From Jarrett.Lu at Sun.COM Mon Oct 13 21:42:53 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Mon, 13 Oct 2008 21:42:53 -0700 Subject: [doi-discuss] test message Message-ID: <48F4234D.3080102@sun.com> test message to doi-discuss at opensolaris.org mailing list. From Jarrett.Lu at Sun.COM Thu Oct 16 16:23:07 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Thu, 16 Oct 2008 16:23:07 -0700 Subject: [doi-discuss] DOI consistency Message-ID: <48F7CCDB.70605@sun.com> This DOI discussion is in the context of MLS, not ISAKMP/IKE. There are at least two current IETF Internet Drafts that define use of DOI. (1) http://tools.ietf.org/html/draft-stjohns-sipso-05 (2) http://tools.ietf.org/html/draft-quigley-nfsv4-sec-label-requirements-01 Although with different wording and varying degree of details, the intended meaning and usage of DOI in the two drafts are largely consistent, i.e. to ensure that labels with same DOI are interpreted the same way among all communicating parties. Although draft (1) is an IP layer specification and (2) is a transport/NFS layer specification, I believe the two drafts should adopt the same DOI format and use the same IANA registry. I speculate that a good portion of label checking logic is needed at IP layer and NFS layer. Using same DOI specification encourages reuse of label checking logic and avoiding complexities caused by different DOI specifications. I suggest that Labeled NFSv4 draft (2) adopt the DOI specification in (1), as the IANA Consideration section in (1) is more detailed. As I understand it, the editor of (1) is collecting feedback for that section right now. If the current specification in that section doesn't meet the need of labeled NFSv4, it's the right time to suggest changes. Jarrett From dpquigl at tycho.nsa.gov Fri Oct 17 07:33:35 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Fri, 17 Oct 2008 10:33:35 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <48F7CCDB.70605@sun.com> References: <48F7CCDB.70605@sun.com> Message-ID: <1224254015.18940.71.camel@moss-terrapins.epoch.ncsc.mil> On Thu, 2008-10-16 at 16:23 -0700, Jarrett Lu wrote: > This DOI discussion is in the context of MLS, not ISAKMP/IKE. > > There are at least two current IETF Internet Drafts that define use of DOI. > (1) http://tools.ietf.org/html/draft-stjohns-sipso-05 > (2) http://tools.ietf.org/html/draft-quigley-nfsv4-sec-label-requirements-01 > > Although with different wording and varying degree of details, the intended > meaning and usage of DOI in the two drafts are largely consistent, i.e. to > ensure that labels with same DOI are interpreted the same way among all > communicating parties. Although draft (1) is an IP layer specification and > (2) is a transport/NFS layer specification, I believe the two drafts should > adopt the same DOI format and use the same IANA registry. I speculate that > a good portion of label checking logic is needed at IP layer and NFS layer. > Using same DOI specification encourages reuse of label checking logic > and avoiding complexities caused by different DOI specifications. > > I suggest that Labeled NFSv4 draft (2) adopt the DOI specification in (1), > as the IANA Consideration section in (1) is more detailed. As I understand > it, the editor of (1) is collecting feedback for that section right now. > If the > current specification in that section doesn't meet the need of labeled > NFSv4, > it's the right time to suggest changes. > > > Jarrett > > > > _______________________________________________ > doi-discuss mailing list > doi-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/doi-discuss Just a couple of clarifying points. I think we need to discuss DOIs in the larger context of MAC systems not just MLS. MLS is one form of MAC but by far isn't the only one. Also I agree that the format for the SIPSO DOI is better than my original suggestions in the Labeled NFS drafts but his definitions are very MLS centric. His section describing the structure of DOIs and its registry (section 9.2) is reasonable to adopt. However his description of a DOI in section 2.1 is somewhat limited in scope. From what I've heard Mike and company seem intent on just developing an IP security option for MLS at the moment and if we want something for DTE or another MAC system we would have to create another IP option later. I'd like to see a generic MAC IP security option but its not something that I can do the legwork on nor am I qualified to do the legwork for it. So assuming we adopt the CALIPSO DOI registry description (section 9.2), what is the way forward for this? I think there are a bunch of other issues such as initial DOI negotiation, proper translation, and label structure that also need to be addressed. Should we draw up an ID once we have figured out all of this? Should we post a MAC DOI considerations ID for IETF approval and make it a normative reference on the CALIPSO/Labeled NFS/Labeled IPSec documents? Dave From Jarrett.Lu at Sun.COM Fri Oct 17 14:46:01 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Fri, 17 Oct 2008 14:46:01 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224254015.18940.71.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <1224254015.18940.71.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <48F90799.2080808@sun.com> On 10/17/08 07:33, David P. Quigley wrote: > On Thu, 2008-10-16 at 16:23 -0700, Jarrett Lu wrote: > >> This DOI discussion is in the context of MLS, not ISAKMP/IKE. >> >> There are at least two current IETF Internet Drafts that define use of DOI. >> (1) http://tools.ietf.org/html/draft-stjohns-sipso-05 >> (2) http://tools.ietf.org/html/draft-quigley-nfsv4-sec-label-requirements-01 >> >> Although with different wording and varying degree of details, the intended >> meaning and usage of DOI in the two drafts are largely consistent, i.e. to >> ensure that labels with same DOI are interpreted the same way among all >> communicating parties. Although draft (1) is an IP layer specification and >> (2) is a transport/NFS layer specification, I believe the two drafts should >> adopt the same DOI format and use the same IANA registry. I speculate that >> a good portion of label checking logic is needed at IP layer and NFS layer. >> Using same DOI specification encourages reuse of label checking logic >> and avoiding complexities caused by different DOI specifications. >> >> I suggest that Labeled NFSv4 draft (2) adopt the DOI specification in (1), >> as the IANA Consideration section in (1) is more detailed. As I understand >> it, the editor of (1) is collecting feedback for that section right now. >> If the >> current specification in that section doesn't meet the need of labeled >> NFSv4, >> it's the right time to suggest changes. >> >> >> Jarrett >> >> >> >> _______________________________________________ >> doi-discuss mailing list >> doi-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/doi-discuss >> > > Just a couple of clarifying points. I think we need to discuss DOIs in > the larger context of MAC systems not just MLS. MLS is one form of MAC > but by far isn't the only one. Also I agree that the format for the > SIPSO DOI is better than my original suggestions in the Labeled NFS > drafts but his definitions are very MLS centric. His section describing > the structure of DOIs and its registry (section 9.2) is reasonable to > adopt. However his description of a DOI in section 2.1 is somewhat > limited in scope. Within the scope of the SIPSO draft, i.e. specifying a traditional MLS CIPSO like option for IPv6, the DOI description in section 2.1 is largely appropriate. I'm not against defining DOI in larger context of MAC system. I believe the current DOI definition and usage model work for a general MAC system if we just substitute "MLS label" with "MAC Security Attributes". Using same DOI implies that communicating parties will interpret, translate, or map the MAC Security Attributes in a consistent manner. > From what I've heard Mike and company seem intent on > just developing an IP security option for MLS at the moment and if we > want something for DTE or another MAC system we would have to create > another IP option later. I'd like to see a generic MAC IP security > option but its not something that I can do the legwork on nor am I > qualified to do the legwork for it. > While I agree a generic IP security option that works for all MAC systems would be very nice, it's out of scope. The requirements are not at all clear, e.g. does it require integrity, confidentiality, flexibility (i.e. can MAC attr be changed, added, deleted by intermediate systems?), etc.. > So assuming we adopt the CALIPSO DOI registry description (section 9.2), > what is the way forward for this? I think there are a bunch of other > issues such as initial DOI negotiation, proper translation, and label > structure that also need to be addressed. Current MAC systems that I know about don't do DOI negotiations at IP layer. If IP module sees a packet with a DOI it doesn't recognize, it drops the packet. I believe that's the right behavior. DOI negotiation may make sense in ULP, e.g. Labeled NFS. It's up to Labeled NFS protocol to define that. Label translation can be implemented in multiple places in a system. But I don't think it's a protocol issue. It should be possible to use different label translation schemes on different system and still for the systems to inter-operate. By "label structure", I guess you mean "label format". We need to agree on DOI's on-wire-format, e.g., its size, alignment requirement, etc.. > Should we draw up an ID once > we have figured out all of this? Should we post a MAC DOI considerations > ID for IETF approval and make it a normative reference on the > CALIPSO/Labeled NFS/Labeled IPSec documents? > A MAC DOI IANA Consideration ID may be appropriate, specially if multiple RFCs share the same registry. Jarrett > Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jarrett.Lu at Sun.COM Mon Oct 20 00:32:10 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Mon, 20 Oct 2008 00:32:10 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <48F90799.2080808@sun.com> References: <48F7CCDB.70605@sun.com> <1224254015.18940.71.camel@moss-terrapins.epoch.ncsc.mil> <48F90799.2080808@sun.com> Message-ID: <48FC33FA.5020707@sun.com> Jarrett Lu wrote: > On 10/17/08 07:33, David P. Quigley wrote: >> So assuming we adopt the CALIPSO DOI registry description (section 9.2), >> what is the way forward for this? I think there are a bunch of other >> issues such as initial DOI negotiation, proper translation, and label >> structure that also need to be addressed. > > Current MAC systems that I know about don't do DOI negotiations at IP > layer. > If IP module sees a packet with a DOI it doesn't recognize, it drops > the packet. > I believe that's the right behavior. DOI negotiation may make sense in > ULP, > e.g. Labeled NFS. It's up to Labeled NFS protocol to define that. > Label translation > can be implemented in multiple places in a system. But I don't think > it's a > protocol issue. It should be possible to use different label > translation schemes > on different system and still for the systems to inter-operate. By > "label structure", > I guess you mean "label format". We need to agree on DOI's on-wire-format, > e.g., its size, alignment requirement, etc.. > I thought about supporting multiple DOIs a bit more. I still don't believe DOI negotiations is necessary in IP, as it may add significant complexity. A simple and effective way for IP to support multiple DOIs is to list all the DOIs a system could support during initialization. The list of DOIs should be small. If Labeled NFS negotiates DOIs, it's important that the DOIs which NFS can support is a subset of what IP can support. Maybe it makes sense to provide an interface so that NFS can query IP what DOI it currently supports. Do you want to use this alias to discuss design issues? Jarrett From paul.moore at hp.com Mon Oct 20 08:11:46 2008 From: paul.moore at hp.com (Paul Moore) Date: Mon, 20 Oct 2008 11:11:46 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <48FC33FA.5020707@sun.com> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> Message-ID: <200810201111.46322.paul.moore@hp.com> On Monday 20 October 2008 3:32:10 am Jarrett Lu wrote: > Jarrett Lu wrote: > > On 10/17/08 07:33, David P. Quigley wrote: > >> So assuming we adopt the CALIPSO DOI registry description (section > >> 9.2), what is the way forward for this? I think there are a bunch > >> of other issues such as initial DOI negotiation, proper > >> translation, and label structure that also need to be addressed. > > > > Current MAC systems that I know about don't do DOI negotiations at > > IP layer. If IP module sees a packet with a DOI it doesn't > > recognize, it drops the packet. I believe that's the right > > behavior. I agree, if a system doesn't understand a particular DOI the only sane option is to drop the packet. > I thought about supporting multiple DOIs a bit more. I still don't > believe DOI negotiations is necessary in IP, as it may add > significant complexity. I believe that complexity is going to be very dependent on the implementation and not something that is inherent in the protocol design. I tend to think there might be some value in supporting multiple DOIs at the IP layer and don't see it as a major handicap for implementation. > A simple and effective way for IP to support > multiple DOIs is to list all the DOIs a system could support during > initialization. The list of DOIs should be small. If Labeled NFS > negotiates DOIs, it's important that the DOIs which NFS can support > is a subset of what IP can support. Maybe it makes sense to provide > an interface so that NFS can query IP what DOI it currently supports. > Do you want to use this alias to discuss design issues? Hmm. I still need to read Dave's latest NFS drafts (sorry Dave) but last time I looked the proposed labeled NFS specification did not require an form of labeled networking to operate which to me indicates that the DOI space used by labeled NFS is independent of the IP layer DOI space. If you happen to be sending labeled NFS traffic over a labeled IP layer then it makes sense to apply some sort of additional checking, not just DOI, but I believe that is going to be implementation specific (or perhaps it is defined in the labeled NFS spec already? it wouldn't be out of place there I don't think). Regardless, while I agree that a common DOI representation is a very good thing, I think trying to integrate all of the different labeled security layers right now is a bit out of scope for this effort (although a common DOI representation paves the way for such an effort at a later date). -- paul moore linux @ hp From dpquigl at tycho.nsa.gov Mon Oct 20 08:24:48 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 11:24:48 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <200810201111.46322.paul.moore@hp.com> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> Message-ID: <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 11:11 -0400, Paul Moore wrote: > On Monday 20 October 2008 3:32:10 am Jarrett Lu wrote: > > Jarrett Lu wrote: > > > On 10/17/08 07:33, David P. Quigley wrote: > > >> So assuming we adopt the CALIPSO DOI registry description (section > > >> 9.2), what is the way forward for this? I think there are a bunch > > >> of other issues such as initial DOI negotiation, proper > > >> translation, and label structure that also need to be addressed. > > > > > > Current MAC systems that I know about don't do DOI negotiations at > > > IP layer. If IP module sees a packet with a DOI it doesn't > > > recognize, it drops the packet. I believe that's the right > > > behavior. > > I agree, if a system doesn't understand a particular DOI the only sane > option is to drop the packet. > > > I thought about supporting multiple DOIs a bit more. I still don't > > believe DOI negotiations is necessary in IP, as it may add > > significant complexity. > > I believe that complexity is going to be very dependent on the > implementation and not something that is inherent in the protocol > design. I tend to think there might be some value in supporting > multiple DOIs at the IP layer and don't see it as a major handicap for > implementation. > > > A simple and effective way for IP to support > > multiple DOIs is to list all the DOIs a system could support during > > initialization. The list of DOIs should be small. If Labeled NFS > > negotiates DOIs, it's important that the DOIs which NFS can support > > is a subset of what IP can support. Maybe it makes sense to provide > > an interface so that NFS can query IP what DOI it currently supports. > > Do you want to use this alias to discuss design issues? >From an information flow perspective it seems unsettling to me that we can potentially have two disjoint DOIs on two different layers. Internally to a machine the DOI needs to be consistent. It doesn't seem right that the IP layer and Labeled NFS can communicated in two different DOIs on the same request. > > Hmm. I still need to read Dave's latest NFS drafts (sorry Dave) but > last time I looked the proposed labeled NFS specification did not > require an form of labeled networking to operate which to me indicates > that the DOI space used by labeled NFS is independent of the IP layer > DOI space. If you happen to be sending labeled NFS traffic over a > labeled IP layer then it makes sense to apply some sort of additional > checking, not just DOI, but I believe that is going to be > implementation specific (or perhaps it is defined in the labeled NFS > spec already? it wouldn't be out of place there I don't think). So Pete, Steve, and I have been talking about this recently and we aren't 100% sold that binding the process label with the rpc request is the right way to go. This means we think we are going to resurrect the putclientlabel operation. So for a "trusted" network there is no requirement to protect this. However for most networks we need to ensure that there is a secure unbypassable channel between the client and the server. It seems that the way to accomplish this is through something like Labeled IPSec. Is it reasonable to mandate the use of labeled IPSec in these environments? Is it something that the working group will agree to leave unprotected in the "trusted" case. > > Regardless, while I agree that a common DOI representation is a very > good thing, I think trying to integrate all of the different labeled > security layers right now is a bit out of scope for this effort > (although a common DOI representation paves the way for such an effort > at a later date). >From what I've been told the number one rule in network protocols is there is no "intermediate" step. Once people start using it they will continue to use it. So if we don't do this now what we will have is a hodgepodge of systems, and chances are we won't be able to convince people to move away from. A generic means of negotiating DOIs and determining how translation works seems reasonable for all layers. Regardless of the layer we need to determine what "language" we are going to speak for further communications which then determines who translates from what to what. The layer that this happens at is still to be determined but it seems like it is something that needs to be discussed. From sommerfeld at sun.com Mon Oct 20 08:48:03 2008 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Mon, 20 Oct 2008 11:48:03 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <200810201111.46322.paul.moore@hp.com> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> Message-ID: <1224517683.2463.7.camel@localhost> On Mon, 2008-10-20 at 11:11 -0400, Paul Moore wrote: > On Monday 20 October 2008 3:32:10 am Jarrett Lu wrote: > > Jarrett Lu wrote: > > > On 10/17/08 07:33, David P. Quigley wrote: > > >> So assuming we adopt the CALIPSO DOI registry description (section > > >> 9.2), what is the way forward for this? I think there are a bunch > > >> of other issues such as initial DOI negotiation, proper > > >> translation, and label structure that also need to be addressed. > > > > > > Current MAC systems that I know about don't do DOI negotiations at > > > IP layer. If IP module sees a packet with a DOI it doesn't > > > recognize, it drops the packet. I believe that's the right > > > behavior. > > I agree, if a system doesn't understand a particular DOI the only sane > option is to drop the packet. > > > I thought about supporting multiple DOIs a bit more. I still don't > > believe DOI negotiations is necessary in IP, as it may add > > significant complexity. > > I believe that complexity is going to be very dependent on the > implementation and not something that is inherent in the protocol > design. I tend to think there might be some value in supporting > multiple DOIs at the IP layer and don't see it as a major handicap for > implementation. I don't believe doi *negotiation* is necessary to support multiple DOI's. > Hmm. I still need to read Dave's latest NFS drafts (sorry Dave) but > last time I looked the proposed labeled NFS specification did not > require an form of labeled networking to operate which to me indicates > that the DOI space used by labeled NFS is independent of the IP layer > DOI space. If you happen to be sending labeled NFS traffic over a > labeled IP layer then it makes sense to apply some sort of additional > checking, not just DOI, but I believe that is going to be > implementation specific (or perhaps it is defined in the labeled NFS > spec already? it wouldn't be out of place there I don't think). one of the little annoyances I keep running into in my labeled ipsec implementation is subtly different representations of MLS labels in different codebases. They all use the same logical structure (32-bit "doi" (which goes by different names in different protocols), level, compartment set) so you can losslessly convert between them but because the encoding and/or field names are different you end up writing N*(N-1) conversion functions. > Regardless, while I agree that a common DOI representation is a very > good thing, I think trying to integrate all of the different labeled > security layers right now is a bit out of scope for this effort > (although a common DOI representation paves the way for such an effort > at a later date). I think having a common representation for MLS labels -- which are IIRC a subset of the flask/selinux/fmac label -- would make all of our lives easier. From paul.moore at hp.com Mon Oct 20 09:00:26 2008 From: paul.moore at hp.com (Paul Moore) Date: Mon, 20 Oct 2008 12:00:26 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <200810201200.26766.paul.moore@hp.com> On Monday 20 October 2008 11:24:48 am David P. Quigley wrote: > On Mon, 2008-10-20 at 11:11 -0400, Paul Moore wrote: > > On Monday 20 October 2008 3:32:10 am Jarrett Lu wrote: > > > Jarrett Lu wrote: > > > > On 10/17/08 07:33, David P. Quigley wrote: > > > >> So assuming we adopt the CALIPSO DOI registry description > > > >> (section 9.2), what is the way forward for this? I think there > > > >> are a bunch of other issues such as initial DOI negotiation, > > > >> proper translation, and label structure that also need to be > > > >> addressed. > > > > > > > > Current MAC systems that I know about don't do DOI negotiations > > > > at IP layer. If IP module sees a packet with a DOI it doesn't > > > > recognize, it drops the packet. I believe that's the right > > > > behavior. > > > > I agree, if a system doesn't understand a particular DOI the only > > sane option is to drop the packet. > > > > > I thought about supporting multiple DOIs a bit more. I still > > > don't believe DOI negotiations is necessary in IP, as it may add > > > significant complexity. > > > > I believe that complexity is going to be very dependent on the > > implementation and not something that is inherent in the protocol > > design. I tend to think there might be some value in supporting > > multiple DOIs at the IP layer and don't see it as a major handicap > > for implementation. > > > > > A simple and effective way for IP to support > > > multiple DOIs is to list all the DOIs a system could support > > > during initialization. The list of DOIs should be small. If > > > Labeled NFS negotiates DOIs, it's important that the DOIs which > > > NFS can support is a subset of what IP can support. Maybe it > > > makes sense to provide an interface so that NFS can query IP what > > > DOI it currently supports. Do you want to use this alias to > > > discuss design issues? > > From an information flow perspective it seems unsettling to me that > we can potentially have two disjoint DOIs on two different layers. Why? From an information flow perspective you only care about the meaning behind the security label. Speaking in broad terms, how the security label is represented should not affect the enforcement of the system's security policy, if it does then the there is a bug in the DOI handling mechanism somewhere. > Internally to a machine the DOI needs to be consistent. Yep, no argument here. Regardless of if the system supports one or one thousand DOIs it still needs to internalize the security labels to enforce the security policy. > It doesn't seem right that the IP layer and Labeled NFS can > communicated in two different DOIs on the same request. Why? It's the meaning behind the security label that counts, not how the label is represented. > > Hmm. I still need to read Dave's latest NFS drafts (sorry Dave) > > but last time I looked the proposed labeled NFS specification did > > not require an form of labeled networking to operate which to me > > indicates that the DOI space used by labeled NFS is independent of > > the IP layer DOI space. If you happen to be sending labeled NFS > > traffic over a labeled IP layer then it makes sense to apply some > > sort of additional checking, not just DOI, but I believe that is > > going to be > > implementation specific (or perhaps it is defined in the labeled > > NFS spec already? it wouldn't be out of place there I don't > > think). > > So Pete, Steve, and I have been talking about this recently and we > aren't 100% sold that binding the process label with the rpc request > is the right way to go. This means we think we are going to resurrect > the putclientlabel operation. So for a "trusted" network there is no > requirement to protect this. However for most networks we need to > ensure that there is a secure unbypassable channel between the client > and the server. It seems that the way to accomplish this is through > something like Labeled IPSec. Is it reasonable to mandate the use of > labeled IPSec in these environments? Is it something that the working > group will agree to leave unprotected in the "trusted" case. So why do you need _labeled_ IPsec? Why not just good ole fashioned IPsec which has already been standardized? > > Regardless, while I agree that a common DOI representation is a > > very good thing, I think trying to integrate all of the different > > labeled security layers right now is a bit out of scope for this > > effort (although a common DOI representation paves the way for such > > an effort at a later date). > > From what I've been told the number one rule in network protocols is > there is no "intermediate" step. Once people start using it they will > continue to use it. So if we don't do this now what we will have is a > hodgepodge of systems, and chances are we won't be able to convince > people to move away from. A generic means of negotiating DOIs and > determining how translation works seems reasonable for all layers. > Regardless of the layer we need to determine what "language" we are > going to speak for further communications which then determines who > translates from what to what. The layer that this happens at is still > to be determined but it seems like it is something that needs to be > discussed. I think we have a bit of a disconnect here, it isn't clear to me if you agree or disagree with my comment. I don't see anything in your response which contradicts what I was (trying) to say, but then again people rarely type so much when they agree :) Perhaps a good first step is to set aside discussions about specific issues and clarify our goals/intentions for this effort. -- paul moore linux @ hp From paul.moore at hp.com Mon Oct 20 09:06:30 2008 From: paul.moore at hp.com (Paul Moore) Date: Mon, 20 Oct 2008 12:06:30 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224517683.2463.7.camel@localhost> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> Message-ID: <200810201206.30288.paul.moore@hp.com> On Monday 20 October 2008 11:48:03 am Bill Sommerfeld wrote: > On Mon, 2008-10-20 at 11:11 -0400, Paul Moore wrote: > > On Monday 20 October 2008 3:32:10 am Jarrett Lu wrote: > > > Jarrett Lu wrote: > > > > On 10/17/08 07:33, David P. Quigley wrote: > > > >> So assuming we adopt the CALIPSO DOI registry description > > > >> (section 9.2), what is the way forward for this? I think there > > > >> are a bunch of other issues such as initial DOI negotiation, > > > >> proper translation, and label structure that also need to be > > > >> addressed. > > > > > > > > Current MAC systems that I know about don't do DOI negotiations > > > > at IP layer. If IP module sees a packet with a DOI it doesn't > > > > recognize, it drops the packet. I believe that's the right > > > > behavior. > > > > I agree, if a system doesn't understand a particular DOI the only > > sane option is to drop the packet. > > > > > I thought about supporting multiple DOIs a bit more. I still > > > don't believe DOI negotiations is necessary in IP, as it may add > > > significant complexity. > > > > I believe that complexity is going to be very dependent on the > > implementation and not something that is inherent in the protocol > > design. I tend to think there might be some value in supporting > > multiple DOIs at the IP layer and don't see it as a major handicap > > for implementation. > > I don't believe doi *negotiation* is necessary to support multiple > DOI's. Agreed. I see now I may have read Jarrett's comment the wrong way, my apologies for any confusion. To be clear, I think we need to allow systems to support multiple DOIs but defining a mechanism for DOI negotiation is not a necessity. -- paul moore linux @ hp From sommerfeld at sun.com Mon Oct 20 09:14:10 2008 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Mon, 20 Oct 2008 12:14:10 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <200810201200.26766.paul.moore@hp.com> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> Message-ID: <1224519250.2463.14.camel@localhost> On Mon, 2008-10-20 at 12:00 -0400, Paul Moore wrote: > Why? From an information flow perspective you only care about the > meaning behind the security label. Speaking in broad terms, how the > security label is represented should not affect the enforcement of the > system's security policy, if it does then the there is a bug in the DOI > handling mechanism somewhere. this looks to me like a gap between theory and practice. in theory this is true. in practice, multiple representations aren't going to be precisely equivalent, so conversions between representations will necessarily have error cases ("oops, this representation doesn't have room for that many compartment bits"). all this adds complexity and bugs and mysterious failures to communicate. > So why do you need _labeled_ IPsec? Why not just good ole fashioned > IPsec which has already been standardized? I haven't been following labeled NFS (maybe I should). If you're using multiple labels over a single transport connection you at the very least need some way to distinguish traffic from random user processes from traffic from a label-aware trusted NFS client. - Bill From Nicolas.Williams at sun.com Mon Oct 20 09:24:53 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 11:24:53 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224519250.2463.14.camel@localhost> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> Message-ID: <20081020162452.GT8906@Sun.COM> On Mon, Oct 20, 2008 at 12:14:10PM -0400, Bill Sommerfeld wrote: > > So why do you need _labeled_ IPsec? Why not just good ole fashioned > > IPsec which has already been standardized? > > I haven't been following labeled NFS (maybe I should). If you're using > multiple labels over a single transport connection you at the very least > need some way to distinguish traffic from random user processes from > traffic from a label-aware trusted NFS client. If one were using secure NFS over unlabeled IPsec with channel binding and confidentiality protection then indeed labeling at the IPsec layer would be unimportant -- it should suffice to have label-aware NFS clients and servers... ...Unless, of course, you have middle boxes that want to see labeled packets. In that case there's still no reason why the "outer" IP and "inner" NFS labels need to be in the same DOI, other than for simplicity of administration. Nico -- From paul.moore at hp.com Mon Oct 20 09:40:16 2008 From: paul.moore at hp.com (Paul Moore) Date: Mon, 20 Oct 2008 12:40:16 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224519250.2463.14.camel@localhost> References: <48F7CCDB.70605@sun.com> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> Message-ID: <200810201240.16485.paul.moore@hp.com> On Monday 20 October 2008 12:14:10 pm Bill Sommerfeld wrote: > On Mon, 2008-10-20 at 12:00 -0400, Paul Moore wrote: > > Why? From an information flow perspective you only care about the > > meaning behind the security label. Speaking in broad terms, how > > the security label is represented should not affect the enforcement > > of the system's security policy, if it does then the there is a bug > > in the DOI handling mechanism somewhere. > > this looks to me like a gap between theory and practice. > > in theory this is true. > > in practice, multiple representations aren't going to be precisely > equivalent, so conversions between representations will necessarily > have error cases ("oops, this representation doesn't have room for > that many compartment bits"). I agree, there is always the chance to run into issues when trying to translate between different DOIs (hence my "speaking in broad terms" comment) and in some cases there is not always a nice clean solution. My opinion is that the specification should allow it, but it is up to the implementations to decide if they want to implement it and the system administrators if they want to enable it. > all this adds complexity and bugs and mysterious failures to > communicate. It also adds flexibility and the potential to do things you might not be able to do otherwise. > > So why do you need _labeled_ IPsec? Why not just good ole > > fashioned IPsec which has already been standardized? > > I haven't been following labeled NFS (maybe I should). If you're > using multiple labels over a single transport connection you at the > very least need some way to distinguish traffic from random user > processes from traffic from a label-aware trusted NFS client. Maybe I misunderstood Dave, but I thought he was talking about carrying all the NFS process label information in the RPC calls which should disambiguate things at the RPC layer. -- paul moore linux @ hp From Nicolas.Williams at sun.com Mon Oct 20 09:37:01 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 11:37:01 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224517683.2463.7.camel@localhost> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> Message-ID: <20081020163701.GU8906@Sun.COM> On Mon, Oct 20, 2008 at 11:48:03AM -0400, Bill Sommerfeld wrote: > > I believe that complexity is going to be very dependent on the > > implementation and not something that is inherent in the protocol > > design. I tend to think there might be some value in supporting > > multiple DOIs at the IP layer and don't see it as a major handicap for > > implementation. > > I don't believe doi *negotiation* is necessary to support multiple > DOI's. Could you expand on this? My guess: a node asserts a label in some DOI and a peer says "yes, I know that DOI" or "no, I don't know that DOI"; that listing known DOIs does not do any good. I.e., telling a node N that wanted to use DOI A that you (peer P) support only DOIs B, C or D does that node no good because N really wanted to use DOI A. And if there's a mapping between DOI A and one or more of DOIs B, C and/or D then EITHER node N should know a priori (via configuration or name service lookups) that P wants one of those and then N should map accordingly, or P should know about DOI A and how to map it to one or more of DOIs B, C and/or D. Right? If so then I agree: there's no need to negotiate DOIs. Besides being potentially impractical (if there were too many DOIs to list), it could also leak information. Nico -- From Jarrett.Lu at Sun.COM Mon Oct 20 10:20:23 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Mon, 20 Oct 2008 10:20:23 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <48FCBDD7.9050308@sun.com> David P. Quigley wrote: > On Mon, 2008-10-20 at 11:11 -0400, Paul Moore wrote: > >> Hmm. I still need to read Dave's latest NFS drafts (sorry Dave) but >> last time I looked the proposed labeled NFS specification did not >> require an form of labeled networking to operate which to me indicates >> that the DOI space used by labeled NFS is independent of the IP layer >> DOI space. If you happen to be sending labeled NFS traffic over a >> labeled IP layer then it makes sense to apply some sort of additional >> checking, not just DOI, but I believe that is going to be >> implementation specific (or perhaps it is defined in the labeled NFS >> spec already? it wouldn't be out of place there I don't think). >> > > So Pete, Steve, and I have been talking about this recently and we > aren't 100% sold that binding the process label with the rpc request is > the right way to go. This means we think we are going to resurrect the > putclientlabel operation. So for a "trusted" network there is no > requirement to protect this. However for most networks we need to ensure > that there is a secure unbypassable channel between the client and the > server. It seems that the way to accomplish this is through something > like Labeled IPSec. Is it reasonable to mandate the use of labeled IPSec > in these environments? Is it something that the working group will agree > to leave unprotected in the "trusted" case. > Labeled NFS requiring labeled networking makes sense to me. I believe we need to support both labeled IPsec and cleartext labels. In enterprise environment, where NFS is typically used, cleartext label may be appropriate. When network is untrustworthy, labeled IPsec may be more appropriate. I think you should let NFSv4 WG know your plan on requiring labeled IPsec. There will always be people who are uncomfortable with the idea of cleartext labels. At same time, trusted system customers are OK or sometimes prefer that. It's easier to get acceptance if labeled IPsec is an trusted network option. > >> Regardless, while I agree that a common DOI representation is a very >> good thing, I think trying to integrate all of the different labeled >> security layers right now is a bit out of scope for this effort >> (although a common DOI representation paves the way for such an effort >> at a later date). >> > > >From what I've been told the number one rule in network protocols is > there is no "intermediate" step. Once people start using it they will > continue to use it. So if we don't do this now what we will have is a > hodgepodge of systems, and chances are we won't be able to convince > people to move away from. A generic means of negotiating DOIs and > determining how translation works seems reasonable for all layers. > Regardless of the layer we need to determine what "language" we are > going to speak for further communications which then determines who > translates from what to what. The layer that this happens at is still to > be determined but it seems like it is something that needs to be > discussed. > I still think dynamically negotiate DOIs, at least at IP layer, is complex and will require other IP protocol extensions, e.g. imaging doing labeled IP routing. Defining a list of DOIs a system can support via configuration is much simpler than doing it over a negotiation protocol. I have much less experience in DOI (and MAC security attribute) translation. Using MLS label as an example, by translation, you mean the label takes a different form but the security level remains the same, i.e. SECRET is still SECRET, but the bit patten is now different with a different DOI. Right? Can the label representation be very different with different DOIs? I'm trying to understand the "translation" requirements are and see if we should define the problem better. At IP layer, translation may require replacing one on-the-wire label with another, and that may blow away PMTU. With labeled IPsec, keys are negotiated end to end and may be unfriendly to such translations. NFS need not deal with the same issues as IP. It may be more manageable to define label translation in NFS, without requiring the same translation must work for IP as well. BTW, I agree with you that the DOIs used by IP and NFS should be consistent. That may mean as long as IP thinks the DOI is valid, NFS can do the translation. Jarrett > > From Nicolas.Williams at sun.com Mon Oct 20 10:02:29 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 12:02:29 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <200810201240.16485.paul.moore@hp.com> References: <48F7CCDB.70605@sun.com> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> <200810201240.16485.paul.moore@hp.com> Message-ID: <20081020170228.GX8906@Sun.COM> On Mon, Oct 20, 2008 at 12:40:16PM -0400, Paul Moore wrote: > > I haven't been following labeled NFS (maybe I should). If you're > > using multiple labels over a single transport connection you at the > > very least need some way to distinguish traffic from random user > > processes from traffic from a label-aware trusted NFS client. > > Maybe I misunderstood Dave, but I thought he was talking about carrying > all the NFS process label information in the RPC calls which should > disambiguate things at the RPC layer. Yes. Actually, labeled NFSv4 extensions would roughly consist of two enhancements to NFS: 1) an extension (most likely at the RPC auth layer, specifically as an RPCSEC_GSS extension) to communicate process labels; 2) new NFSv4 operations for getting/setting the labels of filesystem objects. Nico -- From sommerfeld at sun.com Mon Oct 20 10:25:53 2008 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Mon, 20 Oct 2008 13:25:53 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020163701.GU8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> Message-ID: <1224523553.2463.90.camel@localhost> On Mon, 2008-10-20 at 11:37 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 11:48:03AM -0400, Bill Sommerfeld wrote: > > I don't believe doi *negotiation* is necessary to support multiple > > DOI's. > > Could you expand on this? To me "DOI negotiation" implies that (at least) one party to a successful communication won't know, a priori, which DOI will be used. > My guess: a node asserts a label in some DOI and a peer says "yes, I > know that DOI" or "no, I don't know that DOI"; that listing known DOIs > does not do any good. in some cases the peer wouldn't say that explicitly -- either it would pass the traffic or drop the traffic. > I.e., telling a node N that wanted to use DOI A that you (peer P) > support only DOIs B, C or D does that node no good because N really > wanted to use DOI A. correct. the network administrator needs to lay down rules of the road which specify where various DOI's get used and how they get used in cross-domain communication. > And if there's a mapping between DOI A and one or more of DOIs B, C > and/or D then EITHER node N should know a priori (via configuration or > name service lookups) that P wants one of those and then N should map > accordingly, or P should know about DOI A and how to map it to one or > more of DOIs B, C and/or D. correct. From Nicolas.Williams at sun.com Mon Oct 20 13:03:18 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 15:03:18 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224523553.2463.90.camel@localhost> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224523553.2463.90.camel@localhost> Message-ID: <20081020200318.GC8906@Sun.COM> On Mon, Oct 20, 2008 at 01:25:53PM -0400, Bill Sommerfeld wrote: > On Mon, 2008-10-20 at 11:37 -0500, Nicolas Williams wrote: > > I.e., telling a node N that wanted to use DOI A that you (peer P) > > support only DOIs B, C or D does that node no good because N really > > wanted to use DOI A. > > correct. the network administrator needs to lay down rules of the road > which specify where various DOI's get used and how they get used in > cross-domain communication. To the extent that labels in different DOIs can be mapped from one to the other, I think: a) client implementors will prefer to let the server do the translations, while b) server implementors will prefer to let the client do the translations, and c) deployers will prefer whatever is easiest for them to deploy (probably: the server translates). I suspect though that DOI translations are unlikely, except, perhaps, in very simplistic ways (e.g., process with label X in unknown DOI Y -> ADMIN_LOW (in MLS), set file label X in unknown DOI Y -> reject). I also suspect that DTE DOIs are disjoint. In so far as DTE resembles RBAC clearly the profiles/roles will be specific to individual operating systems and applications, with NFS servers aware only of the latter (ignoring diskless clients, for now). > > And if there's a mapping between DOI A and one or more of DOIs B, C > > and/or D then EITHER node N should know a priori (via configuration or > > name service lookups) that P wants one of those and then N should map > > accordingly, or P should know about DOI A and how to map it to one or > > more of DOIs B, C and/or D. > > correct. I suppose that P could help N find the correct translation mechanism by saying "I know about DOIs B, C and D," in the case where N couldn't figure that out in some other way. But again, that's predicated on the idea that you could configure such mappings, which seems unlikely. Nico -- From dpquigl at tycho.nsa.gov Mon Oct 20 13:45:25 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 16:45:25 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020163701.GU8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> Message-ID: <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 11:37 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 11:48:03AM -0400, Bill Sommerfeld wrote: > > > I believe that complexity is going to be very dependent on the > > > implementation and not something that is inherent in the protocol > > > design. I tend to think there might be some value in supporting > > > multiple DOIs at the IP layer and don't see it as a major handicap for > > > implementation. > > > > I don't believe doi *negotiation* is necessary to support multiple > > DOI's. > > Could you expand on this? > > My guess: a node asserts a label in some DOI and a peer says "yes, I > know that DOI" or "no, I don't know that DOI"; that listing known DOIs > does not do any good. > > I.e., telling a node N that wanted to use DOI A that you (peer P) > support only DOIs B, C or D does that node no good because N really > wanted to use DOI A. > > And if there's a mapping between DOI A and one or more of DOIs B, C > and/or D then EITHER node N should know a priori (via configuration or > name service lookups) that P wants one of those and then N should map > accordingly, or P should know about DOI A and how to map it to one or > more of DOIs B, C and/or D. > I should clarify what I mean by negotiation because it seems to be a point of confusion. I'm not saying that if one endpoint knows about DOI A and the other does not that the side that is unaware of DOI A should be able to negotiate the mapping for it. What I am saying is that at connection time both sides should say we support these DOIs and then they can make a conscious policy decision based on this information as to which one to use. What happens if both of the endpoints support both B and C? One side should be able to say you know what C is better for our uses than B we should go with that. By the one end asserting an arbitrary DOI you don't get this ability. An example of this might be if both sides natively use C but for some reason one end is asserting B. > Right? > > If so then I agree: there's no need to negotiate DOIs. Besides being > potentially impractical (if there were too many DOIs to list), it could > also leak information. > > Nico From dpquigl at tycho.nsa.gov Mon Oct 20 13:51:07 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 16:51:07 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020200318.GC8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224523553.2463.90.camel@localhost> <20081020200318.GC8906@Sun.COM> Message-ID: <1224535867.18940.107.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 15:03 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 01:25:53PM -0400, Bill Sommerfeld wrote: > > On Mon, 2008-10-20 at 11:37 -0500, Nicolas Williams wrote: > > > I.e., telling a node N that wanted to use DOI A that you (peer P) > > > support only DOIs B, C or D does that node no good because N really > > > wanted to use DOI A. > > > > correct. the network administrator needs to lay down rules of the road > > which specify where various DOI's get used and how they get used in > > cross-domain communication. > > To the extent that labels in different DOIs can be mapped from one to > the other, I think: > > a) client implementors will prefer to let the server do the > translations, This seems like it will introduce scalability issues. > > while > > b) server implementors will prefer to let the client do the > translations, > I'd say this is the preferred method. > and > > c) deployers will prefer whatever is easiest for them to deploy > (probably: the server translates). In this situation i would see it being the server translation since they only need to set it up on one end. How does this work currently with the NFS idmap stuff? It seems to me that there is a translation on both ends that needs to be maintained which can be an administrative burden. > > I suspect though that DOI translations are unlikely, except, perhaps, in > very simplistic ways (e.g., process with label X in unknown DOI Y -> > ADMIN_LOW (in MLS), set file label X in unknown DOI Y -> reject). > > I also suspect that DTE DOIs are disjoint. In so far as DTE resembles > RBAC clearly the profiles/roles will be specific to individual operating > systems and applications, with NFS servers aware only of the latter > (ignoring diskless clients, for now). For the most part they will be but that doesn't mean there aren't valid translations between them. SELinux policy may have httpd_public_content_t while FMAC calles the same thing exportable_webcontent_t. Semantically they are the same and even though there may be a bunch of other types that we don't share it might be valuable for me to be able to handle that. > > > > And if there's a mapping between DOI A and one or more of DOIs B, C > > > and/or D then EITHER node N should know a priori (via configuration or > > > name service lookups) that P wants one of those and then N should map > > > accordingly, or P should know about DOI A and how to map it to one or > > > more of DOIs B, C and/or D. > > > > correct. > > I suppose that P could help N find the correct translation mechanism by > saying "I know about DOIs B, C and D," in the case where N couldn't > figure that out in some other way. But again, that's predicated on the > idea that you could configure such mappings, which seems unlikely. > > Nico From Nicolas.Williams at sun.com Mon Oct 20 14:17:39 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 16:17:39 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081020211738.GE8906@Sun.COM> On Mon, Oct 20, 2008 at 04:45:25PM -0400, David P. Quigley wrote: > I should clarify what I mean by negotiation because it seems to be a > point of confusion. I'm not saying that if one endpoint knows about DOI > A and the other does not that the side that is unaware of DOI A should > be able to negotiate the mapping for it. What I am saying is that at > connection time both sides should say we support these DOIs and then > they can make a conscious policy decision based on this information as > to which one to use. What happens if both of the endpoints support both > B and C? One side should be able to say you know what C is better for > our uses than B we should go with that. By the one end asserting an > arbitrary DOI you don't get this ability. An example of this might be if > both sides natively use C but for some reason one end is asserting B. OK, so node N could and should know about peer P's preferences, but it happens that it does not, and so if only P could tell N what those preferences are, then N could pick the best DOI mapping? I can see that. It simplifies client/name service configuration. It still puts the onus for DOI mapping on clients. And it presumes that such a thing (mappings between DOIs) is possible. Do we really want DOI negotiation? How many DOIs are we likely to see that can be mapped? Nico -- From Nicolas.Williams at sun.com Mon Oct 20 14:47:57 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 16:47:57 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224535867.18940.107.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224523553.2463.90.camel@localhost> <20081020200318.GC8906@Sun.COM> <1224535867.18940.107.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081020214757.GF8906@Sun.COM> On Mon, Oct 20, 2008 at 04:51:07PM -0400, David P. Quigley wrote: > On Mon, 2008-10-20 at 15:03 -0500, Nicolas Williams wrote: > > To the extent that labels in different DOIs can be mapped from one to > > the other, I think: > > > > a) client implementors will prefer to let the server do the > > translations, > > This seems like it will introduce scalability issues. Do you mean that DOI mapping is an undue burden on servers? > > while > > > > b) server implementors will prefer to let the client do the > > translations, > > I'd say this is the preferred method. Because of the scalability issue above? > > and > > > > c) deployers will prefer whatever is easiest for them to deploy > > (probably: the server translates). > > In this situation i would see it being the server translation since they > only need to set it up on one end. Right. > How does this work currently with the > NFS idmap stuff? It seems to me that there is a translation on both ends > that needs to be maintained which can be an administrative burden. Currently NFSv4 clients and servers need to know how to map internal identifiers (e.g., POSIX UIDs/GIDs, Windows SIDs, whatever) to NFSv4 on-the-wire user/group names. However, we're considering adding support on the client side for passing those o-t-w user/group names straight through from/to the application (via new APIs). In that case the client wouldn't have to know anything about ID mapping (assume RPCSEC_GSS is used, not AUTH_SYS), but the server still has to. Personally I'd like to add a way to negotiate the use of SIDs on the wire in NFSv4 and so avoid the ID mapping problem altogether in some cases. IMO it was a mistake to use names on the wire in NFSv4. The right solution would have been to use SIDs, with server implementations that do not support storing SIDs using simple algorithm mapping to SIDs relative to a server machine SID prefix. But it'd have been an even bigger mistake to put the onus for ID mapping on the client. Putting the onus for name service lookups on the client is perfectly reasonable, but ID mapping is not. Unfortunately I don't see ID mapping as sufficiently similar to DOI mapping for the ID mapping experience to shed useful light here. > > I suspect though that DOI translations are unlikely, except, perhaps, in > > very simplistic ways (e.g., process with label X in unknown DOI Y -> > > ADMIN_LOW (in MLS), set file label X in unknown DOI Y -> reject). > > > > I also suspect that DTE DOIs are disjoint. In so far as DTE resembles > > RBAC clearly the profiles/roles will be specific to individual operating > > systems and applications, with NFS servers aware only of the latter > > (ignoring diskless clients, for now). > > For the most part they will be but that doesn't mean there aren't valid > translations between them. SELinux policy may have > httpd_public_content_t while FMAC calles the same thing > exportable_webcontent_t. Semantically they are the same and even though > there may be a bunch of other types that we don't share it might be > valuable for me to be able to handle that. Right, but arguably those two labels/types are application ones, rather than system ones, and preferably the customer could have a single DOI for the web service application. But I gather that that may seem unrealistic to you. SELinux and FMAC are likely to have distinct-but-similar policies for a large variety of similar, if not even the same apps. Right? Or can that be avoided? It's not too late, is it? Nico -- From Jarrett.Lu at Sun.COM Mon Oct 20 15:52:47 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Mon, 20 Oct 2008 15:52:47 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020211738.GE8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> Message-ID: <48FD0BBF.4000400@sun.com> Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 04:45:25PM -0400, David P. Quigley wrote: > >> I should clarify what I mean by negotiation because it seems to be a >> point of confusion. I'm not saying that if one endpoint knows about DOI >> A and the other does not that the side that is unaware of DOI A should >> be able to negotiate the mapping for it. What I am saying is that at >> connection time both sides should say we support these DOIs and then >> they can make a conscious policy decision based on this information as >> to which one to use. What happens if both of the endpoints support both >> B and C? One side should be able to say you know what C is better for >> our uses than B we should go with that. By the one end asserting an >> arbitrary DOI you don't get this ability. An example of this might be if >> both sides natively use C but for some reason one end is asserting B. >> > > OK, so node N could and should know about peer P's preferences, but it > happens that it does not, and so if only P could tell N what those > preferences are, then N could pick the best DOI mapping? > > I can see that. It simplifies client/name service configuration. It > still puts the onus for DOI mapping on clients. And it presumes that > such a thing (mappings between DOIs) is possible. > If a node asserts that it understands DOI B and C, is this an automatic declaration that it knows how to map between the two? Or does it merely says I can interpret labels with DOI B and C, but the mapping between the two isn't known to me? Are we still saying the DOI used by NFS should also be supported by IP module? Or are we pursuing the model that IP DOI knowledge doesn't matter, i.e. IP thinks it only knows DOI A; NFS client and server agree that DOI B is the best one. They embed file labels (with DOI B) in the payload so that IP doesn't actually know what's going on. I still think it's desirable that DOIs used by different layers are consistent. It's odd that a communication worked because we are successful in hinding the real DOI from IP module. Jarrett From dpquigl at tycho.nsa.gov Mon Oct 20 15:35:18 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 18:35:18 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020211738.GE8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> Message-ID: <1224542118.31157.3.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 16:17 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 04:45:25PM -0400, David P. Quigley wrote: > > I should clarify what I mean by negotiation because it seems to be a > > point of confusion. I'm not saying that if one endpoint knows about DOI > > A and the other does not that the side that is unaware of DOI A should > > be able to negotiate the mapping for it. What I am saying is that at > > connection time both sides should say we support these DOIs and then > > they can make a conscious policy decision based on this information as > > to which one to use. What happens if both of the endpoints support both > > B and C? One side should be able to say you know what C is better for > > our uses than B we should go with that. By the one end asserting an > > arbitrary DOI you don't get this ability. An example of this might be if > > both sides natively use C but for some reason one end is asserting B. > > OK, so node N could and should know about peer P's preferences, but it > happens that it does not, and so if only P could tell N what those > preferences are, then N could pick the best DOI mapping? > > I can see that. It simplifies client/name service configuration. It > still puts the onus for DOI mapping on clients. And it presumes that > such a thing (mappings between DOIs) is possible. > > Do we really want DOI negotiation? How many DOIs are we likely to see > that can be mapped? Unfortunately I am new to this space so I don't have any anecdotal evidence to the number of DOIs however I can see a situation where SELinux may take a label coming from a box that just supports MLS and label it internally with some type which is then sent down a trusted path to be handled. > > Nico From dpquigl at tycho.nsa.gov Mon Oct 20 15:39:32 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 18:39:32 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <48FD0BBF.4000400@sun.com> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> Message-ID: <1224542372.31157.8.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 15:52 -0700, Jarrett Lu wrote: > Nicolas Williams wrote: > > On Mon, Oct 20, 2008 at 04:45:25PM -0400, David P. Quigley wrote: > > > >> I should clarify what I mean by negotiation because it seems to be a > >> point of confusion. I'm not saying that if one endpoint knows about DOI > >> A and the other does not that the side that is unaware of DOI A should > >> be able to negotiate the mapping for it. What I am saying is that at > >> connection time both sides should say we support these DOIs and then > >> they can make a conscious policy decision based on this information as > >> to which one to use. What happens if both of the endpoints support both > >> B and C? One side should be able to say you know what C is better for > >> our uses than B we should go with that. By the one end asserting an > >> arbitrary DOI you don't get this ability. An example of this might be if > >> both sides natively use C but for some reason one end is asserting B. > >> > > > > OK, so node N could and should know about peer P's preferences, but it > > happens that it does not, and so if only P could tell N what those > > preferences are, then N could pick the best DOI mapping? > > > > I can see that. It simplifies client/name service configuration. It > > still puts the onus for DOI mapping on clients. And it presumes that > > such a thing (mappings between DOIs) is possible. > > > > If a node asserts that it understands DOI B and C, is this an automatic > declaration that it knows how to map between the two? Or does it > merely says I can interpret labels with DOI B and C, but the mapping > between the two isn't known to me? Understanding B and C means that I can take a label of DOI B or C and translate it into my local DOI. Whatever that means. I'm not sure if there is a use for me exporting the fact that I transmit labels in B or C but internally use A. I'm going to need to sit down with some people here and get some more insight into what we've seen and what we think the right way to handle this is. > > Are we still saying the DOI used by NFS should also be supported by > IP module? Or are we pursuing the model that IP DOI knowledge doesn't > matter, i.e. IP thinks it only knows DOI A; NFS client and server agree > that DOI B is the best one. They embed file labels (with DOI B) in the > payload so that IP doesn't actually know what's going on. I still think > it's desirable that DOIs used by different layers are consistent. It's odd > that a communication worked because we are successful in hinding > the real DOI from IP module. > So I think I was wrong in asserting that a DOI at the IP and Labeled NFS level should be the same. It seems like it isn't really practical and it would be an administrative nightmare. Also this will potentially leak information across the levels that doesn't need to be. > > Jarrett From dpquigl at tycho.nsa.gov Mon Oct 20 15:49:52 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 18:49:52 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020214757.GF8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224523553.2463.90.camel@localhost> <20081020200318.GC8906@Sun.COM> <1224535867.18940.107.camel@moss-terrapins.epoch.ncsc.mil> <20081020214757.GF8906@Sun.COM> Message-ID: <1224542992.31157.19.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 16:47 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 04:51:07PM -0400, David P. Quigley wrote: > > On Mon, 2008-10-20 at 15:03 -0500, Nicolas Williams wrote: > > > To the extent that labels in different DOIs can be mapped from one to > > > the other, I think: > > > > > > a) client implementors will prefer to let the server do the > > > translations, > > > > This seems like it will introduce scalability issues. > > Do you mean that DOI mapping is an undue burden on servers? Yes. > > > > while > > > > > > b) server implementors will prefer to let the client do the > > > translations, > > > > I'd say this is the preferred method. > > Because of the scalability issue above? Exactly. > > > > and > > > > > > c) deployers will prefer whatever is easiest for them to deploy > > > (probably: the server translates). > > > > In this situation i would see it being the server translation since they > > only need to set it up on one end. > > Right. > > > How does this work currently with the > > NFS idmap stuff? It seems to me that there is a translation on both ends > > that needs to be maintained which can be an administrative burden. > > Currently NFSv4 clients and servers need to know how to map internal > identifiers (e.g., POSIX UIDs/GIDs, Windows SIDs, whatever) to NFSv4 > on-the-wire user/group names. > > However, we're considering adding support on the client side for passing > those o-t-w user/group names straight through from/to the application > (via new APIs). In that case the client wouldn't have to know anything > about ID mapping (assume RPCSEC_GSS is used, not AUTH_SYS), but the > server still has to. > > Personally I'd like to add a way to negotiate the use of SIDs on the > wire in NFSv4 and so avoid the ID mapping problem altogether in some > cases. > > IMO it was a mistake to use names on the wire in NFSv4. The right > solution would have been to use SIDs, with server implementations that > do not support storing SIDs using simple algorithm mapping to SIDs > relative to a server machine SID prefix. > > But it'd have been an even bigger mistake to put the onus for ID mapping > on the client. Putting the onus for name service lookups on the client > is perfectly reasonable, but ID mapping is not. > > Unfortunately I don't see ID mapping as sufficiently similar to DOI > mapping for the ID mapping experience to shed useful light here. What do you mean by SIDs. I'm guessing it is some sort of Security Identifier which represents the file's ownership. > > > > I suspect though that DOI translations are unlikely, except, perhaps, in > > > very simplistic ways (e.g., process with label X in unknown DOI Y -> > > > ADMIN_LOW (in MLS), set file label X in unknown DOI Y -> reject). > > > > > > I also suspect that DTE DOIs are disjoint. In so far as DTE resembles > > > RBAC clearly the profiles/roles will be specific to individual operating > > > systems and applications, with NFS servers aware only of the latter > > > (ignoring diskless clients, for now). > > > > For the most part they will be but that doesn't mean there aren't valid > > translations between them. SELinux policy may have > > httpd_public_content_t while FMAC calles the same thing > > exportable_webcontent_t. Semantically they are the same and even though > > there may be a bunch of other types that we don't share it might be > > valuable for me to be able to handle that. > > Right, but arguably those two labels/types are application ones, rather > than system ones, and preferably the customer could have a single DOI > for the web service application. SELinux/FMAC/Flask define system wide policy. If apache or whatever web serve is being used is an object manager then yes it might need its own DOI but for the purpose of these systems the DOI is the semantic meaning of the types in the entire system policy which includes the applications running on it. > > But I gather that that may seem unrealistic to you. SELinux and FMAC > are likely to have distinct-but-similar policies for a large variety of > similar, if not even the same apps. Right? Or can that be avoided? > It's not too late, is it? So from what I've been hearing of the FMAC effort they are taking all that we have learned from SELinux with respect to policy development and are doing things with the policy that we can't do in SELinux due to backwards compatibility constraints. I will have to talk with Steve about this tomorrow. It isn't too late to change FMAC stuff (or even some SELinux stuff) however, it's important to learn from past experiences. > Nico From Nicolas.Williams at sun.com Mon Oct 20 16:02:13 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 18:02:13 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <48FD0BBF.4000400@sun.com> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> Message-ID: <20081020230213.GM8906@Sun.COM> On Mon, Oct 20, 2008 at 03:52:47PM -0700, Jarrett Lu wrote: > If a node asserts that it understands DOI B and C, is this an automatic > declaration that it knows how to map between the two? Or does it > merely says I can interpret labels with DOI B and C, but the mapping > between the two isn't known to me? Or even "I can interpret labels with DOI B and C, and that says nothing about whether I can map between them -- mapping is up to you." We get to choose the semantics of any DOI negotiation. The interesting question is: who should have the burden of DOI mapping, if anyone? If the client -> let the client tell the server what DOIs it can map between and then let the server pick one. Alternatively let the client just know from name service lookups. If the server -> no negotiation -- let the client assert what it wishes and let the server do what it can (including mapping process labels to the lowest available, and rejecting file labels it doesn't understand). So we need to resolve the issue of who has this burden. > Are we still saying the DOI used by NFS should also be supported by > IP module? Or are we pursuing the model that IP DOI knowledge doesn't > matter, i.e. IP thinks it only knows DOI A; NFS client and server agree > that DOI B is the best one. They embed file labels (with DOI B) in the > payload so that IP doesn't actually know what's going on. I still think > it's desirable that DOIs used by different layers are consistent. It's odd > that a communication worked because we are successful in hinding > the real DOI from IP module. Good question. I don't know. The server could workout process credentials and label of clients as follows: - first establish the label range of the client, Rc - then establish the credentials and label range of the client process (RPCSEC_GSS client principal), Ru - then evaluate Rc ^ Ru ^ {asserted label} (or, if result is empty set, the lowest label in some DOI) or: - establish the credentials and label range of the client process (RPCSEC_GSS client principal), Ru - then evaluate Ru ^ {asserted label} (or, if result is empty set, the lowest label in some DOI) In the former case IPsec labeling matters. In the latter it does not, though you can think of it as all clients having the same label range that is equal to the union of all user label ranges. In practice I suspect the former will often be desired, so we'll need to at least support it, and to support labeled IPsec in any case. Aside: is there a notion of label range in DTE? Nico -- From dpquigl at tycho.nsa.gov Mon Oct 20 15:57:46 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 18:57:46 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <200810201200.26766.paul.moore@hp.com> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> Message-ID: <1224543466.31157.27.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 12:00 -0400, Paul Moore wrote: > On Monday 20 October 2008 11:24:48 am David P. Quigley wrote: > > On Mon, 2008-10-20 at 11:11 -0400, Paul Moore wrote: > > > On Monday 20 October 2008 3:32:10 am Jarrett Lu wrote: > > > > Jarrett Lu wrote: > > > > > On 10/17/08 07:33, David P. Quigley wrote: > > > > >> So assuming we adopt the CALIPSO DOI registry description > > > > >> (section 9.2), what is the way forward for this? I think there > > > > >> are a bunch of other issues such as initial DOI negotiation, > > > > >> proper translation, and label structure that also need to be > > > > >> addressed. > > > > > > > > > > Current MAC systems that I know about don't do DOI negotiations > > > > > at IP layer. If IP module sees a packet with a DOI it doesn't > > > > > recognize, it drops the packet. I believe that's the right > > > > > behavior. > > > > > > I agree, if a system doesn't understand a particular DOI the only > > > sane option is to drop the packet. > > > > > > > I thought about supporting multiple DOIs a bit more. I still > > > > don't believe DOI negotiations is necessary in IP, as it may add > > > > significant complexity. > > > > > > I believe that complexity is going to be very dependent on the > > > implementation and not something that is inherent in the protocol > > > design. I tend to think there might be some value in supporting > > > multiple DOIs at the IP layer and don't see it as a major handicap > > > for implementation. > > > > > > > A simple and effective way for IP to support > > > > multiple DOIs is to list all the DOIs a system could support > > > > during initialization. The list of DOIs should be small. If > > > > Labeled NFS negotiates DOIs, it's important that the DOIs which > > > > NFS can support is a subset of what IP can support. Maybe it > > > > makes sense to provide an interface so that NFS can query IP what > > > > DOI it currently supports. Do you want to use this alias to > > > > discuss design issues? > > > > From an information flow perspective it seems unsettling to me that > > we can potentially have two disjoint DOIs on two different layers. > > Why? From an information flow perspective you only care about the > meaning behind the security label. Speaking in broad terms, how the > security label is represented should not affect the enforcement of the > system's security policy, if it does then the there is a bug in the DOI > handling mechanism somewhere. After thinking this over I was wrong about this I responded to it in another email in the chain. > > > Internally to a machine the DOI needs to be consistent. > > Yep, no argument here. Regardless of if the system supports one or one > thousand DOIs it still needs to internalize the security labels to > enforce the security policy. > > > It doesn't seem right that the IP layer and Labeled NFS can > > communicated in two different DOIs on the same request. > > Why? It's the meaning behind the security label that counts, not how > the label is represented. > > > > Hmm. I still need to read Dave's latest NFS drafts (sorry Dave) > > > but last time I looked the proposed labeled NFS specification did > > > not require an form of labeled networking to operate which to me > > > indicates that the DOI space used by labeled NFS is independent of > > > the IP layer DOI space. If you happen to be sending labeled NFS > > > traffic over a labeled IP layer then it makes sense to apply some > > > sort of additional checking, not just DOI, but I believe that is > > > going to be > > > implementation specific (or perhaps it is defined in the labeled > > > NFS spec already? it wouldn't be out of place there I don't > > > think). > > > > So Pete, Steve, and I have been talking about this recently and we > > aren't 100% sold that binding the process label with the rpc request > > is the right way to go. This means we think we are going to resurrect > > the putclientlabel operation. So for a "trusted" network there is no > > requirement to protect this. However for most networks we need to > > ensure that there is a secure unbypassable channel between the client > > and the server. It seems that the way to accomplish this is through > > something like Labeled IPSec. Is it reasonable to mandate the use of > > labeled IPSec in these environments? Is it something that the working > > group will agree to leave unprotected in the "trusted" case. > > So why do you need _labeled_ IPsec? Why not just good ole fashioned > IPsec which has already been standardized? Because we want to use the label as part of the selector. In regular IPSec the selector is host pair based. We want it to be host pair based plus label based so we can assure than on a system only certain applications (in the Linux case the kernel NFS client) can talk with the server. This way we can write policy to mediate that. > > > > Regardless, while I agree that a common DOI representation is a > > > very good thing, I think trying to integrate all of the different > > > labeled security layers right now is a bit out of scope for this > > > effort (although a common DOI representation paves the way for such > > > an effort at a later date). > > > > From what I've been told the number one rule in network protocols is > > there is no "intermediate" step. Once people start using it they will > > continue to use it. So if we don't do this now what we will have is a > > hodgepodge of systems, and chances are we won't be able to convince > > people to move away from. A generic means of negotiating DOIs and > > determining how translation works seems reasonable for all layers. > > Regardless of the layer we need to determine what "language" we are > > going to speak for further communications which then determines who > > translates from what to what. The layer that this happens at is still > > to be determined but it seems like it is something that needs to be > > discussed. > > I think we have a bit of a disconnect here, it isn't clear to me if you > agree or disagree with my comment. I don't see anything in your > response which contradicts what I was (trying) to say, but then again > people rarely type so much when they agree :) > > Perhaps a good first step is to set aside discussions about specific > issues and clarify our goals/intentions for this effort. > So this was partially based on my every level should share a DOI approach which after more though I've determined isn't sensible. I agree that a common DOI representation is definitely a good place to start. One thing we need to make sure though is that we can find out what key services are needed for DOIs and IF a layer needs that service we have a set way of performing it. I don't want it to be that if Labeled NFS needs DOI negotiation (as described in my other email) and some other protocol also needs DOI negotiation that they are done in two different ways. Likewise for label translation it there should be a set way for determining who does translation in what situations. These are things that regardless of the protocol seem to be consistent. From dpquigl at tycho.nsa.gov Mon Oct 20 15:58:38 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 18:58:38 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224519250.2463.14.camel@localhost> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> Message-ID: <1224543518.31157.29.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 12:14 -0400, Bill Sommerfeld wrote: > On Mon, 2008-10-20 at 12:00 -0400, Paul Moore wrote: > > Why? From an information flow perspective you only care about the > > meaning behind the security label. Speaking in broad terms, how the > > security label is represented should not affect the enforcement of the > > system's security policy, if it does then the there is a bug in the DOI > > handling mechanism somewhere. > > this looks to me like a gap between theory and practice. > > in theory this is true. > > in practice, multiple representations aren't going to be precisely > equivalent, so conversions between representations will necessarily have > error cases ("oops, this representation doesn't have room for that many > compartment bits"). > > all this adds complexity and bugs and mysterious failures to > communicate. > > > So why do you need _labeled_ IPsec? Why not just good ole fashioned > > IPsec which has already been standardized? > > I haven't been following labeled NFS (maybe I should). If you're using > multiple labels over a single transport connection you at the very least > need some way to distinguish traffic from random user processes from > traffic from a label-aware trusted NFS client. > Exactly. I should have read your email before responding to Paul :) From dpquigl at tycho.nsa.gov Mon Oct 20 15:59:42 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 18:59:42 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020162452.GT8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> <20081020162452.GT8906@Sun.COM> Message-ID: <1224543582.31157.31.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 11:24 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 12:14:10PM -0400, Bill Sommerfeld wrote: > > > So why do you need _labeled_ IPsec? Why not just good ole fashioned > > > IPsec which has already been standardized? > > > > I haven't been following labeled NFS (maybe I should). If you're using > > multiple labels over a single transport connection you at the very least > > need some way to distinguish traffic from random user processes from > > traffic from a label-aware trusted NFS client. > > If one were using secure NFS over unlabeled IPsec with channel binding > and confidentiality protection then indeed labeling at the IPsec layer > would be unimportant -- it should suffice to have label-aware NFS > clients and servers... > > ...Unless, of course, you have middle boxes that want to see labeled > packets. In that case there's still no reason why the "outer" IP and > "inner" NFS labels need to be in the same DOI, other than for simplicity > of administration. Agreed. > > Nico From dpquigl at tycho.nsa.gov Mon Oct 20 16:07:19 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 19:07:19 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020170228.GX8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> <200810201240.16485.paul.moore@hp.com> <20081020170228.GX8906@Sun.COM> Message-ID: <1224544039.31157.40.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 12:02 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 12:40:16PM -0400, Paul Moore wrote: > > > I haven't been following labeled NFS (maybe I should). If you're > > > using multiple labels over a single transport connection you at the > > > very least need some way to distinguish traffic from random user > > > processes from traffic from a label-aware trusted NFS client. > > > > Maybe I misunderstood Dave, but I thought he was talking about carrying > > all the NFS process label information in the RPC calls which should > > disambiguate things at the RPC layer. > > Yes. > > Actually, labeled NFSv4 extensions would roughly consist of two > enhancements to NFS: > > 1) an extension (most likely at the RPC auth layer, specifically as an > RPCSEC_GSS extension) to communicate process labels; > > 2) new NFSv4 operations for getting/setting the labels of filesystem > objects. > > Nico So I think this is one thing that we need to discuss. I think the requirement here is that we need to be able to transfer access control data through NFS while insuring its integrity. From an implementation standpoint placing the process labels into each security flavor at the RPC layer seems a bit hacky. However if I can provide for the integrity of that label at the RPC layer that is a good thing. The issue we see is that we don't want to mix access control data with authentication data which I fear is something we might end up doing if we cram everything into the RPC layer. Point 2 from above stays the same but instead of transporting the process labels in the krb5 Authentication-data field or as a cert extension for IKE we provide for a method of specifying the process label in the NFSv4 request. Now we can protect this information in two ways. In environment that we can mandate use of Labeled IPSec we can use that. If that isn't an option providing integrity checking of the attribute in the way Nico suggested is not quite as strong but will work. The reason we abandoned the NFS level approach for this was because it would be a pain to implement in the Linux version of NFS. There is nothing in the NFSv4 protocol that prevents us from taking this approach. Also if a new security flavor or transport mechanism is devised for NFS we still have the process label without having take into account the new mechanisms. Dave From dpquigl at tycho.nsa.gov Mon Oct 20 16:17:46 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Mon, 20 Oct 2008 19:17:46 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020230213.GM8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <20081020230213.GM8906@Sun.COM> Message-ID: <1224544666.31157.46.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 18:02 -0500, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 03:52:47PM -0700, Jarrett Lu wrote: > > If a node asserts that it understands DOI B and C, is this an automatic > > declaration that it knows how to map between the two? Or does it > > merely says I can interpret labels with DOI B and C, but the mapping > > between the two isn't known to me? > > Or even "I can interpret labels with DOI B and C, and that says nothing > about whether I can map between them -- mapping is up to you." > > We get to choose the semantics of any DOI negotiation. > > The interesting question is: who should have the burden of DOI mapping, > if anyone? > > If the client -> let the client tell the server what DOIs it can map > between and then let the server pick one. Alternatively let the client > just know from name service lookups. > > If the server -> no negotiation -- let the client assert what it wishes > and let the server do what it can (including mapping process labels to > the lowest available, and rejecting file labels it doesn't understand). > > So we need to resolve the issue of who has this burden. > > > Are we still saying the DOI used by NFS should also be supported by > > IP module? Or are we pursuing the model that IP DOI knowledge doesn't > > matter, i.e. IP thinks it only knows DOI A; NFS client and server agree > > that DOI B is the best one. They embed file labels (with DOI B) in the > > payload so that IP doesn't actually know what's going on. I still think > > it's desirable that DOIs used by different layers are consistent. It's odd > > that a communication worked because we are successful in hinding > > the real DOI from IP module. > > Good question. I don't know. > > The server could workout process credentials and label of clients as > follows: > > - first establish the label range of the client, Rc > - then establish the credentials and label range of the client process > (RPCSEC_GSS client principal), Ru > - then evaluate Rc ^ Ru ^ {asserted label} (or, if result is empty set, > the lowest label in some DOI) > > or: > > - establish the credentials and label range of the client process > (RPCSEC_GSS client principal), Ru > - then evaluate Ru ^ {asserted label} (or, if result is empty set, the > lowest label in some DOI) > > In the former case IPsec labeling matters. In the latter it does not, > though you can think of it as all clients having the same label range > that is equal to the union of all user label ranges. > > In practice I suspect the former will often be desired, so we'll need to > at least support it, and to support labeled IPsec in any case. > > Aside: is there a notion of label range in DTE? Unfortunately(depending on your outlook) no it doesn't. One of the things in DTE that drives some people crazy is that there is no lattice for the types. So there is no strict hierarchy of what is higher than the other to do range checking on. In our case range checking would be more of a set comparision. If you wanted to say the only programs that can access this data have these types you would have to check if your process label exists in that set. SELinux labels also have an MLS portion which is ordered but you would still need to say here are the domains that are allowed. This could potentially be a powerful tool if we have this protected pipe between the client and server. You could say that the server will only release data to a domain type that is the opening of a trusted path. Dave From jon at pgpeng.com Mon Oct 20 13:12:26 2008 From: jon at pgpeng.com (Jon Callas) Date: Mon, 20 Oct 2008 13:12:26 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020163701.GU8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> Message-ID: <84937954-63F6-46C6-A615-D977B447BFCD@pgpeng.com> > > My guess: a node asserts a label in some DOI and a peer says "yes, I > know that DOI" or "no, I don't know that DOI"; that listing known DOIs > does not do any good. > > I.e., telling a node N that wanted to use DOI A that you (peer P) > support only DOIs B, C or D does that node no good because N really > wanted to use DOI A. > > And if there's a mapping between DOI A and one or more of DOIs B, C > and/or D then EITHER node N should know a priori (via configuration or > name service lookups) that P wants one of those and then N should map > accordingly, or P should know about DOI A and how to map it to one or > more of DOIs B, C and/or D. > > Right? > > If so then I agree: there's no need to negotiate DOIs. Besides being > potentially impractical (if there were too many DOIs to list), it > could > also leak information. Since we basically agree, I have a couple short comments. There are times when maximizing information is good in a security system and times when it isn't. For example, negotiating a cipher suite by stating all options is a good thing because the options are likely to be reasonably small, and the information leaked is also small. On the other hand, with a DOI, it's more likely to be large and have a large amount of information leakage gathered by blabbing. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 200 Jefferson Drive Fax: +1 (650) 319-9001 Menlo Park, CA 94025 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From Nicolas.Williams at sun.com Mon Oct 20 18:58:33 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 20:58:33 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224544666.31157.46.camel@moss-terrapins.epoch.ncsc.mil> References: <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <20081020230213.GM8906@Sun.COM> <1224544666.31157.46.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081021015833.GQ8906@Sun.COM> On Mon, Oct 20, 2008 at 07:17:46PM -0400, David P. Quigley wrote: > > Aside: is there a notion of label range in DTE? > > Unfortunately(depending on your outlook) no it doesn't. [...] > [...] In our case range checking would be > more of a set comparision. If you wanted to say the only programs that > can access this data have these types you would have to check if your > process label exists in that set. SELinux labels also have an MLS > portion which is ordered but you would still need to say here are the > domains that are allowed. This could potentially be a powerful tool if > [...] I can see that sets allow you to implement "levels" and "compartments" but I think that for ease of adoption you may want a DOI whose labels explicitly cover all three things: type/role, classification level, compartment. More than anything that would help keep administration simple. Nico -- From Nicolas.Williams at sun.com Mon Oct 20 19:06:43 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 21:06:43 -0500 Subject: [doi-discuss] Digression on SIDs (Re: DOI consistency) In-Reply-To: <1224542992.31157.19.camel@moss-terrapins.epoch.ncsc.mil> References: <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224523553.2463.90.camel@localhost> <20081020200318.GC8906@Sun.COM> <1224535867.18940.107.camel@moss-terrapins.epoch.ncsc.mil> <20081020214757.GF8906@Sun.COM> <1224542992.31157.19.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081021020642.GR8906@Sun.COM> On Mon, Oct 20, 2008 at 06:49:52PM -0400, David P. Quigley wrote: > What do you mean by SIDs. I'm guessing it is some sort of Security > Identifier which represents the file's ownership. Windows uses SIDs -- Security IDentifiers -- of a particular form. Their textual representation is: S-1----..- where is a 48-bit unsigned integer, is a 32-bit unsigned integer, and there are no more than 15 RIDs. RID stands for "Relative IDentifier" -- as in "relative to the preceding." The on-the-wire form is: a byte with value '0x01', a byte with the count of RIDs, six bytes in big-endian order representing the authority, plus N little-endian 32-bit unsigned ints. As I understand it SIDs were supposed to be hierarchical, but in practice domains get randomly-generated SIDs and users/groups are represented as RIDs relative to domain SIDs. Domain SIDs usually have the form S-1-5-21-x-y-z, where x, y, and z were randomly selected when the domain was created, so that domains are identified by 96-bits. Nico -- From Nicolas.Williams at sun.com Mon Oct 20 19:14:39 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Oct 2008 21:14:39 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224543518.31157.29.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> <1224543518.31157.29.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081021021439.GS8906@Sun.COM> On Mon, Oct 20, 2008 at 06:58:38PM -0400, David P. Quigley wrote: > On Mon, 2008-10-20 at 12:14 -0400, Bill Sommerfeld wrote: > > I haven't been following labeled NFS (maybe I should). If you're using > > multiple labels over a single transport connection you at the very least > > need some way to distinguish traffic from random user processes from > > traffic from a label-aware trusted NFS client. > > Exactly. I should have read your email before responding to Paul :) Oh, this rings bells. I just noticed that draft-stjohns-sipso-05 would have TCP/IP individually label the packets of a single TCP connection carrying NFS traffic for multiple users such that each packet for that connection: a) carries data from a single NFS RPC b) is labelled according to the user process on behalf of which the client is sending that NFS RPC. My initial reaction is that that's asking a lot of TCP. I suppose that running multiple TCP connections, each at a single label might scale worse than tracking {label, offset, length} in TCP buffers, but that depends on how many distinct labels are used on a given client. Either way it seems to me that the only reason for any of this is to let middle boxes inspect the label of each RPC, but there's an alternative: plain old IPsec, and let the middleboxes eat cake. Nico -- From dpquigl at tycho.nsa.gov Tue Oct 21 08:17:38 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Tue, 21 Oct 2008 11:17:38 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <84937954-63F6-46C6-A615-D977B447BFCD@pgpeng.com> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <84937954-63F6-46C6-A615-D977B447BFCD@pgpeng.com> Message-ID: <1224602258.31157.49.camel@moss-terrapins.epoch.ncsc.mil> On Mon, 2008-10-20 at 13:12 -0700, Jon Callas wrote: > > > > My guess: a node asserts a label in some DOI and a peer says "yes, I > > know that DOI" or "no, I don't know that DOI"; that listing known DOIs > > does not do any good. > > > > I.e., telling a node N that wanted to use DOI A that you (peer P) > > support only DOIs B, C or D does that node no good because N really > > wanted to use DOI A. > > > > And if there's a mapping between DOI A and one or more of DOIs B, C > > and/or D then EITHER node N should know a priori (via configuration or > > name service lookups) that P wants one of those and then N should map > > accordingly, or P should know about DOI A and how to map it to one or > > more of DOIs B, C and/or D. > > > > Right? > > > > If so then I agree: there's no need to negotiate DOIs. Besides being > > potentially impractical (if there were too many DOIs to list), it > > could > > also leak information. > > > Since we basically agree, I have a couple short comments. > > There are times when maximizing information is good in a security > system and times when it isn't. For example, negotiating a cipher > suite by stating all options is a good thing because the options are > likely to be reasonably small, and the information leaked is also > small. On the other hand, with a DOI, it's more likely to be large and > have a large amount of information leakage gathered by blabbing. > > Jon > > In another email I clarified what I meant by negotiation and the system I described is closer to your first example. By negotiation I meant both sides say these are the DOIs I understand and based on that and other policy information they can determine the best one to speak in. I didn't mean to imply that they can magically establish mappings which would leak more information than necessary. Dave From sommerfeld at sun.com Tue Oct 21 12:30:15 2008 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Tue, 21 Oct 2008 15:30:15 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081021021439.GS8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> <1224543518.31157.29.camel@moss-terrapins.epoch.ncsc.mil> <20081021021439.GS8906@Sun.COM> Message-ID: <1224617415.21685.35.camel@localhost> On Mon, 2008-10-20 at 21:14 -0500, Nicolas Williams wrote: > > I just noticed that draft-stjohns-sipso-05 would have TCP/IP > individually label the packets of a single TCP connection carrying NFS > traffic for multiple users it says no such thing -- see section 6.2.1 of that document, which reads in part: NOTE WELL: A connection-oriented transport-layer protocol session (e.g. TCP session, SCTP session) MUST have the same DOI and same Sensitivity Label for the life of that connection. The DOI is selected at connection initiation and MUST NOT change during the session. - Bill From Nicolas.Williams at sun.com Tue Oct 21 12:34:12 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 21 Oct 2008 14:34:12 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224617415.21685.35.camel@localhost> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> <1224543518.31157.29.camel@moss-terrapins.epoch.ncsc.mil> <20081021021439.GS8906@Sun.COM> <1224617415.21685.35.camel@localhost> Message-ID: <20081021193411.GZ8906@Sun.COM> On Tue, Oct 21, 2008 at 03:30:15PM -0400, Bill Sommerfeld wrote: > On Mon, 2008-10-20 at 21:14 -0500, Nicolas Williams wrote: > > > > I just noticed that draft-stjohns-sipso-05 would have TCP/IP > > individually label the packets of a single TCP connection carrying NFS > > traffic for multiple users > > it says no such thing -- see section 6.2.1 of that document, which reads > in part: > > NOTE WELL: > A connection-oriented transport-layer protocol session > (e.g. TCP session, SCTP session) MUST have the same DOI and > same Sensitivity Label for the life of that connection. The > DOI is selected at connection initiation and MUST NOT change > during the session. Ah, thanks for the clarification. I read much too much into the last paragraph of section 1.1. From Jarrett.Lu at Sun.COM Tue Oct 21 12:45:49 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Tue, 21 Oct 2008 12:45:49 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224542372.31157.8.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <1224542372.31157.8.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <48FE316D.2050407@sun.com> On 10/20/08 15:39, David P. Quigley wrote: > On Mon, 2008-10-20 at 15:52 -0700, Jarrett Lu wrote: > >> Nicolas Williams wrote: >> >>> On Mon, Oct 20, 2008 at 04:45:25PM -0400, David P. Quigley wrote: >>> >>> >>>> I should clarify what I mean by negotiation because it seems to be a >>>> point of confusion. I'm not saying that if one endpoint knows about DOI >>>> A and the other does not that the side that is unaware of DOI A should >>>> be able to negotiate the mapping for it. What I am saying is that at >>>> connection time both sides should say we support these DOIs and then >>>> they can make a conscious policy decision based on this information as >>>> to which one to use. What happens if both of the endpoints support both >>>> B and C? One side should be able to say you know what C is better for >>>> our uses than B we should go with that. By the one end asserting an >>>> arbitrary DOI you don't get this ability. An example of this might be if >>>> both sides natively use C but for some reason one end is asserting B. >>>> >>>> >>> OK, so node N could and should know about peer P's preferences, but it >>> happens that it does not, and so if only P could tell N what those >>> preferences are, then N could pick the best DOI mapping? >>> >>> I can see that. It simplifies client/name service configuration. It >>> still puts the onus for DOI mapping on clients. And it presumes that >>> such a thing (mappings between DOIs) is possible. >>> >>> >> If a node asserts that it understands DOI B and C, is this an automatic >> declaration that it knows how to map between the two? Or does it >> merely says I can interpret labels with DOI B and C, but the mapping >> between the two isn't known to me? >> > > Understanding B and C means that I can take a label of DOI B or C and > translate it into my local DOI. Whatever that means. I'm not sure if > there is a use for me exporting the fact that I transmit labels in B or > C but internally use A. I'm going to need to sit down with some people > here and get some more insight into what we've seen and what we think > the right way to handle this is. > I am curious about the notion of "my local DOI" which could be different from any DOIs on the packets. That means every system needs to do at least one DOI translation (note; I'm using mapping and DOI translation interchangeably here), i.e. systems that understand only one DOI, which could very well be the majority of MAC systems out there, have to get into the business of DOI translation. I found this burden on single DOI system unnecessary. A node should be able to communicate labels (or other MAC attributes) using DOI B with other systems that also understand DOI B. It should treat DOI B as "my local DOI" as that's the one it understands. I don't see sufficient benefit to force a translation from B to "my local DOI". If a node understands multiple DOIs, it should take actions based on its function. For example, a router could simply forward a packet out on a network interface with matching DOI; an NFS server could translate a label from one DOI to a different DOI, etc.. > >> Are we still saying the DOI used by NFS should also be supported by >> IP module? Or are we pursuing the model that IP DOI knowledge doesn't >> matter, i.e. IP thinks it only knows DOI A; NFS client and server agree >> that DOI B is the best one. They embed file labels (with DOI B) in the >> payload so that IP doesn't actually know what's going on. I still think >> it's desirable that DOIs used by different layers are consistent. It's odd >> that a communication worked because we are successful in hinding >> the real DOI from IP module. >> >> > > So I think I was wrong in asserting that a DOI at the IP and Labeled NFS > level should be the same. It seems like it isn't really practical and it > would be an administrative nightmare. Also this will potentially leak > information across the levels that doesn't need to be. > Depending on how complex the DOI negotiation protocol is, I'm not convinced it has to be an administrative nightmare. If NFS and IP labeling are completely disjoint, you run the risk that NFS may never see a packet when IP enforces filtering and decides to drop the packets with "wrong DOIs". I understand IP can't easily peek into NFS packets to inspect DOIs. But if IP is made aware that DOI B and C are what it supports, that should be sufficient. What kind of information leak are you concerned about? Jarrett -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jarrett.Lu at Sun.COM Tue Oct 21 12:56:44 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Tue, 21 Oct 2008 12:56:44 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <20081020230213.GM8906@Sun.COM> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <20081020230213.GM8906@Sun.COM> Message-ID: <48FE33FC.2090707@sun.com> On 10/20/08 16:02, Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 03:52:47PM -0700, Jarrett Lu wrote: > >> If a node asserts that it understands DOI B and C, is this an automatic >> declaration that it knows how to map between the two? Or does it >> merely says I can interpret labels with DOI B and C, but the mapping >> between the two isn't known to me? >> > > Or even "I can interpret labels with DOI B and C, and that says nothing > about whether I can map between them -- mapping is up to you." > > We get to choose the semantics of any DOI negotiation. > > The interesting question is: who should have the burden of DOI mapping, > if anyone? > > If the client -> let the client tell the server what DOIs it can map > between and then let the server pick one. Alternatively let the client > just know from name service lookups. > > If the server -> no negotiation -- let the client assert what it wishes > and let the server do what it can (including mapping process labels to > the lowest available, and rejecting file labels it doesn't understand). > There may be a confusion between the term "mapping" and "DOI translation". When a server can't interpret an DOI, mapping a label to the lowest level doesn't actually help. The "lowest" in one DOI may not be the "lowest" or even defined in other DOI. I lean towards having server do DOI translation. It seems to simply things. Besides simpler negotiation scheme, an MLS NFS server already knows how to serve multiple single level clients, serving clients with different DOIs may be a more natural extension. Jarrett -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicolas.Williams at sun.com Thu Oct 23 12:30:57 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Oct 2008 14:30:57 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224602258.31157.49.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <84937954-63F6-46C6-A615-D977B447BFCD@pgpeng.com> <1224602258.31157.49.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081023193057.GM21103@Sun.COM> On Tue, Oct 21, 2008 at 11:17:38AM -0400, David P. Quigley wrote: > In another email I clarified what I meant by negotiation and the system > I described is closer to your first example. By negotiation I meant both > sides say these are the DOIs I understand and based on that and other > policy information they can determine the best one to speak in. I didn't > mean to imply that they can magically establish mappings which would > leak more information than necessary. Although that wouldn't necessarily be out of the question either. I can see several kinds of mappings: - Mappings between different-but-semantically-similar DOIs - such as mappings between deprecated and replacement DOIs - or mappings between DTE DOIs historically constructed separately but for the same apps and same roles This warrants negotiation only if it is the client that must do the mapping. I think it will be easier to deploy server-does-mapping. But I'm not sufficiently sure. To avoid having to add DOI negotiation later, but also to avoid having it be a requirement, let's just make DOI negotiation an option. - Mappings between on-the-wire and server-internal DOIs. This is an internal detail warranting no negotiation, of course. Nico -- From Nicolas.Williams at sun.com Thu Oct 23 12:40:44 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Oct 2008 14:40:44 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224543466.31157.27.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <200810201111.46322.paul.moore@hp.com> <1224516288.18940.94.camel@moss-terrapins.epoch.ncsc.mil> <200810201200.26766.paul.moore@hp.com> <1224543466.31157.27.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081023194044.GN21103@Sun.COM> On Mon, Oct 20, 2008 at 06:57:46PM -0400, David P. Quigley wrote: > > So why do you need _labeled_ IPsec? Why not just good ole fashioned > > IPsec which has already been standardized? > > Because we want to use the label as part of the selector. In regular > IPSec the selector is host pair based. We want it to be host pair based > plus label based so we can assure than on a system only certain > applications (in the Linux case the kernel NFS client) can talk with the > server. This way we can write policy to mediate that. In other words: you need outer IP labelling for the benefit of middle boxes, even though IPsec provides enough protection anyways (label-aware middle boxes may add a measure of protection against traffic analysis, so it's not entirely pointless when using IPsec anyways). This says nothing about whether IP and NFS must use the same DOIs. I could see IP using an MLS DOI and NFS using a DTE DOI, weird as that would be. > > Perhaps a good first step is to set aside discussions about specific > > issues and clarify our goals/intentions for this effort. > > So this was partially based on my every level should share a DOI > approach which after more though I've determined isn't sensible. I agree > that a common DOI representation is definitely a good place to start. > One thing we need to make sure though is that we can find out what key > services are needed for DOIs and IF a layer needs that service we have a > set way of performing it. I don't want it to be that if Labeled NFS > needs DOI negotiation (as described in my other email) and some other > protocol also needs DOI negotiation that they are done in two different > ways. Likewise for label translation it there should be a set way for > determining who does translation in what situations. These are things > that regardless of the protocol seem to be consistent. For DOI negotiation/identification integers + a registration authority will do. As would OIDs, domainnames, ... IIUC integers are used in various protocols already, right? W.r.t. label mapping, that's an implementation-specific problem. The implementation needs to understand labels in the various DOIs and mapping rules. Nico -- From Nicolas.Williams at sun.com Thu Oct 23 12:49:48 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Oct 2008 14:49:48 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1224544039.31157.40.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <200810201200.26766.paul.moore@hp.com> <1224519250.2463.14.camel@localhost> <200810201240.16485.paul.moore@hp.com> <20081020170228.GX8906@Sun.COM> <1224544039.31157.40.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081023194948.GO21103@Sun.COM> On Mon, Oct 20, 2008 at 07:07:19PM -0400, David P. Quigley wrote: > So I think this is one thing that we need to discuss. I think the > requirement here is that we need to be able to transfer access control > data through NFS while insuring its integrity. From an implementation > standpoint placing the process labels into each security flavor at the > RPC layer seems a bit hacky. However if I can provide for the integrity > of that label at the RPC layer that is a good thing. The issue we see is > that we don't want to mix access control data with authentication data > which I fear is something we might end up doing if we cram everything > into the RPC layer. I'm a fan of moving session protection down to the lowest end-to-end layer and authentication up to the application layer, with channel binding to detect MITMs. That would argue for moving authentication from RPCSEC_GSS to NFS. And for putting process label assertion in the NFS layer too. But in this case I don't think that's necessary, and I think it will be a lot easier in terms of both, specification and implementation work, to add a new flavor of RPCSEC_GSS than to add operations to do deal with authentication and label assertion at the NFS layer. If nothing else there's an opportunity to solve related problems at the same. Note that I'm *not* arguing for using Kerberos V authorization-data in the AP-REQ authenticator for process label assertions (which would require mechanism work), much less authorization-data the Ticket (which would require client and KDC work as well as acceptor work). > [...] > There is nothing in the NFSv4 protocol that prevents us from taking this > approach. Also if a new security flavor or transport mechanism is > devised for NFS we still have the process label without having take into > account the new mechanisms. No new GSS mechanisms are needed. Nor GSS mechanism work. Either RPCSEC_GSS work (a new version) or NFSv4 work will do, with the former being more general and requiring less change (possibly none) to the NFS client and server implementations (in the case of Solaris that'd be zero change to either the client or the server, just the RPCSEC_GSS work). Nico -- From dpquigl at tycho.nsa.gov Wed Oct 29 14:43:03 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Wed, 29 Oct 2008 17:43:03 -0400 Subject: [doi-discuss] DOI consistency In-Reply-To: <48FE316D.2050407@sun.com> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <1224542372.31157.8.camel@moss-terrapins.epoch.ncsc.mil> <48FE316D.2050407@sun.com> Message-ID: <1225316583.31157.268.camel@moss-terrapins.epoch.ncsc.mil> On Tue, 2008-10-21 at 12:45 -0700, Jarrett Lu wrote: [Snip] > > I am curious about the notion of "my local DOI" which could be > different from > any DOIs on the packets. That means every system needs to do at least > one DOI > translation (note; I'm using mapping and DOI translation > interchangeably here), > i.e. systems that understand only one DOI, which could very well be > the majority > of MAC systems out there, have to get into the business of DOI > translation. I > found this burden on single DOI system unnecessary. A node should be > able > to communicate labels (or other MAC attributes) using DOI B with other > systems > that also understand DOI B. It should treat DOI B as "my local DOI" as > that's > the one it understands. I don't see sufficient benefit to force a > translation from B > to "my local DOI". If a node understands multiple DOIs, it should take > actions > based on its function. For example, a router could simply forward a > packet out > on a network interface with matching DOI; an NFS server could > translate a label > from one DOI to a different DOI, etc.. > [Snip] So I am working on slides for IETF and this question seems like something I might be asked. When I say that a machine can handle multiple DOIs I see this as meaning that we have one DOI that is used internally we prefer to use. I may or may not want to indicate to other systems that I support this DOI so I will probably need at least one translation if I choose to withhold this information. It seems reasonable though that if we have an environment where most systems speak in the same DOI that this won't be the case. I am curious how other people see the concept of supporting multiple DOIs. Dave From sommerfeld at sun.com Wed Oct 29 15:52:19 2008 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Wed, 29 Oct 2008 15:52:19 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <1225316583.31157.268.camel@moss-terrapins.epoch.ncsc.mil> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <1224542372.31157.8.camel@moss-terrapins.epoch.ncsc.mil> <48FE316D.2050407@sun.com> <1225316583.31157.268.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <1225320739.1108.42.camel@localhost> On Wed, 2008-10-29 at 17:43 -0400, David P. Quigley wrote: > When I say that a machine can handle > multiple DOIs I see this as meaning that we have one DOI that is used > internally we prefer to use. I may or may not want to indicate to other > systems that I support this DOI so I will probably need at least one > translation if I choose to withhold this information. It seems > reasonable though that if we have an environment where most systems > speak in the same DOI that this won't be the case. I am curious how > other people see the concept of supporting multiple DOIs. I think that's pretty fair. I see the multiple-DOI case being needed at boundaries -- you have one network using one DOI, another network using a second DOI, and you need data to flow between them with labels attached. Perhaps another way of looking at it is that the "doi identifier" is part of an external label representation; A single abstract label may well be present in multiple DOIs but may be represented differently in each DOI. - Bill From Jarrett.Lu at Sun.COM Wed Oct 29 16:30:57 2008 From: Jarrett.Lu at Sun.COM (Jarrett Lu) Date: Wed, 29 Oct 2008 16:30:57 -0700 Subject: [doi-discuss] DOI consistency In-Reply-To: <1225320739.1108.42.camel@localhost> References: <48F7CCDB.70605@sun.com> <48F90799.2080808@sun.com> <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <1224542372.31157.8.camel@moss-terrapins.epoch.ncsc.mil> <48FE316D.2050407@sun.com> <1225316583.31157.268.camel@moss-terrapins.epoch.ncsc.mil> <1225320739.1108.42.camel@localhost> Message-ID: <4908F231.6010303@sun.com> Bill Sommerfeld wrote: > On Wed, 2008-10-29 at 17:43 -0400, David P. Quigley wrote: > >> When I say that a machine can handle >> multiple DOIs I see this as meaning that we have one DOI that is used >> internally we prefer to use. I may or may not want to indicate to other >> systems that I support this DOI so I will probably need at least one >> translation if I choose to withhold this information. It seems >> reasonable though that if we have an environment where most systems >> speak in the same DOI that this won't be the case. I am curious how >> other people see the concept of supporting multiple DOIs. >> > > I think that's pretty fair. > > I see the multiple-DOI case being needed at boundaries -- you have one > network using one DOI, another network using a second DOI, and you need > data to flow between them with labels attached. > > Perhaps another way of looking at it is that the "doi identifier" is > part of an external label representation; > > A single abstract label may well be present in multiple DOIs but may be > represented differently in each DOI. > Two multiple DOI scenarios have been discussed so far. One is the "boundary" case, where a router needs to forward packets labeled with different DOIs. The label aware router may not need to translate labels if all it does is to ensure labeled traffic is forwarded out on the correct interfaces, e.g foo-doi-1 out on interface-1, bar-doi-2 out on interface-2, etc.. The other case is that some application above IP module actually interprets labeled data. For example, an application can filter data labeled with foo-doi-1; then forwarding the same data onto a different network using label bar-doi-2. Label translation is required in the latter case. LNFS is similar to the latter case. For example, a server understand two DOIs and knows how to translate labels between them. It serves clients' request with the DOI the client understands. Someone argued that the DOIs used by Labeled NFS and labeled IP module should be completely disjoint. I'm still concerned about that. Allowing disjointly labeled traffic flowing in a labeled network sounds like a MAC violation to me. On Dave's multiple DOI interpretation, I have no problem that some one always does one translation between your own native DOI and network DOI (in fact you can as many translations as you like ;-) ). I don't see a lot of value in that. Systems communicating with same DOI assume some trust among them. So, as long as you don't mandate such a translation, I have no problem. BTW, the CALIPSO draft's notion of supporting multiple DOI is that a system should support at least two on the wire DOIs. Jarrett > - Bill > > > > > > From Nicolas.Williams at sun.com Wed Oct 29 16:31:16 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 29 Oct 2008 18:31:16 -0500 Subject: [doi-discuss] DOI consistency In-Reply-To: <1225316583.31157.268.camel@moss-terrapins.epoch.ncsc.mil> References: <48FC33FA.5020707@sun.com> <200810201111.46322.paul.moore@hp.com> <1224517683.2463.7.camel@localhost> <20081020163701.GU8906@Sun.COM> <1224535525.18940.102.camel@moss-terrapins.epoch.ncsc.mil> <20081020211738.GE8906@Sun.COM> <48FD0BBF.4000400@sun.com> <1224542372.31157.8.camel@moss-terrapins.epoch.ncsc.mil> <48FE316D.2050407@sun.com> <1225316583.31157.268.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20081029233116.GY102869@Sun.COM> On Wed, Oct 29, 2008 at 05:43:03PM -0400, David P. Quigley wrote: > So I am working on slides for IETF and this question seems like > something I might be asked. When I say that a machine can handle > multiple DOIs I see this as meaning that we have one DOI that is used > internally we prefer to use. I may or may not want to indicate to other > systems that I support this DOI so I will probably need at least one > translation if I choose to withhold this information. It seems > reasonable though that if we have an environment where most systems > speak in the same DOI that this won't be the case. I am curious how > other people see the concept of supporting multiple DOIs. Scenarios I can imagine: 1) DOI mapping scenarios: a) Single-DOI clients, multi-DOI NAS servers; servers map between DOIs. Think of transitions from legacy to new DOIs, or mapping between different-but-semantically-similar DTE DOIs. b) Single-DOI NAS servers, multi-DOI clients; clients map between DOIs. 2) Multiple, distinct, never-the-twain-shall-meet DOIs exist. Here you can just think of the server (or even client) as being virtualized, with each domain/zone/whatever speaking only one DOI. (2) is uninteresting here. If you care about (2) use virtualization technology. (1) is interesting. I doubt (1b) is likely. If you drop (1b) then you don't ever need to negotiate DOIs. Nico --