* [RFC 1/2] labeled ipsec internet drafts
@ 2008-07-25 17:51 Joy Latten
2008-07-26 16:34 ` Paul Moore
0 siblings, 1 reply; 23+ messages in thread
From: Joy Latten @ 2008-07-25 17:51 UTC (permalink / raw)
To: selinux; +Cc: gcwilson, serue, tjaeger
My apologies if you have already received copies of this.
I sent this email out earlier this week, but it appears to
have never arrived to selinux mailing list, so trying again
without attachments.
regards,
Joy
----------------------------------------------------------------------------
I have attached two internet drafts for labeled ipsec for the community's
review if interested.
I have not yet submitted to IETF. I'd need comments by next
Thursday (July 31) so I can incorporate any comments before submitting.
There are two drafts because IKEv1 was obsoleted by IKEv2, but most
are still using IKEv1. I also noticed some recent IPsec rfcs, particularly
those proposing algorithm suites sometimes referred to IKEv1 also,
although it has been obsoleted. So just in case, there is a draft for
IKEv1 too. It didn't seem the drafts could be merged since ikev1 and ikev2
are different.
Lastly, IPsec architecture rfc 2401 was obsoleted by rfc 4301.
2401, section 8 supported "MLS networking" within IPsec. All this was
removed from rfc 4301. Thus the labeled ipsec draft for ikev2,
reintroduces mls networking as MAC Networking and is longer.
Please let me know if anything is missing or could be improved.
Thanks!
regards,
Joy
---------------------------------------------------------------
Network Working Group J. Latten
Internet-Draft G. Wilson
Intended Status: Standards Track S. Hallyn
Expires: ? IBM
T. Jaeger
Penn State
June 2008
Security Label Addendum to
IPsec Domain of Interpretation (DOI)
for Internet Security Association
and Key Management Protocol (ISAKMP)
draft-jml-ipsec-ikev1-security-label-00
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008)
Abstract
This document describes the need for and the use of a security label
within IPsec. It describes the extension to the Internet IP Security
Latten, et al. Expires ? [Page 1]
\f
Internet-Draft IKEv1SecurityLabel June 2008
Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet
Security Association and Key Management Protocol (ISAKMP) [RFC2408].
This extension supports the negotiation of the security label for a
particular IP Authentication Header (AH) [RFC4302] or IP
Encapsulating Security Payload (ESP) [RFC4303] security association.
1. Introduction
Traditionally, security context referred to the security level and
category used by Multilevel Security (MLS). This document will refer
to the security level and category as the security classification.
Current security mechanisms, such as SELinux, use the security
classification and additional security attributes to form their
security context. For example, a type for type enforcement.
Techniques such as IP Security Options (IPSO) allow IP datagrams to
be labeled with an MLS security classification [RFC1108]. This
ensured the same security applied to local objects and resources was
utilized when communicating over the network with homogenous systems.
However, these techniques cannot pass along the additional security
attributes used in current security mechanisms.
The ISAKMP specification defines a Situation field in the Security
Association payload [RFC2408]. The IPsec DOI describes the use of
this field to communicate sensitivity and integrity classification
information between initiator and responder when negotiating a
security association [RFC2407]. However, it does not provide for
additional security attributes that may be required by the security
mechanism being deployed in the environment.
This document describes the additions to the IPsec DOI for ISAKMP
that are needed to support communication of additional security
attributes between two hosts, in particular a security label.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Latten, et al. Expires ? [Page 2]
\f
Internet-Draft IKEv1SecurityLabel June 2008
3. IPsec Security Association Attribute
The following SA attribute definition is used in Phase II of an
Internet Key Exchange Protocol (IKE) negotiation that includes a
security label. The attribute type is Variable-Length (V).
Encoding of attributes is defined in the base ISAKMP specification
[RFC2408].
Attribute Type
class value type
------------------------------------------------------
Security Label ? V
Class Values
Security Label
Specifies that the security association is being negotiated
in an environment that requires labeled security. This field
will contain the security label.
The security label has the following format.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| doi | algorithm | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| security label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Security Label format
- doi (1 octet) - The first octet contains the security label's
domain of interpretation.
The domain of interpretation can be viewed as a group of
systems that agree on the meaning of particular values within
the security label of a security mechanism.
The value of 1 is reserved as the default.
Reserved 0
Default 1
- algorithm (1 octet) - The second octet contains the security
label's algorithm.
Latten, et al. Expires ? [Page 3]
\f
Internet-Draft IKEv1SecurityLabel June 2008
The security label's algorithm specifies the security
mechanism or context in which the label is applicable. For
example, the security label is interpreted within the SELinux
context.
Requests for assignment of additional algorithms should be
addressed to the Internet Assigned Numbers Authority (IANA).
Reserved 0
SELinux 1
Smack 2
Private Use 120-128
- length (2 octets) - The third and fourth octets contain the
string length of the security context.
- security label (1 or more octets) - The security label. The
actual content will be dependent on the security algorithm
that is specified. Within IKE context, this is regarded as
an opaque bit string.
3. Attribute Negotiation
If an implementation receives an IPsec DOI attribute or attribute
value that it does not support, it SHOULD send an
ATTRIBUTES-NOT-SUPPORT and the security association negotiation
and setup MUST be aborted.
4. Security Considerations
This document describes an extension to IKE [RFC2409] and ISAKMP
[RFC2408] protocols. The use of the described security label should
not change the basic security features of the two.
The IPsec DOI describes a Situation field whose values can be
SIT_SECRECY and/or SIT_INTEGRITY. When SIT_SECRECY is used, it
indicates an environment requiring labeled secrecy and is
followed with sensitivity label. When SIT_INTEGITY is used,
it indicates an environment requiring labeled integrity and
is followed with integrity information.
SIT_SECRECY and SIT_INTEGRITY themselves indicate the use of
a security label and therefore the security attribute described
in this document MUST NOT be used in conjunction with either.
The new security attribute extends the existing security
mechanism to allow for additional interpretations of a security
label and not just those defined by SIT_SECRECY and SIT INTEGRITY.
It is possible that the sensitivity level and/or integrity level are
Latten, et al. Expires ? [Page 4]
\f
Internet-Draft IKEv1SecurityLabel June 2008
included in the security label defined by the security algorithm
using the new security attribute.
5. IANA Considerations
This document contains two new "magic numbers" which are allocated
and maintained by IANA registry.
- The class value for the security label attribute.
class value type
-----------------------------------------
Security Label ? V
Only one value assigned by IANA is required.
- The value for the security algorithm.
SELinux 1(?)
Smack 2(?)
Additional values may be assigned by IANA for the
security mechanisms requiring IKE to communicate its
security label.
Acknowledgements
The authors would like to thank Stephen Smalley, James Morris and
the SELinux community for their work on labeled ipsec.
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and
J. Turner, "Internet Security Association and Key
Management Protocol", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange",
RFC 2409, November 1998.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
Latten, et al. Expires ? [Page 5]
\f
Internet-Draft IKEv1SecurityLabel June 2008
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Informative references
[RFC1108] Kent, S., "U.S. DoD Security Options for the Internet
Protocol, RFC 1108, November 1991.
Authors' Addresses
Joy Latten
IBM
email: latten@austin.ibm.com
George Wilson
IBM
email: gcwilson@us.ibm.com
Serge Hallyn
IBM
email: serue@us.ibm.com
Trent Jaeger
Penn State
email: tjaeger@cse.psu.edu
Latten, et al. Expires ? [Page 6]
\f
Internet-Draft IKEv1SecurityLabel June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Latten, et al. Expires ? [Page 7]
\f
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-07-25 17:51 Joy Latten
@ 2008-07-26 16:34 ` Paul Moore
0 siblings, 0 replies; 23+ messages in thread
From: Paul Moore @ 2008-07-26 16:34 UTC (permalink / raw)
To: Joy Latten
Cc: selinux, gcwilson, serue, tjaeger, linux-security-module, netdev
On Friday 25 July 2008 1:51:19 pm Joy Latten wrote:
> I have attached two internet drafts for labeled ipsec for the
> community's review if interested.
>
> I have not yet submitted to IETF. I'd need comments by next
> Thursday (July 31) so I can incorporate any comments before
> submitting.
I'm CC'ing the LSM and netdev lists because there are some smart people
there too that might want to comment on these proposed specifications.
Otherwise my comments are below.
> There are two drafts because IKEv1 was obsoleted by IKEv2, but most
> are still using IKEv1. I also noticed some recent IPsec rfcs,
> particularly those proposing algorithm suites sometimes referred to
> IKEv1 also, although it has been obsoleted. So just in case, there is
> a draft for IKEv1 too. It didn't seem the drafts could be merged
> since ikev1 and ikev2 are different.
>
> Lastly, IPsec architecture rfc 2401 was obsoleted by rfc 4301.
> 2401, section 8 supported "MLS networking" within IPsec. All this was
> removed from rfc 4301. Thus the labeled ipsec draft for ikev2,
> reintroduces mls networking as MAC Networking and is longer.
>
> Please let me know if anything is missing or could be improved.
> Thanks!
>
> regards,
> Joy
>
> ---------------------------------------------------------------
>
>
>
>
>
> Network Working Group J. Latten
> Internet-Draft G. Wilson
> Intended Status: Standards Track S. Hallyn
> Expires: ? IBM
> T. Jaeger
> Penn State
> June 2008
>
> Security Label Addendum to
> IPsec Domain of Interpretation (DOI)
> for Internet Security Association
> and Key Management Protocol (ISAKMP)
>
> draft-jml-ipsec-ikev1-security-label-00
>
> Status of This Memo
>
> By submitting this Internet-Draft, each author represents that any
> applicable patent or other IPR claims of which he or she is aware
> have been or will be disclosed, and any of which he or she becomes
> aware will be disclosed, in accordance with Section 6 of BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other documents
> at any time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress".
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on December, 2008.
>
> Copyright Notice
>
> Copyright (C) The IETF Trust (2008)
>
> Abstract
>
> This document describes the need for and the use of a security
> label within IPsec. It describes the extension to the Internet IP
> Security
>
>
>
> Latten, et al. Expires ? [Page
> 1]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet
> Security Association and Key Management Protocol (ISAKMP)
> [RFC2408]. This extension supports the negotiation of the security
> label for a particular IP Authentication Header (AH) [RFC4302] or IP
> Encapsulating Security Payload (ESP) [RFC4303] security
> association.
>
> 1. Introduction
>
> Traditionally, security context referred to the security level and
Should this be "security label" instead of "security context"?
> category used by Multilevel Security (MLS). This document will
This should probably bet "category set" or something similar.
> refer to the security level and category as the security
> classification.
Do you mean "MLS security classification"? That "MLS" qualifier helps
make it a bit more concrete and appears to match how you actually use
it in the document.
>
> Current security mechanisms, such as SELinux, use the security
> classification and additional security attributes to form their
> security context. For example, a type for type enforcement.
>
> Techniques such as IP Security Options (IPSO) allow IP datagrams
> to be labeled with an MLS security classification [RFC1108]. This
> ensured the same security applied to local objects and resources was
> utilized when communicating over the network with homogenous systems.
I think you should either remove the "homogeneous" qualifier or change
it to heterogeneous. We've seen both different MLS implementations as
well as MLS/Type-Enforcement implementations interoperate using IP
options; granted it was with CIPSO and not RFC1108 but they are similar
enough for this level of discussion.
> However, these techniques cannot pass along the additional security
> attributes used in current security mechanisms.
This is an intersting point and the following argument may be a bit
contentious, but arguably you could encode random security contexts
into a traditional MLS security context; Smack is a shining example of
this as it encodes the generic Smack label into a CIPSO permissive
bitmap tag. It may violate the spirit of the CIPSO specification but
it is valid and provides a strong counterexample.
Further, the FIPS-188 specification, while not an IETF specification,
does provide for a "freeform" IP option which is intended to support
arbitrary security attributes.
> The ISAKMP specification defines a Situation field in the Security
> Association payload [RFC2408]. The IPsec DOI describes the use of
> this field to communicate sensitivity and integrity classification
> information between initiator and responder when negotiating a
> security association [RFC2407]. However, it does not provide for
> additional security attributes that may be required by the
> security mechanism being deployed in the environment.
>
> This document describes the additions to the IPsec DOI for ISAKMP
> that are needed to support communication of additional security
> attributes between two hosts, in particular a security label.
>
> 2. Terminology
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this document are to be interpreted as described in [RFC2119].
>
>
>
>
>
>
>
>
>
>
>
> Latten, et al. Expires ? [Page
> 2]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> 3. IPsec Security Association Attribute
>
> The following SA attribute definition is used in Phase II of an
> Internet Key Exchange Protocol (IKE) negotiation that includes a
> security label. The attribute type is Variable-Length (V).
> Encoding of attributes is defined in the base ISAKMP
> specification [RFC2408].
>
> Attribute Type
>
> class value type
> ------------------------------------------------------
> Security Label ? V
>
> Class Values
>
> Security Label
>
> Specifies that the security association is being negotiated
> in an environment that requires labeled security. This field
> will contain the security label.
> The security label has the following format.
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | doi | algorithm | length
> | |
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | security label (variable)
> | |
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 1: Security Label format
>
> - doi (1 octet) - The first octet contains the security
> label's domain of interpretation.
>
> The domain of interpretation can be viewed as a group of
> systems that agree on the meaning of particular values
> within the security label of a security mechanism.
>
> The value of 1 is reserved as the default.
>
> Reserved 0
> Default 1
>
> - algorithm (1 octet) - The second octet contains the security
> label's algorithm.
>
>
>
>
> Latten, et al. Expires ? [Page
> 3]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> The security label's algorithm specifies the security
> mechanism or context in which the label is applicable. For
> example, the security label is interpreted within the
> SELinux context.
>
> Requests for assignment of additional algorithms should be
> addressed to the Internet Assigned Numbers Authority (IANA).
>
> Reserved 0
> SELinux 1
> Smack 2
> Private Use 120-128
Is one octet enough here? I honestly don't have a good idea as to how
much is enough, so a little justification of your choice (even if it
only lives in email, not in the spec) would be welcome.
I'm also concerned with the implied convention of assigning one value to
a particular implementation. In the SELinux case, how do you deal with
a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
such as Fedora/RHEL? What about policies with different types?
Differing numbers of MLS sensitivity levels or categories?
Also, can you explain the reason for having both a DOI and a algorithm
field? From an interoperability point of view, the node's security
implementation is irrelevant as long as it agrees to abide by the rules
and labels specified in the DOI. I understand that currently a SELinux
security label looks different from a traditional MLS/CMW security
label, but there is no reason that a translation mechanism could not be
implemented to provide a common network security label that could be
understood and internalized by both types of systems. While I'm not
holding this up as a particularly good example in all cases, we do have
something similar to this today in SELinux with how we handle the CIPSO
protocol.
> - length (2 octets) - The third and fourth octets contain the
> string length of the security context.
>
> - security label (1 or more octets) - The security label. The
> actual content will be dependent on the security algorithm
> that is specified. Within IKE context, this is regarded as
> an opaque bit string.
I'm being picky here, but it might be better to say "opaque bit field"
just so we don't get into string encoding issues (is it UTF-8 or
something else?).
> 3. Attribute Negotiation
>
> If an implementation receives an IPsec DOI attribute or attribute
> value that it does not support, it SHOULD send an
> ATTRIBUTES-NOT-SUPPORT and the security association negotiation
> and setup MUST be aborted.
See my comments in the next email about needing more text around how
security enforcement must be handled by the different implementations.
> 4. Security Considerations
>
> This document describes an extension to IKE [RFC2409] and ISAKMP
> [RFC2408] protocols. The use of the described security label
> should not change the basic security features of the two.
>
> The IPsec DOI describes a Situation field whose values can be
> SIT_SECRECY and/or SIT_INTEGRITY. When SIT_SECRECY is used, it
> indicates an environment requiring labeled secrecy and is
> followed with sensitivity label. When SIT_INTEGITY is used,
> it indicates an environment requiring labeled integrity and
> is followed with integrity information.
>
> SIT_SECRECY and SIT_INTEGRITY themselves indicate the use of
> a security label and therefore the security attribute described
> in this document MUST NOT be used in conjunction with either.
> The new security attribute extends the existing security
> mechanism to allow for additional interpretations of a security
> label and not just those defined by SIT_SECRECY and SIT INTEGRITY.
> It is possible that the sensitivity level and/or integrity level
> are
>
>
>
> Latten, et al. Expires ? [Page
> 4]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> included in the security label defined by the security algorithm
> using the new security attribute.
>
> 5. IANA Considerations
>
> This document contains two new "magic numbers" which are allocated
> and maintained by IANA registry.
>
> - The class value for the security label attribute.
>
> class value type
> -----------------------------------------
> Security Label ? V
>
> Only one value assigned by IANA is required.
>
> - The value for the security algorithm.
>
> SELinux 1(?)
> Smack 2(?)
>
> Additional values may be assigned by IANA for the
> security mechanisms requiring IKE to communicate its
> security label.
>
> Acknowledgements
>
> The authors would like to thank Stephen Smalley, James Morris and
> the SELinux community for their work on labeled ipsec.
>
> Normative References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Level", BCP 14, RFC 2119, March 1997.
>
> [RFC2407] Piper, D., "The Internet IP Security Domain of
> Interpretation for ISAKMP", RFC 2407, November 1998.
>
> [RFC2408] Maughan, D., Schertler, M., Schneider, M., and
> J. Turner, "Internet Security Association and Key
> Management Protocol", RFC 2408, November 1998.
>
> [RFC2409] Harkins, D. and D. Carrel, "The Internet Key
> Exchange", RFC 2409, November 1998.
>
> [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
> December 2005.
>
>
>
>
> Latten, et al. Expires ? [Page
> 5]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
> RFC 4303, December 2005.
>
> Informative references
>
> [RFC1108] Kent, S., "U.S. DoD Security Options for the Internet
> Protocol, RFC 1108, November 1991.
>
> Authors' Addresses
>
> Joy Latten
> IBM
> email: latten@austin.ibm.com
>
> George Wilson
> IBM
> email: gcwilson@us.ibm.com
>
> Serge Hallyn
> IBM
> email: serue@us.ibm.com
>
> Trent Jaeger
> Penn State
> email: tjaeger@cse.psu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Latten, et al. Expires ? [Page
> 6]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> Full Copyright Statement
>
> Copyright (C) The IETF Trust (2008).
>
> This document is subject to the rights, licenses and restrictions
> contained in BCP 78, and except as set forth therein, the authors
> retain all their rights.
>
> This document and the information contained herein are provided on
> an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
> PARTICULAR PURPOSE.
>
> Intellectual Property
>
> The IETF takes no position regarding the validity or scope of any
> Intellectual Property Rights or other rights that might be claimed
> to pertain to the implementation or use of the technology
> described in this document or the extent to which any license
> under such rights might or might not be available; nor does it
> represent that it has made any independent effort to identify any
> such rights. Information on the procedures with respect to rights
> in RFC documents can be found in BCP 78 and BCP 79.
>
> Copies of IPR disclosures made to the IETF Secretariat and any
> assurances of licenses to be made available, or the result of an
> attempt made to obtain a general license or permission for the use
> of such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository
> at http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention
> any copyrights, patents or patent applications, or other
> proprietary rights that may cover technology that may be required
> to implement this standard. Please address the information to the
> IETF at ietf-ipr@ietf.org.
>
>
>
>
>
>
>
>
>
>
>
>
> Latten, et al. Expires ? [Page
> 7]
--
paul moore
linux @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
@ 2008-07-26 16:34 ` Paul Moore
0 siblings, 0 replies; 23+ messages in thread
From: Paul Moore @ 2008-07-26 16:34 UTC (permalink / raw)
To: Joy Latten
Cc: selinux, gcwilson, serue, tjaeger, linux-security-module, netdev
On Friday 25 July 2008 1:51:19 pm Joy Latten wrote:
> I have attached two internet drafts for labeled ipsec for the
> community's review if interested.
>
> I have not yet submitted to IETF. I'd need comments by next
> Thursday (July 31) so I can incorporate any comments before
> submitting.
I'm CC'ing the LSM and netdev lists because there are some smart people
there too that might want to comment on these proposed specifications.
Otherwise my comments are below.
> There are two drafts because IKEv1 was obsoleted by IKEv2, but most
> are still using IKEv1. I also noticed some recent IPsec rfcs,
> particularly those proposing algorithm suites sometimes referred to
> IKEv1 also, although it has been obsoleted. So just in case, there is
> a draft for IKEv1 too. It didn't seem the drafts could be merged
> since ikev1 and ikev2 are different.
>
> Lastly, IPsec architecture rfc 2401 was obsoleted by rfc 4301.
> 2401, section 8 supported "MLS networking" within IPsec. All this was
> removed from rfc 4301. Thus the labeled ipsec draft for ikev2,
> reintroduces mls networking as MAC Networking and is longer.
>
> Please let me know if anything is missing or could be improved.
> Thanks!
>
> regards,
> Joy
>
> ---------------------------------------------------------------
>
>
>
>
>
> Network Working Group J. Latten
> Internet-Draft G. Wilson
> Intended Status: Standards Track S. Hallyn
> Expires: ? IBM
> T. Jaeger
> Penn State
> June 2008
>
> Security Label Addendum to
> IPsec Domain of Interpretation (DOI)
> for Internet Security Association
> and Key Management Protocol (ISAKMP)
>
> draft-jml-ipsec-ikev1-security-label-00
>
> Status of This Memo
>
> By submitting this Internet-Draft, each author represents that any
> applicable patent or other IPR claims of which he or she is aware
> have been or will be disclosed, and any of which he or she becomes
> aware will be disclosed, in accordance with Section 6 of BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other documents
> at any time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress".
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on December, 2008.
>
> Copyright Notice
>
> Copyright (C) The IETF Trust (2008)
>
> Abstract
>
> This document describes the need for and the use of a security
> label within IPsec. It describes the extension to the Internet IP
> Security
>
>
>
> Latten, et al. Expires ? [Page
> 1]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet
> Security Association and Key Management Protocol (ISAKMP)
> [RFC2408]. This extension supports the negotiation of the security
> label for a particular IP Authentication Header (AH) [RFC4302] or IP
> Encapsulating Security Payload (ESP) [RFC4303] security
> association.
>
> 1. Introduction
>
> Traditionally, security context referred to the security level and
Should this be "security label" instead of "security context"?
> category used by Multilevel Security (MLS). This document will
This should probably bet "category set" or something similar.
> refer to the security level and category as the security
> classification.
Do you mean "MLS security classification"? That "MLS" qualifier helps
make it a bit more concrete and appears to match how you actually use
it in the document.
>
> Current security mechanisms, such as SELinux, use the security
> classification and additional security attributes to form their
> security context. For example, a type for type enforcement.
>
> Techniques such as IP Security Options (IPSO) allow IP datagrams
> to be labeled with an MLS security classification [RFC1108]. This
> ensured the same security applied to local objects and resources was
> utilized when communicating over the network with homogenous systems.
I think you should either remove the "homogeneous" qualifier or change
it to heterogeneous. We've seen both different MLS implementations as
well as MLS/Type-Enforcement implementations interoperate using IP
options; granted it was with CIPSO and not RFC1108 but they are similar
enough for this level of discussion.
> However, these techniques cannot pass along the additional security
> attributes used in current security mechanisms.
This is an intersting point and the following argument may be a bit
contentious, but arguably you could encode random security contexts
into a traditional MLS security context; Smack is a shining example of
this as it encodes the generic Smack label into a CIPSO permissive
bitmap tag. It may violate the spirit of the CIPSO specification but
it is valid and provides a strong counterexample.
Further, the FIPS-188 specification, while not an IETF specification,
does provide for a "freeform" IP option which is intended to support
arbitrary security attributes.
> The ISAKMP specification defines a Situation field in the Security
> Association payload [RFC2408]. The IPsec DOI describes the use of
> this field to communicate sensitivity and integrity classification
> information between initiator and responder when negotiating a
> security association [RFC2407]. However, it does not provide for
> additional security attributes that may be required by the
> security mechanism being deployed in the environment.
>
> This document describes the additions to the IPsec DOI for ISAKMP
> that are needed to support communication of additional security
> attributes between two hosts, in particular a security label.
>
> 2. Terminology
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this document are to be interpreted as described in [RFC2119].
>
>
>
>
>
>
>
>
>
>
>
> Latten, et al. Expires ? [Page
> 2]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> 3. IPsec Security Association Attribute
>
> The following SA attribute definition is used in Phase II of an
> Internet Key Exchange Protocol (IKE) negotiation that includes a
> security label. The attribute type is Variable-Length (V).
> Encoding of attributes is defined in the base ISAKMP
> specification [RFC2408].
>
> Attribute Type
>
> class value type
> ------------------------------------------------------
> Security Label ? V
>
> Class Values
>
> Security Label
>
> Specifies that the security association is being negotiated
> in an environment that requires labeled security. This field
> will contain the security label.
> The security label has the following format.
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | doi | algorithm | length
> | |
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | security label (variable)
> | |
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 1: Security Label format
>
> - doi (1 octet) - The first octet contains the security
> label's domain of interpretation.
>
> The domain of interpretation can be viewed as a group of
> systems that agree on the meaning of particular values
> within the security label of a security mechanism.
>
> The value of 1 is reserved as the default.
>
> Reserved 0
> Default 1
>
> - algorithm (1 octet) - The second octet contains the security
> label's algorithm.
>
>
>
>
> Latten, et al. Expires ? [Page
> 3]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> The security label's algorithm specifies the security
> mechanism or context in which the label is applicable. For
> example, the security label is interpreted within the
> SELinux context.
>
> Requests for assignment of additional algorithms should be
> addressed to the Internet Assigned Numbers Authority (IANA).
>
> Reserved 0
> SELinux 1
> Smack 2
> Private Use 120-128
Is one octet enough here? I honestly don't have a good idea as to how
much is enough, so a little justification of your choice (even if it
only lives in email, not in the spec) would be welcome.
I'm also concerned with the implied convention of assigning one value to
a particular implementation. In the SELinux case, how do you deal with
a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
such as Fedora/RHEL? What about policies with different types?
Differing numbers of MLS sensitivity levels or categories?
Also, can you explain the reason for having both a DOI and a algorithm
field? From an interoperability point of view, the node's security
implementation is irrelevant as long as it agrees to abide by the rules
and labels specified in the DOI. I understand that currently a SELinux
security label looks different from a traditional MLS/CMW security
label, but there is no reason that a translation mechanism could not be
implemented to provide a common network security label that could be
understood and internalized by both types of systems. While I'm not
holding this up as a particularly good example in all cases, we do have
something similar to this today in SELinux with how we handle the CIPSO
protocol.
> - length (2 octets) - The third and fourth octets contain the
> string length of the security context.
>
> - security label (1 or more octets) - The security label. The
> actual content will be dependent on the security algorithm
> that is specified. Within IKE context, this is regarded as
> an opaque bit string.
I'm being picky here, but it might be better to say "opaque bit field"
just so we don't get into string encoding issues (is it UTF-8 or
something else?).
> 3. Attribute Negotiation
>
> If an implementation receives an IPsec DOI attribute or attribute
> value that it does not support, it SHOULD send an
> ATTRIBUTES-NOT-SUPPORT and the security association negotiation
> and setup MUST be aborted.
See my comments in the next email about needing more text around how
security enforcement must be handled by the different implementations.
> 4. Security Considerations
>
> This document describes an extension to IKE [RFC2409] and ISAKMP
> [RFC2408] protocols. The use of the described security label
> should not change the basic security features of the two.
>
> The IPsec DOI describes a Situation field whose values can be
> SIT_SECRECY and/or SIT_INTEGRITY. When SIT_SECRECY is used, it
> indicates an environment requiring labeled secrecy and is
> followed with sensitivity label. When SIT_INTEGITY is used,
> it indicates an environment requiring labeled integrity and
> is followed with integrity information.
>
> SIT_SECRECY and SIT_INTEGRITY themselves indicate the use of
> a security label and therefore the security attribute described
> in this document MUST NOT be used in conjunction with either.
> The new security attribute extends the existing security
> mechanism to allow for additional interpretations of a security
> label and not just those defined by SIT_SECRECY and SIT INTEGRITY.
> It is possible that the sensitivity level and/or integrity level
> are
>
>
>
> Latten, et al. Expires ? [Page
> 4]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> included in the security label defined by the security algorithm
> using the new security attribute.
>
> 5. IANA Considerations
>
> This document contains two new "magic numbers" which are allocated
> and maintained by IANA registry.
>
> - The class value for the security label attribute.
>
> class value type
> -----------------------------------------
> Security Label ? V
>
> Only one value assigned by IANA is required.
>
> - The value for the security algorithm.
>
> SELinux 1(?)
> Smack 2(?)
>
> Additional values may be assigned by IANA for the
> security mechanisms requiring IKE to communicate its
> security label.
>
> Acknowledgements
>
> The authors would like to thank Stephen Smalley, James Morris and
> the SELinux community for their work on labeled ipsec.
>
> Normative References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Level", BCP 14, RFC 2119, March 1997.
>
> [RFC2407] Piper, D., "The Internet IP Security Domain of
> Interpretation for ISAKMP", RFC 2407, November 1998.
>
> [RFC2408] Maughan, D., Schertler, M., Schneider, M., and
> J. Turner, "Internet Security Association and Key
> Management Protocol", RFC 2408, November 1998.
>
> [RFC2409] Harkins, D. and D. Carrel, "The Internet Key
> Exchange", RFC 2409, November 1998.
>
> [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
> December 2005.
>
>
>
>
> Latten, et al. Expires ? [Page
> 5]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
> RFC 4303, December 2005.
>
> Informative references
>
> [RFC1108] Kent, S., "U.S. DoD Security Options for the Internet
> Protocol, RFC 1108, November 1991.
>
> Authors' Addresses
>
> Joy Latten
> IBM
> email: latten@austin.ibm.com
>
> George Wilson
> IBM
> email: gcwilson@us.ibm.com
>
> Serge Hallyn
> IBM
> email: serue@us.ibm.com
>
> Trent Jaeger
> Penn State
> email: tjaeger@cse.psu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Latten, et al. Expires ? [Page
> 6]
> Internet-Draft IKEv1SecurityLabel June
> 2008
>
>
> Full Copyright Statement
>
> Copyright (C) The IETF Trust (2008).
>
> This document is subject to the rights, licenses and restrictions
> contained in BCP 78, and except as set forth therein, the authors
> retain all their rights.
>
> This document and the information contained herein are provided on
> an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
> PARTICULAR PURPOSE.
>
> Intellectual Property
>
> The IETF takes no position regarding the validity or scope of any
> Intellectual Property Rights or other rights that might be claimed
> to pertain to the implementation or use of the technology
> described in this document or the extent to which any license
> under such rights might or might not be available; nor does it
> represent that it has made any independent effort to identify any
> such rights. Information on the procedures with respect to rights
> in RFC documents can be found in BCP 78 and BCP 79.
>
> Copies of IPR disclosures made to the IETF Secretariat and any
> assurances of licenses to be made available, or the result of an
> attempt made to obtain a general license or permission for the use
> of such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository
> at http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention
> any copyrights, patents or patent applications, or other
> proprietary rights that may cover technology that may be required
> to implement this standard. Please address the information to the
> IETF at ietf-ipr@ietf.org.
>
>
>
>
>
>
>
>
>
>
>
>
> Latten, et al. Expires ? [Page
> 7]
--
paul moore
linux @ hp
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
@ 2008-08-25 20:46 Joy Latten
2008-08-25 21:42 ` David P. Quigley
0 siblings, 1 reply; 23+ messages in thread
From: Joy Latten @ 2008-08-25 20:46 UTC (permalink / raw)
To: paul.moore; +Cc: gcwilson, selinux, serue, tjaeger
I apologize for the delay in responding. Vacation and then
jury duty kinda got in the way. :-)
>>
>> 1. Introduction
>>
>> Traditionally, security context referred to the security level and
>
>Should this be "security label" instead of "security context"?
Yes, will change.
>> category used by Multilevel Security (MLS). This document will
>
> This should probably bet "category set" or something similar.
Ok.
>> refer to the security level and category as the security
>> classification.
>
>Do you mean "MLS security classification"? That "MLS" qualifier helps
>make it a bit more concrete and appears to match how you actually use
>it in the document.
Yes! That is much better.
>>
>> Current security mechanisms, such as SELinux, use the security
>> classification and additional security attributes to form their
>> security context. For example, a type for type enforcement.
>>
>> Techniques such as IP Security Options (IPSO) allow IP datagrams
>> to be labeled with an MLS security classification [RFC1108]. This
>> ensured the same security applied to local objects and resources was
>> utilized when communicating over the network with homogenous systems.
>
>I think you should either remove the "homogeneous" qualifier or change
>it to heterogeneous. We've seen both different MLS implementations as
>well as MLS/Type-Enforcement implementations interoperate using IP
>options; granted it was with CIPSO and not RFC1108 but they are similar
>enough for this level of discussion.
What I meant was that the systems must be operating within same DOI.
I will change this sentence to better state this fact.
>> However, these techniques cannot pass along the additional security
>> attributes used in current security mechanisms.
>
>This is an intersting point and the following argument may be a bit
>contentious, but arguably you could encode random security contexts
>into a traditional MLS security context; Smack is a shining example of
>this as it encodes the generic Smack label into a CIPSO permissive
>bitmap tag. It may violate the spirit of the CIPSO specification but
>it is valid and provides a strong counterexample.
>
>Further, the FIPS-188 specification, while not an IETF specification,
>does provide for a "freeform" IP option which is intended to support
>arbitrary security attributes.
Yes, I agree, FIPS-188 free form tags would help accomplish this.
What I should state here is that the data, including the label
isn't protected nor or the bindings between the data and the label.
>>
>> - doi (1 octet) - The first octet contains the security
>> label's domain of interpretation.
>>
>> The domain of interpretation can be viewed as a group of
>> systems that agree on the meaning of particular values
>> within the security label of a security mechanism.
>>
>> The value of 1 is reserved as the default.
>>
>> Reserved 0
>> Default 1
>>
>> - algorithm (1 octet) - The second octet contains the security
>> label's algorithm.
>>
>>
>>
>>
>> Latten, et al. Expires ? [Page
>> 3]
>> Internet-Draft IKEv1SecurityLabel June
>> 2008
>>
>>
>> The security label's algorithm specifies the security
>> mechanism or context in which the label is applicable. For
>> example, the security label is interpreted within the
>> SELinux context.
>>
>> Requests for assignment of additional algorithms should be
>> addressed to the Internet Assigned Numbers Authority (IANA).
>>
>> Reserved 0
>> SELinux 1
>> Smack 2
>> Private Use 120-128
>
>Is one octet enough here? I honestly don't have a good idea as to how
>much is enough, so a little justification of your choice (even if it
>only lives in email, not in the spec) would be welcome.
I used one octet here because it is defined as one octet in the kernel's
sec_ctx structure. Originally, I think we used one octect for each
to keep within a 64-bit alignment requirement for pfkey. We thought
one octet would be enough...
>I'm also concerned with the implied convention of assigning one value to
>a particular implementation. In the SELinux case, how do you deal with
>a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
>such as Fedora/RHEL? What about policies with different types?
>Differing numbers of MLS sensitivity levels or categories?
>
Hmm... not sure I understand so I may not answer this correctly...
The algorithm indicates the security mechanism.
In a way, it identifies the syntax/semantics of the
security context to security mechanism, since security mechanisms
may use different syntax/semantics for the security contexts.
i.e. SELinux and SMACK.
The algorithm field in SELinux is used to "authorize" the security
context. In other words, SELinux only wants and understands
SELinux's security context syntax/semantics.
The "doi" would be used for further differentiation within SELinux
domain. Far example, a sysadm wants to differentiate between SELinux
policy versions in his domain. He could used "doi" field to do this.
I suppose if you wanted two different security mechanisms to
interoperate, a mapping of some sort would have to be created
between them. The security mechanisms would need
to indicate they accept (via the mapping) the other's
security context syntax/semantics. In other words, they would "authorize"
the two different security contexts. It would do this via the
"algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
even indicate the mapping such as CIPSO's DOI does.
I considered the information contained in the "algorithm" and
"doi" fields required for interoperability, and the use
implementation specific.
If this doesn't answer your question, let me know.
>>Also, can you explain the reason for having both a DOI and a algorithm
>>field? From an interoperability point of view, the node's security
>>implementation is irrelevant as long as it agrees to abide by the rules
>>and labels specified in the DOI. I understand that currently a SELinux
>>security label looks different from a traditional MLS/CMW security
>>label, but there is no reason that a translation mechanism could not be
>>implemented to provide a common network security label that could be
>>understood and internalized by both types of systems. While I'm not
>>holding this up as a particularly good example in all cases, we do have
>>something similar to this today in SELinux with how we handle the CIPSO
>>protocol.
I hope the above explained it. In a way my above explanation
agrees with what you are saying here.
>> - length (2 octets) - The third and fourth octets contain the
>> string length of the security context.
>>
>> - security label (1 or more octets) - The security label. The
>> actual content will be dependent on the security algorithm
>> that is specified. Within IKE context, this is regarded as
>> an opaque bit string.
>
>I'm being picky here, but it might be better to say "opaque bit field"
>just so we don't get into string encoding issues (is it UTF-8 or
>something else?).
Ok, will do.
regards,
Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-25 20:46 [RFC 1/2] labeled ipsec internet drafts Joy Latten
@ 2008-08-25 21:42 ` David P. Quigley
2008-08-26 17:17 ` Joy Latten
0 siblings, 1 reply; 23+ messages in thread
From: David P. Quigley @ 2008-08-25 21:42 UTC (permalink / raw)
To: Joy Latten; +Cc: paul.moore, gcwilson, selinux, serue, tjaeger
On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
[Snip...]
>
> >>
> >> - doi (1 octet) - The first octet contains the security
> >> label's domain of interpretation.
> >>
> >> The domain of interpretation can be viewed as a group of
> >> systems that agree on the meaning of particular values
> >> within the security label of a security mechanism.
> >>
> >> The value of 1 is reserved as the default.
> >>
> >> Reserved 0
> >> Default 1
> >>
> >> - algorithm (1 octet) - The second octet contains the security
> >> label's algorithm.
> >>
> >>
> >>
> >>
> >> Latten, et al. Expires ? [Page
> >> 3]
> >> Internet-Draft IKEv1SecurityLabel June
> >> 2008
> >>
> >>
> >> The security label's algorithm specifies the security
> >> mechanism or context in which the label is applicable. For
> >> example, the security label is interpreted within the
> >> SELinux context.
> >>
> >> Requests for assignment of additional algorithms should be
> >> addressed to the Internet Assigned Numbers Authority (IANA).
> >>
> >> Reserved 0
> >> SELinux 1
> >> Smack 2
> >> Private Use 120-128
> >
> >Is one octet enough here? I honestly don't have a good idea as to how
> >much is enough, so a little justification of your choice (even if it
> >only lives in email, not in the spec) would be welcome.
>
> I used one octet here because it is defined as one octet in the kernel's
> sec_ctx structure. Originally, I think we used one octect for each
> to keep within a 64-bit alignment requirement for pfkey. We thought
> one octet would be enough...
>
There are several documents being submitted as drafts to the IETF at the
moment and all of them have different definitions of a DOI.
In your method you pair a mechanism with the DOI to form something along
the lines of a (mechanism,policyversion) tuple. The question of if one
octet is enough to identify all potential policies in a mechanism is
unclear but I have a feeling the answer will be no.
The second method is in the SIPSO for IPv6 draft. In this the DOI is a
32 bit value existing as 4 octets. They partition off what are
essentially address spaces to be used privately, by certain
organizations, and they also keep a block for IETF considerations in
later revisions of the specification. There is a lot of information in
the document and most of it pertains to MLS labels.
The third method is in the label support for NFSv4 draft. In this we
just define the DOI as a 32 big value. It is up to a translation daemon
to decide if the endpoint has the knowledge and desire to translate
labels from the foreign DOI to its own.
Regardless of which method is used we need to come to a consensus on
what a DOI is and how we are going to represent it. We can't go to the
IETF with 3 different definitions of a DOI.
> >I'm also concerned with the implied convention of assigning one value to
> >a particular implementation. In the SELinux case, how do you deal with
> >a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
> >such as Fedora/RHEL? What about policies with different types?
> >Differing numbers of MLS sensitivity levels or categories?
> >
>
> Hmm... not sure I understand so I may not answer this correctly...
>
> The algorithm indicates the security mechanism.
> In a way, it identifies the syntax/semantics of the
> security context to security mechanism, since security mechanisms
> may use different syntax/semantics for the security contexts.
> i.e. SELinux and SMACK.
> The algorithm field in SELinux is used to "authorize" the security
> context. In other words, SELinux only wants and understands
> SELinux's security context syntax/semantics.
> The "doi" would be used for further differentiation within SELinux
> domain. Far example, a sysadm wants to differentiate between SELinux
> policy versions in his domain. He could used "doi" field to do this.
>
> I suppose if you wanted two different security mechanisms to
> interoperate, a mapping of some sort would have to be created
> between them. The security mechanisms would need
> to indicate they accept (via the mapping) the other's
> security context syntax/semantics. In other words, they would "authorize"
> the two different security contexts. It would do this via the
> "algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
> even indicate the mapping such as CIPSO's DOI does.
>
> I considered the information contained in the "algorithm" and
> "doi" fields required for interoperability, and the use
> implementation specific.
>
> If this doesn't answer your question, let me know.
I think what Paul might be asking is why is it better to have two
fields, one for Security Mechanism and one for the DOI when that can be
one field. If we go with a method similar to the second described above
for DOIs you could have IANA allocate a range of DOIs for SELinux
partitioning it off into a range for publicly assigned DOIs and
privately managed DOIs. It is acceptable to have IANA create and
populate a registry with values in the document.
>
> >>Also, can you explain the reason for having both a DOI and a algorithm
> >>field? From an interoperability point of view, the node's security
> >>implementation is irrelevant as long as it agrees to abide by the rules
> >>and labels specified in the DOI. I understand that currently a SELinux
> >>security label looks different from a traditional MLS/CMW security
> >>label, but there is no reason that a translation mechanism could not be
> >>implemented to provide a common network security label that could be
> >>understood and internalized by both types of systems. While I'm not
> >>holding this up as a particularly good example in all cases, we do have
> >>something similar to this today in SELinux with how we handle the CIPSO
> >>protocol.
>
> I hope the above explained it. In a way my above explanation
> agrees with what you are saying here.
>
> >> - length (2 octets) - The third and fourth octets contain the
> >> string length of the security context.
> >>
> >> - security label (1 or more octets) - The security label. The
> >> actual content will be dependent on the security algorithm
> >> that is specified. Within IKE context, this is regarded as
> >> an opaque bit string.
> >
> >I'm being picky here, but it might be better to say "opaque bit field"
> >just so we don't get into string encoding issues (is it UTF-8 or
> >something else?).
>
> Ok, will do
I think the proper terminology is an "opaque byte" something where
something is an array, or a stream</pedantic>. At least that is what we
use in the NFSv4 documents, however they use XDR encoding and that term
is actually defined. I'm not sure if the IPSec document already has
definitions for these data types. The problem here is opaque usually
means with respect to the protocol not the encoding. So I think you
should make a decision on the string encoding or it might turn into an
interop nightmare. It's fine to say the semantic meaning of the string
is opaque to the protocol but you should agree on if your sending UTF-8
or whatever.
> .
>
> regards,
> Joy
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-25 21:42 ` David P. Quigley
@ 2008-08-26 17:17 ` Joy Latten
2008-08-26 20:24 ` David P. Quigley
0 siblings, 1 reply; 23+ messages in thread
From: Joy Latten @ 2008-08-26 17:17 UTC (permalink / raw)
To: David P. Quigley; +Cc: paul.moore, gcwilson, selinux, serue, tjaeger
On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
> [Snip...]
> >
> > >>
> > >> - doi (1 octet) - The first octet contains the security
> > >> label's domain of interpretation.
> > >>
> > >> The domain of interpretation can be viewed as a group of
> > >> systems that agree on the meaning of particular values
> > >> within the security label of a security mechanism.
> > >>
> > >> The value of 1 is reserved as the default.
> > >>
> > >> Reserved 0
> > >> Default 1
> > >>
> > >> - algorithm (1 octet) - The second octet contains the security
> > >> label's algorithm.
> > >>
> > >>
> > >>
> > >>
> > >> Latten, et al. Expires ? [Page
> > >> 3]
> > >> Internet-Draft IKEv1SecurityLabel June
> > >> 2008
> > >>
> > >>
> > >> The security label's algorithm specifies the security
> > >> mechanism or context in which the label is applicable. For
> > >> example, the security label is interpreted within the
> > >> SELinux context.
> > >>
> > >> Requests for assignment of additional algorithms should be
> > >> addressed to the Internet Assigned Numbers Authority (IANA).
> > >>
> > >> Reserved 0
> > >> SELinux 1
> > >> Smack 2
> > >> Private Use 120-128
> > >
> > >Is one octet enough here? I honestly don't have a good idea as to how
> > >much is enough, so a little justification of your choice (even if it
> > >only lives in email, not in the spec) would be welcome.
> >
> > I used one octet here because it is defined as one octet in the kernel's
> > sec_ctx structure. Originally, I think we used one octect for each
> > to keep within a 64-bit alignment requirement for pfkey. We thought
> > one octet would be enough...
> >
>
> There are several documents being submitted as drafts to the IETF at the
> moment and all of them have different definitions of a DOI.
>
> In your method you pair a mechanism with the DOI to form something along
> the lines of a (mechanism,policyversion) tuple. The question of if one
> octet is enough to identify all potential policies in a mechanism is
> unclear but I have a feeling the answer will be no.
>
> The second method is in the SIPSO for IPv6 draft. In this the DOI is a
> 32 bit value existing as 4 octets. They partition off what are
> essentially address spaces to be used privately, by certain
> organizations, and they also keep a block for IETF considerations in
> later revisions of the specification. There is a lot of information in
> the document and most of it pertains to MLS labels.
>
> The third method is in the label support for NFSv4 draft. In this we
> just define the DOI as a 32 big value. It is up to a translation daemon
> to decide if the endpoint has the knowledge and desire to translate
> labels from the foreign DOI to its own.
>
> Regardless of which method is used we need to come to a consensus on
> what a DOI is and how we are going to represent it. We can't go to the
> IETF with 3 different definitions of a DOI.
>
I just now quickly glanced at the CALIPSO draft as I had not read
it before. I did read the labeled nfs draft a while back.
I see what you mean. However, I guess I am feeling a bit wary since
the CALIPSO draft's description of the DOI and it's format seem to be
tailored specifically for MLS labels. The labeled ipsec's doi field had
a broader purpose in mind.
> > >I'm also concerned with the implied convention of assigning one value to
> > >a particular implementation. In the SELinux case, how do you deal with
> > >a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
> > >such as Fedora/RHEL? What about policies with different types?
> > >Differing numbers of MLS sensitivity levels or categories?
> > >
> >
> > Hmm... not sure I understand so I may not answer this correctly...
> >
> > The algorithm indicates the security mechanism.
> > In a way, it identifies the syntax/semantics of the
> > security context to security mechanism, since security mechanisms
> > may use different syntax/semantics for the security contexts.
> > i.e. SELinux and SMACK.
> > The algorithm field in SELinux is used to "authorize" the security
> > context. In other words, SELinux only wants and understands
> > SELinux's security context syntax/semantics.
> > The "doi" would be used for further differentiation within SELinux
> > domain. Far example, a sysadm wants to differentiate between SELinux
> > policy versions in his domain. He could used "doi" field to do this.
> >
> > I suppose if you wanted two different security mechanisms to
> > interoperate, a mapping of some sort would have to be created
> > between them. The security mechanisms would need
> > to indicate they accept (via the mapping) the other's
> > security context syntax/semantics. In other words, they would "authorize"
> > the two different security contexts. It would do this via the
> > "algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
> > even indicate the mapping such as CIPSO's DOI does.
> >
> > I considered the information contained in the "algorithm" and
> > "doi" fields required for interoperability, and the use
> > implementation specific.
> >
> > If this doesn't answer your question, let me know.
>
> I think what Paul might be asking is why is it better to have two
> fields, one for Security Mechanism and one for the DOI when that can be
> one field. If we go with a method similar to the second described above
> for DOIs you could have IANA allocate a range of DOIs for SELinux
> partitioning it off into a range for publicly assigned DOIs and
> privately managed DOIs. It is acceptable to have IANA create and
> populate a registry with values in the document.
>
Ok, I understand now. Yes, that seems reasonable, fair, and flexible.
I can still keep semantics (a mechanism and ability to group or
differentiate).
So, a doi field that is 32 bits, with perhaps so much for SELinux,
further partitioned for public and private use. The same for Smack.
Right? And remaining for future use.
Would this be a consensus in regards to DOI for labeled nfs, labeled
ipsec, and CALIPSO drafts?
> >
> > >>Also, can you explain the reason for having both a DOI and a algorithm
> > >>field? From an interoperability point of view, the node's security
> > >>implementation is irrelevant as long as it agrees to abide by the rules
> > >>and labels specified in the DOI. I understand that currently a SELinux
> > >>security label looks different from a traditional MLS/CMW security
> > >>label, but there is no reason that a translation mechanism could not be
> > >>implemented to provide a common network security label that could be
> > >>understood and internalized by both types of systems. While I'm not
> > >>holding this up as a particularly good example in all cases, we do have
> > >>something similar to this today in SELinux with how we handle the CIPSO
> > >>protocol.
> >
> > I hope the above explained it. In a way my above explanation
> > agrees with what you are saying here.
> >
> > >> - length (2 octets) - The third and fourth octets contain the
> > >> string length of the security context.
> > >>
> > >> - security label (1 or more octets) - The security label. The
> > >> actual content will be dependent on the security algorithm
> > >> that is specified. Within IKE context, this is regarded as
> > >> an opaque bit string.
> > >
> > >I'm being picky here, but it might be better to say "opaque bit field"
> > >just so we don't get into string encoding issues (is it UTF-8 or
> > >something else?).
> >
> > Ok, will do
>
> I think the proper terminology is an "opaque byte" something where
> something is an array, or a stream</pedantic>. At least that is what we
> use in the NFSv4 documents, however they use XDR encoding and that term
> is actually defined. I'm not sure if the IPSec document already has
> definitions for these data types. The problem here is opaque usually
> means with respect to the protocol not the encoding. So I think you
> should make a decision on the string encoding or it might turn into an
> interop nightmare. It's fine to say the semantic meaning of the string
> is opaque to the protocol but you should agree on if your sending UTF-8
> or whatever.
>
Ahh, yes! Thanks for pointing that out! Let me go investigate and
determine which encoding.
Thanks!
Hopefully, will send out a revised draft with both Paul and David's
improvements soon.
regards,
Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-26 17:17 ` Joy Latten
@ 2008-08-26 20:24 ` David P. Quigley
2008-08-27 16:17 ` Joy Latten
0 siblings, 1 reply; 23+ messages in thread
From: David P. Quigley @ 2008-08-26 20:24 UTC (permalink / raw)
To: Joy Latten; +Cc: paul.moore, gcwilson, selinux, serue, tjaeger
On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
> > [Snip...]
> > >
> > > >>
> > > >> - doi (1 octet) - The first octet contains the security
> > > >> label's domain of interpretation.
> > > >>
> > > >> The domain of interpretation can be viewed as a group of
> > > >> systems that agree on the meaning of particular values
> > > >> within the security label of a security mechanism.
> > > >>
> > > >> The value of 1 is reserved as the default.
> > > >>
> > > >> Reserved 0
> > > >> Default 1
> > > >>
> > > >> - algorithm (1 octet) - The second octet contains the security
> > > >> label's algorithm.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Latten, et al. Expires ? [Page
> > > >> 3]
> > > >> Internet-Draft IKEv1SecurityLabel June
> > > >> 2008
> > > >>
> > > >>
> > > >> The security label's algorithm specifies the security
> > > >> mechanism or context in which the label is applicable. For
> > > >> example, the security label is interpreted within the
> > > >> SELinux context.
> > > >>
> > > >> Requests for assignment of additional algorithms should be
> > > >> addressed to the Internet Assigned Numbers Authority (IANA).
> > > >>
> > > >> Reserved 0
> > > >> SELinux 1
> > > >> Smack 2
> > > >> Private Use 120-128
> > > >
> > > >Is one octet enough here? I honestly don't have a good idea as to how
> > > >much is enough, so a little justification of your choice (even if it
> > > >only lives in email, not in the spec) would be welcome.
> > >
> > > I used one octet here because it is defined as one octet in the kernel's
> > > sec_ctx structure. Originally, I think we used one octect for each
> > > to keep within a 64-bit alignment requirement for pfkey. We thought
> > > one octet would be enough...
> > >
> >
> > There are several documents being submitted as drafts to the IETF at the
> > moment and all of them have different definitions of a DOI.
> >
> > In your method you pair a mechanism with the DOI to form something along
> > the lines of a (mechanism,policyversion) tuple. The question of if one
> > octet is enough to identify all potential policies in a mechanism is
> > unclear but I have a feeling the answer will be no.
> >
> > The second method is in the SIPSO for IPv6 draft. In this the DOI is a
> > 32 bit value existing as 4 octets. They partition off what are
> > essentially address spaces to be used privately, by certain
> > organizations, and they also keep a block for IETF considerations in
> > later revisions of the specification. There is a lot of information in
> > the document and most of it pertains to MLS labels.
> >
> > The third method is in the label support for NFSv4 draft. In this we
> > just define the DOI as a 32 big value. It is up to a translation daemon
> > to decide if the endpoint has the knowledge and desire to translate
> > labels from the foreign DOI to its own.
> >
> > Regardless of which method is used we need to come to a consensus on
> > what a DOI is and how we are going to represent it. We can't go to the
> > IETF with 3 different definitions of a DOI.
> >
>
> I just now quickly glanced at the CALIPSO draft as I had not read
> it before. I did read the labeled nfs draft a while back.
>
> I see what you mean. However, I guess I am feeling a bit wary since
> the CALIPSO draft's description of the DOI and it's format seem to be
> tailored specifically for MLS labels. The labeled ipsec's doi field had
> a broader purpose in mind.
Yea, it is unfortunate that CALIPSO is only for MLS labels. IPv6 is
still growing in its deployment so it would be nice to have a robust and
flexible method for conveying security labels from the start. For now it
seems as if CALIPSO will try to go through just as MLS labels and then
DTE or other security labels will have to create their own IP security
option.
>
> > > >I'm also concerned with the implied convention of assigning one value to
> > > >a particular implementation. In the SELinux case, how do you deal with
> > > >a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
> > > >such as Fedora/RHEL? What about policies with different types?
> > > >Differing numbers of MLS sensitivity levels or categories?
> > > >
> > >
> > > Hmm... not sure I understand so I may not answer this correctly...
> > >
> > > The algorithm indicates the security mechanism.
> > > In a way, it identifies the syntax/semantics of the
> > > security context to security mechanism, since security mechanisms
> > > may use different syntax/semantics for the security contexts.
> > > i.e. SELinux and SMACK.
> > > The algorithm field in SELinux is used to "authorize" the security
> > > context. In other words, SELinux only wants and understands
> > > SELinux's security context syntax/semantics.
> > > The "doi" would be used for further differentiation within SELinux
> > > domain. Far example, a sysadm wants to differentiate between SELinux
> > > policy versions in his domain. He could used "doi" field to do this.
> > >
> > > I suppose if you wanted two different security mechanisms to
> > > interoperate, a mapping of some sort would have to be created
> > > between them. The security mechanisms would need
> > > to indicate they accept (via the mapping) the other's
> > > security context syntax/semantics. In other words, they would "authorize"
> > > the two different security contexts. It would do this via the
> > > "algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
> > > even indicate the mapping such as CIPSO's DOI does.
> > >
> > > I considered the information contained in the "algorithm" and
> > > "doi" fields required for interoperability, and the use
> > > implementation specific.
> > >
> > > If this doesn't answer your question, let me know.
> >
> > I think what Paul might be asking is why is it better to have two
> > fields, one for Security Mechanism and one for the DOI when that can be
> > one field. If we go with a method similar to the second described above
> > for DOIs you could have IANA allocate a range of DOIs for SELinux
> > partitioning it off into a range for publicly assigned DOIs and
> > privately managed DOIs. It is acceptable to have IANA create and
> > populate a registry with values in the document.
> >
>
> Ok, I understand now. Yes, that seems reasonable, fair, and flexible.
> I can still keep semantics (a mechanism and ability to group or
> differentiate).
>
> So, a doi field that is 32 bits, with perhaps so much for SELinux,
> further partitioned for public and private use. The same for Smack.
> Right? And remaining for future use.
The standards people don't particularly care about specific security
models in this case. I initially mentioned implementation specific
details in my early labeled NFS drafts and was told that those aren't
really a concern of the protocol. Since the label is a (DOI,<OPAQUE>)
tuple it is up to whomever obtains a number from IANA to define the
meaning of that DOI. However it should be written into the standard what
information is recorded by IANA to bind to these numbers. Also do we see
several registries? I really only see one registry that can be shared by
all three of these drafts. I just hope they don't want us to write up an
RFC for the definition and management of DOIs (it might happen that way
though).
>
> Would this be a consensus in regards to DOI for labeled nfs, labeled
> ipsec, and CALIPSO drafts?
>
I would like to think that we could establish one definition of a DOI
for IETF documents. I spoke with several people at the last IETF meeting
and they said that we need to stay consistent here. I will be trying to
organize a security label BOF at the next IETF meeting so we can sit
down and discuss the way things should work. I doubt this will spawn a
working group for security labels but we could come to a consensus on
certain things.
> > >
> > > >>Also, can you explain the reason for having both a DOI and a algorithm
> > > >>field? From an interoperability point of view, the node's security
> > > >>implementation is irrelevant as long as it agrees to abide by the rules
> > > >>and labels specified in the DOI. I understand that currently a SELinux
> > > >>security label looks different from a traditional MLS/CMW security
> > > >>label, but there is no reason that a translation mechanism could not be
> > > >>implemented to provide a common network security label that could be
> > > >>understood and internalized by both types of systems. While I'm not
> > > >>holding this up as a particularly good example in all cases, we do have
> > > >>something similar to this today in SELinux with how we handle the CIPSO
> > > >>protocol.
> > >
> > > I hope the above explained it. In a way my above explanation
> > > agrees with what you are saying here.
> > >
> > > >> - length (2 octets) - The third and fourth octets contain the
> > > >> string length of the security context.
> > > >>
> > > >> - security label (1 or more octets) - The security label. The
> > > >> actual content will be dependent on the security algorithm
> > > >> that is specified. Within IKE context, this is regarded as
> > > >> an opaque bit string.
> > > >
> > > >I'm being picky here, but it might be better to say "opaque bit field"
> > > >just so we don't get into string encoding issues (is it UTF-8 or
> > > >something else?).
> > >
> > > Ok, will do
> >
> > I think the proper terminology is an "opaque byte" something where
> > something is an array, or a stream</pedantic>. At least that is what we
> > use in the NFSv4 documents, however they use XDR encoding and that term
> > is actually defined. I'm not sure if the IPSec document already has
> > definitions for these data types. The problem here is opaque usually
> > means with respect to the protocol not the encoding. So I think you
> > should make a decision on the string encoding or it might turn into an
> > interop nightmare. It's fine to say the semantic meaning of the string
> > is opaque to the protocol but you should agree on if your sending UTF-8
> > or whatever.
> >
>
> Ahh, yes! Thanks for pointing that out! Let me go investigate and
> determine which encoding.
>
> Thanks!
>
> Hopefully, will send out a revised draft with both Paul and David's
> improvements soon.
>
> regards,
> Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-26 20:24 ` David P. Quigley
@ 2008-08-27 16:17 ` Joy Latten
2008-08-27 16:49 ` David P. Quigley
0 siblings, 1 reply; 23+ messages in thread
From: Joy Latten @ 2008-08-27 16:17 UTC (permalink / raw)
To: David P. Quigley; +Cc: paul.moore, gcwilson, selinux, serue, tjaeger
On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
> > > [Snip...]
> > > >
> > > > >>
> > > > >> - doi (1 octet) - The first octet contains the security
> > > > >> label's domain of interpretation.
> > > > >>
> > > > >> The domain of interpretation can be viewed as a group of
> > > > >> systems that agree on the meaning of particular values
> > > > >> within the security label of a security mechanism.
> > > > >>
> > > > >> The value of 1 is reserved as the default.
> > > > >>
> > > > >> Reserved 0
> > > > >> Default 1
> > > > >>
> > > > >> - algorithm (1 octet) - The second octet contains the security
> > > > >> label's algorithm.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> Latten, et al. Expires ? [Page
> > > > >> 3]
> > > > >> Internet-Draft IKEv1SecurityLabel June
> > > > >> 2008
> > > > >>
> > > > >>
> > > > >> The security label's algorithm specifies the security
> > > > >> mechanism or context in which the label is applicable. For
> > > > >> example, the security label is interpreted within the
> > > > >> SELinux context.
> > > > >>
> > > > >> Requests for assignment of additional algorithms should be
> > > > >> addressed to the Internet Assigned Numbers Authority (IANA).
> > > > >>
> > > > >> Reserved 0
> > > > >> SELinux 1
> > > > >> Smack 2
> > > > >> Private Use 120-128
> > > > >
> > > > >Is one octet enough here? I honestly don't have a good idea as to how
> > > > >much is enough, so a little justification of your choice (even if it
> > > > >only lives in email, not in the spec) would be welcome.
> > > >
> > > > I used one octet here because it is defined as one octet in the kernel's
> > > > sec_ctx structure. Originally, I think we used one octect for each
> > > > to keep within a 64-bit alignment requirement for pfkey. We thought
> > > > one octet would be enough...
> > > >
> > >
> > > There are several documents being submitted as drafts to the IETF at the
> > > moment and all of them have different definitions of a DOI.
> > >
> > > In your method you pair a mechanism with the DOI to form something along
> > > the lines of a (mechanism,policyversion) tuple. The question of if one
> > > octet is enough to identify all potential policies in a mechanism is
> > > unclear but I have a feeling the answer will be no.
> > >
> > > The second method is in the SIPSO for IPv6 draft. In this the DOI is a
> > > 32 bit value existing as 4 octets. They partition off what are
> > > essentially address spaces to be used privately, by certain
> > > organizations, and they also keep a block for IETF considerations in
> > > later revisions of the specification. There is a lot of information in
> > > the document and most of it pertains to MLS labels.
> > >
> > > The third method is in the label support for NFSv4 draft. In this we
> > > just define the DOI as a 32 big value. It is up to a translation daemon
> > > to decide if the endpoint has the knowledge and desire to translate
> > > labels from the foreign DOI to its own.
> > >
> > > Regardless of which method is used we need to come to a consensus on
> > > what a DOI is and how we are going to represent it. We can't go to the
> > > IETF with 3 different definitions of a DOI.
> > >
> >
> > I just now quickly glanced at the CALIPSO draft as I had not read
> > it before. I did read the labeled nfs draft a while back.
> >
> > I see what you mean. However, I guess I am feeling a bit wary since
> > the CALIPSO draft's description of the DOI and it's format seem to be
> > tailored specifically for MLS labels. The labeled ipsec's doi field had
> > a broader purpose in mind.
>
> Yea, it is unfortunate that CALIPSO is only for MLS labels. IPv6 is
> still growing in its deployment so it would be nice to have a robust and
> flexible method for conveying security labels from the start. For now it
> seems as if CALIPSO will try to go through just as MLS labels and then
> DTE or other security labels will have to create their own IP security
> option.
>
> >
> > > > >I'm also concerned with the implied convention of assigning one value to
> > > > >a particular implementation. In the SELinux case, how do you deal with
> > > > >a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
> > > > >such as Fedora/RHEL? What about policies with different types?
> > > > >Differing numbers of MLS sensitivity levels or categories?
> > > > >
> > > >
> > > > Hmm... not sure I understand so I may not answer this correctly...
> > > >
> > > > The algorithm indicates the security mechanism.
> > > > In a way, it identifies the syntax/semantics of the
> > > > security context to security mechanism, since security mechanisms
> > > > may use different syntax/semantics for the security contexts.
> > > > i.e. SELinux and SMACK.
> > > > The algorithm field in SELinux is used to "authorize" the security
> > > > context. In other words, SELinux only wants and understands
> > > > SELinux's security context syntax/semantics.
> > > > The "doi" would be used for further differentiation within SELinux
> > > > domain. Far example, a sysadm wants to differentiate between SELinux
> > > > policy versions in his domain. He could used "doi" field to do this.
> > > >
> > > > I suppose if you wanted two different security mechanisms to
> > > > interoperate, a mapping of some sort would have to be created
> > > > between them. The security mechanisms would need
> > > > to indicate they accept (via the mapping) the other's
> > > > security context syntax/semantics. In other words, they would "authorize"
> > > > the two different security contexts. It would do this via the
> > > > "algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
> > > > even indicate the mapping such as CIPSO's DOI does.
> > > >
> > > > I considered the information contained in the "algorithm" and
> > > > "doi" fields required for interoperability, and the use
> > > > implementation specific.
> > > >
> > > > If this doesn't answer your question, let me know.
> > >
> > > I think what Paul might be asking is why is it better to have two
> > > fields, one for Security Mechanism and one for the DOI when that can be
> > > one field. If we go with a method similar to the second described above
> > > for DOIs you could have IANA allocate a range of DOIs for SELinux
> > > partitioning it off into a range for publicly assigned DOIs and
> > > privately managed DOIs. It is acceptable to have IANA create and
> > > populate a registry with values in the document.
> > >
> >
> > Ok, I understand now. Yes, that seems reasonable, fair, and flexible.
> > I can still keep semantics (a mechanism and ability to group or
> > differentiate).
> >
> > So, a doi field that is 32 bits, with perhaps so much for SELinux,
> > further partitioned for public and private use. The same for Smack.
> > Right? And remaining for future use.
>
> The standards people don't particularly care about specific security
> models in this case. I initially mentioned implementation specific
> details in my early labeled NFS drafts and was told that those aren't
> really a concern of the protocol. Since the label is a (DOI,<OPAQUE>)
> tuple it is up to whomever obtains a number from IANA to define the
> meaning of that DOI. However it should be written into the standard what
> information is recorded by IANA to bind to these numbers. Also do we see
> several registries? I really only see one registry that can be shared by
> all three of these drafts. I just hope they don't want us to write up an
> RFC for the definition and management of DOIs (it might happen that way
> though).
>
Ok, gotta admit, I am a little confused as to how we could share the
same DOI registry with CALIPSO since they are using a dotted-quad format
right now? And it doesn't seem to accomodate but one DOI from IANA which
leaves me confused as to how I would get one and then partition it for
private and non-private uses.
Because there is already a working prototype of labeled ipsec in
Linux, I would have very much like to get assignments from IANA
now for SELinux. I would like to make necessary modifications to Linux
kernel and userspace soon as possible because it would seem odd to me to
have an internet draft and a prototype that does not comply to it. It
would also help to set a precedent of what would be required when asking
for DOI assignments ( I hope I said that correctly).
> >
> > Would this be a consensus in regards to DOI for labeled nfs, labeled
> > ipsec, and CALIPSO drafts?
> >
>
> I would like to think that we could establish one definition of a DOI
> for IETF documents. I spoke with several people at the last IETF meeting
> and they said that we need to stay consistent here. I will be trying to
> organize a security label BOF at the next IETF meeting so we can sit
> down and discuss the way things should work. I doubt this will spawn a
> working group for security labels but we could come to a consensus on
> certain things.
>
Ahh, ok. Please let me know if you schedule this BOF.
I guess my concern is I want to get my drafts submitted now.
Because there is a working prototype, I felt it best
to go ahead and ask for the IANA assignments now.
But I do agree with what you are saying... just need to figure
out how I should proceed...
regards,
Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 16:17 ` Joy Latten
@ 2008-08-27 16:49 ` David P. Quigley
2008-08-27 18:41 ` Joy Latten
0 siblings, 1 reply; 23+ messages in thread
From: David P. Quigley @ 2008-08-27 16:49 UTC (permalink / raw)
To: Joy Latten; +Cc: paul.moore, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 11:17 -0500, Joy Latten wrote:
> On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> > On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
> > > > [Snip...]
> > > > >
> > > > > >>
> > > > > >> - doi (1 octet) - The first octet contains the security
> > > > > >> label's domain of interpretation.
> > > > > >>
> > > > > >> The domain of interpretation can be viewed as a group of
> > > > > >> systems that agree on the meaning of particular values
> > > > > >> within the security label of a security mechanism.
> > > > > >>
> > > > > >> The value of 1 is reserved as the default.
> > > > > >>
> > > > > >> Reserved 0
> > > > > >> Default 1
> > > > > >>
> > > > > >> - algorithm (1 octet) - The second octet contains the security
> > > > > >> label's algorithm.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Latten, et al. Expires ? [Page
> > > > > >> 3]
> > > > > >> Internet-Draft IKEv1SecurityLabel June
> > > > > >> 2008
> > > > > >>
> > > > > >>
> > > > > >> The security label's algorithm specifies the security
> > > > > >> mechanism or context in which the label is applicable. For
> > > > > >> example, the security label is interpreted within the
> > > > > >> SELinux context.
> > > > > >>
> > > > > >> Requests for assignment of additional algorithms should be
> > > > > >> addressed to the Internet Assigned Numbers Authority (IANA).
> > > > > >>
> > > > > >> Reserved 0
> > > > > >> SELinux 1
> > > > > >> Smack 2
> > > > > >> Private Use 120-128
> > > > > >
> > > > > >Is one octet enough here? I honestly don't have a good idea as to how
> > > > > >much is enough, so a little justification of your choice (even if it
> > > > > >only lives in email, not in the spec) would be welcome.
> > > > >
> > > > > I used one octet here because it is defined as one octet in the kernel's
> > > > > sec_ctx structure. Originally, I think we used one octect for each
> > > > > to keep within a 64-bit alignment requirement for pfkey. We thought
> > > > > one octet would be enough...
> > > > >
> > > >
> > > > There are several documents being submitted as drafts to the IETF at the
> > > > moment and all of them have different definitions of a DOI.
> > > >
> > > > In your method you pair a mechanism with the DOI to form something along
> > > > the lines of a (mechanism,policyversion) tuple. The question of if one
> > > > octet is enough to identify all potential policies in a mechanism is
> > > > unclear but I have a feeling the answer will be no.
> > > >
> > > > The second method is in the SIPSO for IPv6 draft. In this the DOI is a
> > > > 32 bit value existing as 4 octets. They partition off what are
> > > > essentially address spaces to be used privately, by certain
> > > > organizations, and they also keep a block for IETF considerations in
> > > > later revisions of the specification. There is a lot of information in
> > > > the document and most of it pertains to MLS labels.
> > > >
> > > > The third method is in the label support for NFSv4 draft. In this we
> > > > just define the DOI as a 32 big value. It is up to a translation daemon
> > > > to decide if the endpoint has the knowledge and desire to translate
> > > > labels from the foreign DOI to its own.
> > > >
> > > > Regardless of which method is used we need to come to a consensus on
> > > > what a DOI is and how we are going to represent it. We can't go to the
> > > > IETF with 3 different definitions of a DOI.
> > > >
> > >
> > > I just now quickly glanced at the CALIPSO draft as I had not read
> > > it before. I did read the labeled nfs draft a while back.
> > >
> > > I see what you mean. However, I guess I am feeling a bit wary since
> > > the CALIPSO draft's description of the DOI and it's format seem to be
> > > tailored specifically for MLS labels. The labeled ipsec's doi field had
> > > a broader purpose in mind.
> >
> > Yea, it is unfortunate that CALIPSO is only for MLS labels. IPv6 is
> > still growing in its deployment so it would be nice to have a robust and
> > flexible method for conveying security labels from the start. For now it
> > seems as if CALIPSO will try to go through just as MLS labels and then
> > DTE or other security labels will have to create their own IP security
> > option.
> >
> > >
> > > > > >I'm also concerned with the implied convention of assigning one value to
> > > > > >a particular implementation. In the SELinux case, how do you deal with
> > > > > >a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
> > > > > >such as Fedora/RHEL? What about policies with different types?
> > > > > >Differing numbers of MLS sensitivity levels or categories?
> > > > > >
> > > > >
> > > > > Hmm... not sure I understand so I may not answer this correctly...
> > > > >
> > > > > The algorithm indicates the security mechanism.
> > > > > In a way, it identifies the syntax/semantics of the
> > > > > security context to security mechanism, since security mechanisms
> > > > > may use different syntax/semantics for the security contexts.
> > > > > i.e. SELinux and SMACK.
> > > > > The algorithm field in SELinux is used to "authorize" the security
> > > > > context. In other words, SELinux only wants and understands
> > > > > SELinux's security context syntax/semantics.
> > > > > The "doi" would be used for further differentiation within SELinux
> > > > > domain. Far example, a sysadm wants to differentiate between SELinux
> > > > > policy versions in his domain. He could used "doi" field to do this.
> > > > >
> > > > > I suppose if you wanted two different security mechanisms to
> > > > > interoperate, a mapping of some sort would have to be created
> > > > > between them. The security mechanisms would need
> > > > > to indicate they accept (via the mapping) the other's
> > > > > security context syntax/semantics. In other words, they would "authorize"
> > > > > the two different security contexts. It would do this via the
> > > > > "algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
> > > > > even indicate the mapping such as CIPSO's DOI does.
> > > > >
> > > > > I considered the information contained in the "algorithm" and
> > > > > "doi" fields required for interoperability, and the use
> > > > > implementation specific.
> > > > >
> > > > > If this doesn't answer your question, let me know.
> > > >
> > > > I think what Paul might be asking is why is it better to have two
> > > > fields, one for Security Mechanism and one for the DOI when that can be
> > > > one field. If we go with a method similar to the second described above
> > > > for DOIs you could have IANA allocate a range of DOIs for SELinux
> > > > partitioning it off into a range for publicly assigned DOIs and
> > > > privately managed DOIs. It is acceptable to have IANA create and
> > > > populate a registry with values in the document.
> > > >
> > >
> > > Ok, I understand now. Yes, that seems reasonable, fair, and flexible.
> > > I can still keep semantics (a mechanism and ability to group or
> > > differentiate).
> > >
> > > So, a doi field that is 32 bits, with perhaps so much for SELinux,
> > > further partitioned for public and private use. The same for Smack.
> > > Right? And remaining for future use.
> >
> > The standards people don't particularly care about specific security
> > models in this case. I initially mentioned implementation specific
> > details in my early labeled NFS drafts and was told that those aren't
> > really a concern of the protocol. Since the label is a (DOI,<OPAQUE>)
> > tuple it is up to whomever obtains a number from IANA to define the
> > meaning of that DOI. However it should be written into the standard what
> > information is recorded by IANA to bind to these numbers. Also do we see
> > several registries? I really only see one registry that can be shared by
> > all three of these drafts. I just hope they don't want us to write up an
> > RFC for the definition and management of DOIs (it might happen that way
> > though).
> >
>
> Ok, gotta admit, I am a little confused as to how we could share the
> same DOI registry with CALIPSO since they are using a dotted-quad format
> right now? And it doesn't seem to accomodate but one DOI from IANA which
> leaves me confused as to how I would get one and then partition it for
> private and non-private uses.
Well we might need to talk with the CALIPSO people to figure out a way
that we can all use their DOI scheme. At its core their method just
seems to be a dotted-quad format as you have said. IANA's job is to keep
track of these dotted-quads.
Excerpt from CALIPSO Draft
DOI Value Organisation or Use
======================= ============================
0:0:0:0 Null DOI; MUST NOT be used
on any network at any time.
0:0:0:1 to 0:255:255:255 For private use among
consenting parties within
private networks; for reasons
of interoperability, these
DOI values MUST NOT ever
appear on the global public
Internet.
1:0:0:0 to 254:255:255:255 For assignment by IANA to
organisations following the
guidelines in the paragraph
below.
255:0:0:0 to 255:0:0:0 Reserved to the IETF for
future use by possible
revisions of this specification.
So according to this table IANA can assign anything in the range in section 3.
This means if you wanted to you could ask IANA to reserve
1:0:1:*-1:0:2:* for SELinux DOIs stating that anything in the class C
starting with 1 is public and starting with 2 is private.
I am just taking the CALIPSO mechanism for DOIs here and not the
requirements of how many are issued to what organizations and whatnot.
This would need to be something discussed at the BOF.
>
> Because there is already a working prototype of labeled ipsec in
> Linux, I would have very much like to get assignments from IANA
> now for SELinux. I would like to make necessary modifications to Linux
> kernel and userspace soon as possible because it would seem odd to me to
> have an internet draft and a prototype that does not comply to it. It
> would also help to set a precedent of what would be required when asking
> for DOI assignments ( I hope I said that correctly).
>
> > >
> > > Would this be a consensus in regards to DOI for labeled nfs, labeled
> > > ipsec, and CALIPSO drafts?
> > >
> >
> > I would like to think that we could establish one definition of a DOI
> > for IETF documents. I spoke with several people at the last IETF meeting
> > and they said that we need to stay consistent here. I will be trying to
> > organize a security label BOF at the next IETF meeting so we can sit
> > down and discuss the way things should work. I doubt this will spawn a
> > working group for security labels but we could come to a consensus on
> > certain things.
> >
>
> Ahh, ok. Please let me know if you schedule this BOF.
> I guess my concern is I want to get my drafts submitted now.
> Because there is a working prototype, I felt it best
> to go ahead and ask for the IANA assignments now.
> But I do agree with what you are saying... just need to figure
> out how I should proceed...
Don't fall into the same trap that I did initially thinking that just
because you submitted a draft that it is set in stone. It is common for
a draft to change many times even before it hits the implementation
phase of the standards process. Then once you have multiple people
implementing the standard you will probably run into other problems that
you didn't think of initially. It is a good idea for you to submit the
draft with your concept of a DOI at this point since it gives us several
drafts to consider in the BOF.
Something else to remember is that the fast paced development model of
the Linux community doesn't mesh well with the IETF process. I was at
the NFSv4 WG meeting in Dublin and I had asked about getting my work
added to the charter. They said it could be done between meetings which
is a good thing. To this I responded that it was good that this could be
done quickly and that I didn't have to wait four months to get it done.
One of the directors replied well four months is quick. So patience is a
virtue in this venue.
About the BOF, I sent an email to the Security Area Director about
setting up a BOF and it was suggested that we start with a Bar BOF
first. This type of BOF isn't as formal as a normal one but regular BOFs
are usually formed for the purpose of trying to start a working group.
Even though it is an informal BOF it still needs to have a clear purpose
and a set of goals to accomplish. The main issue I see at the moment is
going to be DOIs. Like we've seen we have three competing definitions of
them and it would be nice to nail it down to one that we can all agree
on.
However this doesn't necessarily have to be the only thing we discuss.
When I post the information about the Bar BOF I am going to do a call
for participation for other topics as well. For all we know there might
be other security label people lurking in other working groups that
might have topics they want to discuss.
Dave
>
> regards,
> Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 16:49 ` David P. Quigley
@ 2008-08-27 18:41 ` Joy Latten
2008-08-27 20:50 ` Paul Moore
2008-08-27 21:21 ` David P. Quigley
0 siblings, 2 replies; 23+ messages in thread
From: Joy Latten @ 2008-08-27 18:41 UTC (permalink / raw)
To: David P. Quigley; +Cc: paul.moore, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 12:49 -0400, David P. Quigley wrote:
> On Wed, 2008-08-27 at 11:17 -0500, Joy Latten wrote:
> > On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> > > On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > > > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
> > > > > [Snip...]
> > > > > >
> > > > > > >>
> > > > > > >> - doi (1 octet) - The first octet contains the security
> > > > > > >> label's domain of interpretation.
> > > > > > >>
> > > > > > >> The domain of interpretation can be viewed as a group of
> > > > > > >> systems that agree on the meaning of particular values
> > > > > > >> within the security label of a security mechanism.
> > > > > > >>
> > > > > > >> The value of 1 is reserved as the default.
> > > > > > >>
> > > > > > >> Reserved 0
> > > > > > >> Default 1
> > > > > > >>
> > > > > > >> - algorithm (1 octet) - The second octet contains the security
> > > > > > >> label's algorithm.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> Latten, et al. Expires ? [Page
> > > > > > >> 3]
> > > > > > >> Internet-Draft IKEv1SecurityLabel June
> > > > > > >> 2008
> > > > > > >>
> > > > > > >>
> > > > > > >> The security label's algorithm specifies the security
> > > > > > >> mechanism or context in which the label is applicable. For
> > > > > > >> example, the security label is interpreted within the
> > > > > > >> SELinux context.
> > > > > > >>
> > > > > > >> Requests for assignment of additional algorithms should be
> > > > > > >> addressed to the Internet Assigned Numbers Authority (IANA).
> > > > > > >>
> > > > > > >> Reserved 0
> > > > > > >> SELinux 1
> > > > > > >> Smack 2
> > > > > > >> Private Use 120-128
> > > > > > >
> > > > > > >Is one octet enough here? I honestly don't have a good idea as to how
> > > > > > >much is enough, so a little justification of your choice (even if it
> > > > > > >only lives in email, not in the spec) would be welcome.
> > > > > >
> > > > > > I used one octet here because it is defined as one octet in the kernel's
> > > > > > sec_ctx structure. Originally, I think we used one octect for each
> > > > > > to keep within a 64-bit alignment requirement for pfkey. We thought
> > > > > > one octet would be enough...
> > > > > >
> > > > >
> > > > > There are several documents being submitted as drafts to the IETF at the
> > > > > moment and all of them have different definitions of a DOI.
> > > > >
> > > > > In your method you pair a mechanism with the DOI to form something along
> > > > > the lines of a (mechanism,policyversion) tuple. The question of if one
> > > > > octet is enough to identify all potential policies in a mechanism is
> > > > > unclear but I have a feeling the answer will be no.
> > > > >
> > > > > The second method is in the SIPSO for IPv6 draft. In this the DOI is a
> > > > > 32 bit value existing as 4 octets. They partition off what are
> > > > > essentially address spaces to be used privately, by certain
> > > > > organizations, and they also keep a block for IETF considerations in
> > > > > later revisions of the specification. There is a lot of information in
> > > > > the document and most of it pertains to MLS labels.
> > > > >
> > > > > The third method is in the label support for NFSv4 draft. In this we
> > > > > just define the DOI as a 32 big value. It is up to a translation daemon
> > > > > to decide if the endpoint has the knowledge and desire to translate
> > > > > labels from the foreign DOI to its own.
> > > > >
> > > > > Regardless of which method is used we need to come to a consensus on
> > > > > what a DOI is and how we are going to represent it. We can't go to the
> > > > > IETF with 3 different definitions of a DOI.
> > > > >
> > > >
> > > > I just now quickly glanced at the CALIPSO draft as I had not read
> > > > it before. I did read the labeled nfs draft a while back.
> > > >
> > > > I see what you mean. However, I guess I am feeling a bit wary since
> > > > the CALIPSO draft's description of the DOI and it's format seem to be
> > > > tailored specifically for MLS labels. The labeled ipsec's doi field had
> > > > a broader purpose in mind.
> > >
> > > Yea, it is unfortunate that CALIPSO is only for MLS labels. IPv6 is
> > > still growing in its deployment so it would be nice to have a robust and
> > > flexible method for conveying security labels from the start. For now it
> > > seems as if CALIPSO will try to go through just as MLS labels and then
> > > DTE or other security labels will have to create their own IP security
> > > option.
> > >
> > > >
> > > > > > >I'm also concerned with the implied convention of assigning one value to
> > > > > > >a particular implementation. In the SELinux case, how do you deal with
> > > > > > >a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
> > > > > > >such as Fedora/RHEL? What about policies with different types?
> > > > > > >Differing numbers of MLS sensitivity levels or categories?
> > > > > > >
> > > > > >
> > > > > > Hmm... not sure I understand so I may not answer this correctly...
> > > > > >
> > > > > > The algorithm indicates the security mechanism.
> > > > > > In a way, it identifies the syntax/semantics of the
> > > > > > security context to security mechanism, since security mechanisms
> > > > > > may use different syntax/semantics for the security contexts.
> > > > > > i.e. SELinux and SMACK.
> > > > > > The algorithm field in SELinux is used to "authorize" the security
> > > > > > context. In other words, SELinux only wants and understands
> > > > > > SELinux's security context syntax/semantics.
> > > > > > The "doi" would be used for further differentiation within SELinux
> > > > > > domain. Far example, a sysadm wants to differentiate between SELinux
> > > > > > policy versions in his domain. He could used "doi" field to do this.
> > > > > >
> > > > > > I suppose if you wanted two different security mechanisms to
> > > > > > interoperate, a mapping of some sort would have to be created
> > > > > > between them. The security mechanisms would need
> > > > > > to indicate they accept (via the mapping) the other's
> > > > > > security context syntax/semantics. In other words, they would "authorize"
> > > > > > the two different security contexts. It would do this via the
> > > > > > "algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
> > > > > > even indicate the mapping such as CIPSO's DOI does.
> > > > > >
> > > > > > I considered the information contained in the "algorithm" and
> > > > > > "doi" fields required for interoperability, and the use
> > > > > > implementation specific.
> > > > > >
> > > > > > If this doesn't answer your question, let me know.
> > > > >
> > > > > I think what Paul might be asking is why is it better to have two
> > > > > fields, one for Security Mechanism and one for the DOI when that can be
> > > > > one field. If we go with a method similar to the second described above
> > > > > for DOIs you could have IANA allocate a range of DOIs for SELinux
> > > > > partitioning it off into a range for publicly assigned DOIs and
> > > > > privately managed DOIs. It is acceptable to have IANA create and
> > > > > populate a registry with values in the document.
> > > > >
> > > >
> > > > Ok, I understand now. Yes, that seems reasonable, fair, and flexible.
> > > > I can still keep semantics (a mechanism and ability to group or
> > > > differentiate).
> > > >
> > > > So, a doi field that is 32 bits, with perhaps so much for SELinux,
> > > > further partitioned for public and private use. The same for Smack.
> > > > Right? And remaining for future use.
> > >
> > > The standards people don't particularly care about specific security
> > > models in this case. I initially mentioned implementation specific
> > > details in my early labeled NFS drafts and was told that those aren't
> > > really a concern of the protocol. Since the label is a (DOI,<OPAQUE>)
> > > tuple it is up to whomever obtains a number from IANA to define the
> > > meaning of that DOI. However it should be written into the standard what
> > > information is recorded by IANA to bind to these numbers. Also do we see
> > > several registries? I really only see one registry that can be shared by
> > > all three of these drafts. I just hope they don't want us to write up an
> > > RFC for the definition and management of DOIs (it might happen that way
> > > though).
> > >
> >
> > Ok, gotta admit, I am a little confused as to how we could share the
> > same DOI registry with CALIPSO since they are using a dotted-quad format
> > right now? And it doesn't seem to accomodate but one DOI from IANA which
> > leaves me confused as to how I would get one and then partition it for
> > private and non-private uses.
>
> Well we might need to talk with the CALIPSO people to figure out a way
> that we can all use their DOI scheme. At its core their method just
> seems to be a dotted-quad format as you have said. IANA's job is to keep
> track of these dotted-quads.
>
> Excerpt from CALIPSO Draft
>
> DOI Value Organisation or Use
> ======================= ============================
> 0:0:0:0 Null DOI; MUST NOT be used
> on any network at any time.
> 0:0:0:1 to 0:255:255:255 For private use among
> consenting parties within
> private networks; for reasons
> of interoperability, these
> DOI values MUST NOT ever
> appear on the global public
> Internet.
> 1:0:0:0 to 254:255:255:255 For assignment by IANA to
> organisations following the
> guidelines in the paragraph
> below.
> 255:0:0:0 to 255:0:0:0 Reserved to the IETF for
> future use by possible
> revisions of this specification.
>
>
> So according to this table IANA can assign anything in the range in section 3.
>
> This means if you wanted to you could ask IANA to reserve
> 1:0:1:*-1:0:2:* for SELinux DOIs stating that anything in the class C
> starting with 1 is public and starting with 2 is private.
>
> I am just taking the CALIPSO mechanism for DOIs here and not the
> requirements of how many are issued to what organizations and whatnot.
>
> This would need to be something discussed at the BOF.
>
Ok, thanks for clearing that up. As you have stated is how I interpreted
the draft. Because there were restrictions on how many DOIs could be
issued to an organization, I became concerned and thought perhaps I had
not interpreted correctly.
> >
> > Because there is already a working prototype of labeled ipsec in
> > Linux, I would have very much like to get assignments from IANA
> > now for SELinux. I would like to make necessary modifications to Linux
> > kernel and userspace soon as possible because it would seem odd to me to
> > have an internet draft and a prototype that does not comply to it. It
> > would also help to set a precedent of what would be required when asking
> > for DOI assignments ( I hope I said that correctly).
> >
> > > >
> > > > Would this be a consensus in regards to DOI for labeled nfs, labeled
> > > > ipsec, and CALIPSO drafts?
> > > >
> > >
> > > I would like to think that we could establish one definition of a DOI
> > > for IETF documents. I spoke with several people at the last IETF meeting
> > > and they said that we need to stay consistent here. I will be trying to
> > > organize a security label BOF at the next IETF meeting so we can sit
> > > down and discuss the way things should work. I doubt this will spawn a
> > > working group for security labels but we could come to a consensus on
> > > certain things.
> > >
> >
> > Ahh, ok. Please let me know if you schedule this BOF.
> > I guess my concern is I want to get my drafts submitted now.
> > Because there is a working prototype, I felt it best
> > to go ahead and ask for the IANA assignments now.
> > But I do agree with what you are saying... just need to figure
> > out how I should proceed...
>
> Don't fall into the same trap that I did initially thinking that just
> because you submitted a draft that it is set in stone. It is common for
> a draft to change many times even before it hits the implementation
> phase of the standards process. Then once you have multiple people
> implementing the standard you will probably run into other problems that
> you didn't think of initially. It is a good idea for you to submit the
> draft with your concept of a DOI at this point since it gives us several
> drafts to consider in the BOF.
>
Ok, thanks. I will take that advice to heart.
When you recommend submitting my draft with my concept of DOI,
do you mean as I originally had it with algorithm and doi field of one
octet each, or in a more generic manner as the labeled NFS draft?
I am open to what this community thinks is best way to do it at this
point.
> Something else to remember is that the fast paced development model of
> the Linux community doesn't mesh well with the IETF process. I was at
> the NFSv4 WG meeting in Dublin and I had asked about getting my work
> added to the charter. They said it could be done between meetings which
> is a good thing. To this I responded that it was good that this could be
> done quickly and that I didn't have to wait four months to get it done.
> One of the directors replied well four months is quick. So patience is a
> virtue in this venue.
>
Gotta remember that. :-)
It has taken so long to get the drafts to this point that I guess I
am somewhat anxious. :-)
>
> About the BOF, I sent an email to the Security Area Director about
> setting up a BOF and it was suggested that we start with a Bar BOF
> first. This type of BOF isn't as formal as a normal one but regular BOFs
> are usually formed for the purpose of trying to start a working group.
> Even though it is an informal BOF it still needs to have a clear purpose
> and a set of goals to accomplish. The main issue I see at the moment is
> going to be DOIs. Like we've seen we have three competing definitions of
> them and it would be nice to nail it down to one that we can all agree
> on.
>
> However this doesn't necessarily have to be the only thing we discuss.
> When I post the information about the Bar BOF I am going to do a call
> for participation for other topics as well. For all we know there might
> be other security label people lurking in other working groups that
> might have topics they want to discuss.
>
Ok. I am definitely interested.
Thanks!!
regards,
Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 18:41 ` Joy Latten
@ 2008-08-27 20:50 ` Paul Moore
2008-08-27 21:33 ` David P. Quigley
2008-08-27 23:27 ` Joy Latten
2008-08-27 21:21 ` David P. Quigley
1 sibling, 2 replies; 23+ messages in thread
From: Paul Moore @ 2008-08-27 20:50 UTC (permalink / raw)
To: Joy Latten; +Cc: David P. Quigley, gcwilson, selinux, serue, tjaeger
Hi Joy, et al.
I'll respond to the rest of you email a little bit later when I have
some time but since you and David have been having a good discussion
around DOI issues I wanted to add some quick comments ... (see below)
On Wednesday 27 August 2008 2:41:48 pm Joy Latten wrote:
> On Wed, 2008-08-27 at 12:49 -0400, David P. Quigley wrote:
> > On Wed, 2008-08-27 at 11:17 -0500, Joy Latten wrote:
> > > On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> > > > On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > > > > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > > > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
...
> > > > Yea, it is unfortunate that CALIPSO is only for MLS labels.
> > > > IPv6 is still growing in its deployment so it would be nice to
> > > > have a robust and flexible method for conveying security labels
> > > > from the start. For now it seems as if CALIPSO will try to go
> > > > through just as MLS labels and then DTE or other security
> > > > labels will have to create their own IP security option.
I've had many discussions with Randall regarding this topic, I even
offered a series of edits to earlier CALIPSO (back when it was still
SIPSO, yipee for the name change!) drafts which introduced a more
generic DTE labeling mechanism. After much discussion Randall agreed
that having a more generic, DTE-friendly labeling mechanism would be
nice but he wanted to keep CALIPSO focused on MLS labeling since that
was the feedback he had been receiving. He was very helpful and the
discussion unveiled many potential issues with a DTE labeling protocol,
primarily around the need to make the protocol more intermediate hop
friendly.
I am currently waiting to see how the CALIPSO specification is received
by the general IETF SAAG community, especially the assertion that
explicit packet labeling is an important user requirement. If the
CALIPSO specification is well received I plan on submitting a draft
specification which will provide a more general packet labeling
mechanism for IPv6 and possibly IPv4.
> > > > > > > >I'm also concerned with the implied convention of
> > > > > > > > assigning one value to a particular implementation. In
> > > > > > > > the SELinux case, how do you deal with a non-MLS/MCS
> > > > > > > > policy such as Gentoo/Ubuntu talking to a MLS/MCS
> > > > > > > > policy such as Fedora/RHEL? What about policies with
> > > > > > > > different types? Differing numbers of MLS sensitivity
> > > > > > > > levels or categories?
> > > > > > >
> > > > > > > Hmm... not sure I understand so I may not answer this
> > > > > > > correctly...
> > > > > > >
> > > > > > > The algorithm indicates the security mechanism.
> > > > > > > In a way, it identifies the syntax/semantics of the
> > > > > > > security context to security mechanism, since security
> > > > > > > mechanisms may use different syntax/semantics for the
> > > > > > > security contexts. i.e. SELinux and SMACK.
> > > > > > > The algorithm field in SELinux is used to "authorize" the
> > > > > > > security context. In other words, SELinux only wants and
> > > > > > > understands SELinux's security context syntax/semantics.
> > > > > > > The "doi" would be used for further differentiation
> > > > > > > within SELinux domain. Far example, a sysadm wants to
> > > > > > > differentiate between SELinux policy versions in his
> > > > > > > domain. He could used "doi" field to do this.
> > > > > > >
> > > > > > > I suppose if you wanted two different security mechanisms
> > > > > > > to interoperate, a mapping of some sort would have to be
> > > > > > > created between them. The security mechanisms would need
> > > > > > > to indicate they accept (via the mapping) the other's
> > > > > > > security context syntax/semantics. In other words, they
> > > > > > > would "authorize" the two different security contexts. It
> > > > > > > would do this via the "algorithm" and/or "doi" fields. I
> > > > > > > am thinking in this case, "doi" could even indicate the
> > > > > > > mapping such as CIPSO's DOI does.
> > > > > > >
> > > > > > > I considered the information contained in the "algorithm"
> > > > > > > and "doi" fields required for interoperability, and the
> > > > > > > use implementation specific.
> > > > > > >
> > > > > > > If this doesn't answer your question, let me know.
> > > > > >
> > > > > > I think what Paul might be asking is why is it better to
> > > > > > have two fields, one for Security Mechanism and one for the
> > > > > > DOI when that can be one field. If we go with a method
> > > > > > similar to the second described above for DOIs you could
> > > > > > have IANA allocate a range of DOIs for SELinux partitioning
> > > > > > it off into a range for publicly assigned DOIs and
> > > > > > privately managed DOIs. It is acceptable to have IANA
> > > > > > create and populate a registry with values in the document.
> > > > >
> > > > > Ok, I understand now. Yes, that seems reasonable, fair, and
> > > > > flexible. I can still keep semantics (a mechanism and ability
> > > > > to group or differentiate).
> > > > >
> > > > > So, a doi field that is 32 bits, with perhaps so much for
> > > > > SELinux, further partitioned for public and private use. The
> > > > > same for Smack. Right? And remaining for future use.
> > > >
> > > > The standards people don't particularly care about specific
> > > > security models in this case. I initially mentioned
> > > > implementation specific details in my early labeled NFS drafts
> > > > and was told that those aren't really a concern of the
> > > > protocol. Since the label is a (DOI,<OPAQUE>) tuple it is up to
> > > > whomever obtains a number from IANA to define the meaning of
> > > > that DOI. However it should be written into the standard what
> > > > information is recorded by IANA to bind to these numbers. Also
> > > > do we see several registries? I really only see one registry
> > > > that can be shared by all three of these drafts. I just hope
> > > > they don't want us to write up an RFC for the definition and
> > > > management of DOIs (it might happen that way though).
> > >
> > > Ok, gotta admit, I am a little confused as to how we could share
> > > the same DOI registry with CALIPSO since they are using a
> > > dotted-quad format right now? And it doesn't seem to accomodate
> > > but one DOI from IANA which leaves me confused as to how I would
> > > get one and then partition it for private and non-private uses.
> >
> > Well we might need to talk with the CALIPSO people to figure out a
> > way that we can all use their DOI scheme. At its core their method
> > just seems to be a dotted-quad format as you have said. IANA's job
> > is to keep track of these dotted-quads.
The CALIPSO DOI is defined as a opaque 32 bit unsigned integer, similar
to CIPSO and your description of labeled NFS's DOI. The dotted
notation used in part of the CALIPSO draft is just a convenient way of
representing the value in the same way we represent IPv4 addresses.
The CALIPSO specification does set aside DOI ranges for specific uses
(is this the source of confusion?) which I think is a good idea and I
would encourage other protocols to follow suit.
> > > Because there is already a working prototype of labeled ipsec in
> > > Linux, I would have very much like to get assignments from IANA
> > > now for SELinux. I would like to make necessary modifications to
> > > Linux kernel and userspace soon as possible because it would seem
> > > odd to me to have an internet draft and a prototype that does not
> > > comply to it. It would also help to set a precedent of what would
> > > be required when asking for DOI assignments ( I hope I said that
> > > correctly).
I'm sure you've gotten feedback from others on this but nothing
involving the IETF is "quick". Be prepared for a potentially lengthy
discussion and understand that just because the Linux Kernel already
has a labeled IPsec implementation does not mean it will be accepted
as-is by the IETF community.
> > About the BOF, I sent an email to the Security Area Director about
> > setting up a BOF and it was suggested that we start with a Bar BOF
> > first. This type of BOF isn't as formal as a normal one but regular
> > BOFs are usually formed for the purpose of trying to start a
> > working group. Even though it is an informal BOF it still needs to
> > have a clear purpose and a set of goals to accomplish. The main
> > issue I see at the moment is going to be DOIs. Like we've seen we
> > have three competing definitions of them and it would be nice to
> > nail it down to one that we can all agree on.
> >
> > However this doesn't necessarily have to be the only thing we
> > discuss. When I post the information about the Bar BOF I am going
> > to do a call for participation for other topics as well. For all we
> > know there might be other security label people lurking in other
> > working groups that might have topics they want to discuss.
Please include me in the BOF notice/invite.
--
paul moore
linux @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 18:41 ` Joy Latten
2008-08-27 20:50 ` Paul Moore
@ 2008-08-27 21:21 ` David P. Quigley
2008-08-27 21:56 ` Paul Moore
1 sibling, 1 reply; 23+ messages in thread
From: David P. Quigley @ 2008-08-27 21:21 UTC (permalink / raw)
To: Joy Latten; +Cc: paul.moore, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 13:41 -0500, Joy Latten wrote:
> On Wed, 2008-08-27 at 12:49 -0400, David P. Quigley wrote:
> > On Wed, 2008-08-27 at 11:17 -0500, Joy Latten wrote:
> > > On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> > > > On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > > > > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > > > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
> > > > > > [Snip...]
> > > > > > >
> > > > > > > >>
> > > > > > > >> - doi (1 octet) - The first octet contains the security
> > > > > > > >> label's domain of interpretation.
> > > > > > > >>
> > > > > > > >> The domain of interpretation can be viewed as a group of
> > > > > > > >> systems that agree on the meaning of particular values
> > > > > > > >> within the security label of a security mechanism.
> > > > > > > >>
> > > > > > > >> The value of 1 is reserved as the default.
> > > > > > > >>
> > > > > > > >> Reserved 0
> > > > > > > >> Default 1
> > > > > > > >>
> > > > > > > >> - algorithm (1 octet) - The second octet contains the security
> > > > > > > >> label's algorithm.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Latten, et al. Expires ? [Page
> > > > > > > >> 3]
> > > > > > > >> Internet-Draft IKEv1SecurityLabel June
> > > > > > > >> 2008
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> The security label's algorithm specifies the security
> > > > > > > >> mechanism or context in which the label is applicable. For
> > > > > > > >> example, the security label is interpreted within the
> > > > > > > >> SELinux context.
> > > > > > > >>
> > > > > > > >> Requests for assignment of additional algorithms should be
> > > > > > > >> addressed to the Internet Assigned Numbers Authority (IANA).
> > > > > > > >>
> > > > > > > >> Reserved 0
> > > > > > > >> SELinux 1
> > > > > > > >> Smack 2
> > > > > > > >> Private Use 120-128
> > > > > > > >
> > > > > > > >Is one octet enough here? I honestly don't have a good idea as to how
> > > > > > > >much is enough, so a little justification of your choice (even if it
> > > > > > > >only lives in email, not in the spec) would be welcome.
> > > > > > >
> > > > > > > I used one octet here because it is defined as one octet in the kernel's
> > > > > > > sec_ctx structure. Originally, I think we used one octect for each
> > > > > > > to keep within a 64-bit alignment requirement for pfkey. We thought
> > > > > > > one octet would be enough...
> > > > > > >
> > > > > >
> > > > > > There are several documents being submitted as drafts to the IETF at the
> > > > > > moment and all of them have different definitions of a DOI.
> > > > > >
> > > > > > In your method you pair a mechanism with the DOI to form something along
> > > > > > the lines of a (mechanism,policyversion) tuple. The question of if one
> > > > > > octet is enough to identify all potential policies in a mechanism is
> > > > > > unclear but I have a feeling the answer will be no.
> > > > > >
> > > > > > The second method is in the SIPSO for IPv6 draft. In this the DOI is a
> > > > > > 32 bit value existing as 4 octets. They partition off what are
> > > > > > essentially address spaces to be used privately, by certain
> > > > > > organizations, and they also keep a block for IETF considerations in
> > > > > > later revisions of the specification. There is a lot of information in
> > > > > > the document and most of it pertains to MLS labels.
> > > > > >
> > > > > > The third method is in the label support for NFSv4 draft. In this we
> > > > > > just define the DOI as a 32 big value. It is up to a translation daemon
> > > > > > to decide if the endpoint has the knowledge and desire to translate
> > > > > > labels from the foreign DOI to its own.
> > > > > >
> > > > > > Regardless of which method is used we need to come to a consensus on
> > > > > > what a DOI is and how we are going to represent it. We can't go to the
> > > > > > IETF with 3 different definitions of a DOI.
> > > > > >
> > > > >
> > > > > I just now quickly glanced at the CALIPSO draft as I had not read
> > > > > it before. I did read the labeled nfs draft a while back.
> > > > >
> > > > > I see what you mean. However, I guess I am feeling a bit wary since
> > > > > the CALIPSO draft's description of the DOI and it's format seem to be
> > > > > tailored specifically for MLS labels. The labeled ipsec's doi field had
> > > > > a broader purpose in mind.
> > > >
> > > > Yea, it is unfortunate that CALIPSO is only for MLS labels. IPv6 is
> > > > still growing in its deployment so it would be nice to have a robust and
> > > > flexible method for conveying security labels from the start. For now it
> > > > seems as if CALIPSO will try to go through just as MLS labels and then
> > > > DTE or other security labels will have to create their own IP security
> > > > option.
> > > >
> > > > >
> > > > > > > >I'm also concerned with the implied convention of assigning one value to
> > > > > > > >a particular implementation. In the SELinux case, how do you deal with
> > > > > > > >a non-MLS/MCS policy such as Gentoo/Ubuntu talking to a MLS/MCS policy
> > > > > > > >such as Fedora/RHEL? What about policies with different types?
> > > > > > > >Differing numbers of MLS sensitivity levels or categories?
> > > > > > > >
> > > > > > >
> > > > > > > Hmm... not sure I understand so I may not answer this correctly...
> > > > > > >
> > > > > > > The algorithm indicates the security mechanism.
> > > > > > > In a way, it identifies the syntax/semantics of the
> > > > > > > security context to security mechanism, since security mechanisms
> > > > > > > may use different syntax/semantics for the security contexts.
> > > > > > > i.e. SELinux and SMACK.
> > > > > > > The algorithm field in SELinux is used to "authorize" the security
> > > > > > > context. In other words, SELinux only wants and understands
> > > > > > > SELinux's security context syntax/semantics.
> > > > > > > The "doi" would be used for further differentiation within SELinux
> > > > > > > domain. Far example, a sysadm wants to differentiate between SELinux
> > > > > > > policy versions in his domain. He could used "doi" field to do this.
> > > > > > >
> > > > > > > I suppose if you wanted two different security mechanisms to
> > > > > > > interoperate, a mapping of some sort would have to be created
> > > > > > > between them. The security mechanisms would need
> > > > > > > to indicate they accept (via the mapping) the other's
> > > > > > > security context syntax/semantics. In other words, they would "authorize"
> > > > > > > the two different security contexts. It would do this via the
> > > > > > > "algorithm" and/or "doi" fields. I am thinking in this case, "doi" could
> > > > > > > even indicate the mapping such as CIPSO's DOI does.
> > > > > > >
> > > > > > > I considered the information contained in the "algorithm" and
> > > > > > > "doi" fields required for interoperability, and the use
> > > > > > > implementation specific.
> > > > > > >
> > > > > > > If this doesn't answer your question, let me know.
> > > > > >
> > > > > > I think what Paul might be asking is why is it better to have two
> > > > > > fields, one for Security Mechanism and one for the DOI when that can be
> > > > > > one field. If we go with a method similar to the second described above
> > > > > > for DOIs you could have IANA allocate a range of DOIs for SELinux
> > > > > > partitioning it off into a range for publicly assigned DOIs and
> > > > > > privately managed DOIs. It is acceptable to have IANA create and
> > > > > > populate a registry with values in the document.
> > > > > >
> > > > >
> > > > > Ok, I understand now. Yes, that seems reasonable, fair, and flexible.
> > > > > I can still keep semantics (a mechanism and ability to group or
> > > > > differentiate).
> > > > >
> > > > > So, a doi field that is 32 bits, with perhaps so much for SELinux,
> > > > > further partitioned for public and private use. The same for Smack.
> > > > > Right? And remaining for future use.
> > > >
> > > > The standards people don't particularly care about specific security
> > > > models in this case. I initially mentioned implementation specific
> > > > details in my early labeled NFS drafts and was told that those aren't
> > > > really a concern of the protocol. Since the label is a (DOI,<OPAQUE>)
> > > > tuple it is up to whomever obtains a number from IANA to define the
> > > > meaning of that DOI. However it should be written into the standard what
> > > > information is recorded by IANA to bind to these numbers. Also do we see
> > > > several registries? I really only see one registry that can be shared by
> > > > all three of these drafts. I just hope they don't want us to write up an
> > > > RFC for the definition and management of DOIs (it might happen that way
> > > > though).
> > > >
> > >
> > > Ok, gotta admit, I am a little confused as to how we could share the
> > > same DOI registry with CALIPSO since they are using a dotted-quad format
> > > right now? And it doesn't seem to accomodate but one DOI from IANA which
> > > leaves me confused as to how I would get one and then partition it for
> > > private and non-private uses.
> >
> > Well we might need to talk with the CALIPSO people to figure out a way
> > that we can all use their DOI scheme. At its core their method just
> > seems to be a dotted-quad format as you have said. IANA's job is to keep
> > track of these dotted-quads.
> >
> > Excerpt from CALIPSO Draft
> >
> > DOI Value Organisation or Use
> > ======================= ============================
> > 0:0:0:0 Null DOI; MUST NOT be used
> > on any network at any time.
> > 0:0:0:1 to 0:255:255:255 For private use among
> > consenting parties within
> > private networks; for reasons
> > of interoperability, these
> > DOI values MUST NOT ever
> > appear on the global public
> > Internet.
> > 1:0:0:0 to 254:255:255:255 For assignment by IANA to
> > organisations following the
> > guidelines in the paragraph
> > below.
> > 255:0:0:0 to 255:0:0:0 Reserved to the IETF for
> > future use by possible
> > revisions of this specification.
> >
> >
> > So according to this table IANA can assign anything in the range in section 3.
> >
> > This means if you wanted to you could ask IANA to reserve
> > 1:0:1:*-1:0:2:* for SELinux DOIs stating that anything in the class C
> > starting with 1 is public and starting with 2 is private.
> >
> > I am just taking the CALIPSO mechanism for DOIs here and not the
> > requirements of how many are issued to what organizations and whatnot.
> >
> > This would need to be something discussed at the BOF.
> >
>
> Ok, thanks for clearing that up. As you have stated is how I interpreted
> the draft. Because there were restrictions on how many DOIs could be
> issued to an organization, I became concerned and thought perhaps I had
> not interpreted correctly.
>
> > >
> > > Because there is already a working prototype of labeled ipsec in
> > > Linux, I would have very much like to get assignments from IANA
> > > now for SELinux. I would like to make necessary modifications to Linux
> > > kernel and userspace soon as possible because it would seem odd to me to
> > > have an internet draft and a prototype that does not comply to it. It
> > > would also help to set a precedent of what would be required when asking
> > > for DOI assignments ( I hope I said that correctly).
> > >
> > > > >
> > > > > Would this be a consensus in regards to DOI for labeled nfs, labeled
> > > > > ipsec, and CALIPSO drafts?
> > > > >
> > > >
> > > > I would like to think that we could establish one definition of a DOI
> > > > for IETF documents. I spoke with several people at the last IETF meeting
> > > > and they said that we need to stay consistent here. I will be trying to
> > > > organize a security label BOF at the next IETF meeting so we can sit
> > > > down and discuss the way things should work. I doubt this will spawn a
> > > > working group for security labels but we could come to a consensus on
> > > > certain things.
> > > >
> > >
> > > Ahh, ok. Please let me know if you schedule this BOF.
> > > I guess my concern is I want to get my drafts submitted now.
> > > Because there is a working prototype, I felt it best
> > > to go ahead and ask for the IANA assignments now.
> > > But I do agree with what you are saying... just need to figure
> > > out how I should proceed...
> >
> > Don't fall into the same trap that I did initially thinking that just
> > because you submitted a draft that it is set in stone. It is common for
> > a draft to change many times even before it hits the implementation
> > phase of the standards process. Then once you have multiple people
> > implementing the standard you will probably run into other problems that
> > you didn't think of initially. It is a good idea for you to submit the
> > draft with your concept of a DOI at this point since it gives us several
> > drafts to consider in the BOF.
> >
> Ok, thanks. I will take that advice to heart.
> When you recommend submitting my draft with my concept of DOI,
> do you mean as I originally had it with algorithm and doi field of one
> octet each, or in a more generic manner as the labeled NFS draft?
> I am open to what this community thinks is best way to do it at this
> point.
I would like Paul to give his opinion on this as well but I think the
best thing at the moment would be go submit your draft where the DOI is
a tuple of (mechanism,doi). I personally like the idea of representing
the 32 bit value as a series of four octets for human readable purposes
but your idea does have some merit with regards to what information
should be stored with these numbers by IANA. By having your draft out
there recommending your method of handling DOIs it gives people one more
thing to consider for discussion during the BOF.
>
> > Something else to remember is that the fast paced development model of
> > the Linux community doesn't mesh well with the IETF process. I was at
> > the NFSv4 WG meeting in Dublin and I had asked about getting my work
> > added to the charter. They said it could be done between meetings which
> > is a good thing. To this I responded that it was good that this could be
> > done quickly and that I didn't have to wait four months to get it done.
> > One of the directors replied well four months is quick. So patience is a
> > virtue in this venue.
> >
>
> Gotta remember that. :-)
> It has taken so long to get the drafts to this point that I guess I
> am somewhat anxious. :-)
When I first went to an IETF conference (8 months ago) I opened my
presentation with "Hello my name is Dave Quigley, I'm from the NSA and
I'm looking forward to working with you for the next decade." I said
this jokingly but looking at the process this might be more true than I
expected.
>
> >
> > About the BOF, I sent an email to the Security Area Director about
> > setting up a BOF and it was suggested that we start with a Bar BOF
> > first. This type of BOF isn't as formal as a normal one but regular BOFs
> > are usually formed for the purpose of trying to start a working group.
> > Even though it is an informal BOF it still needs to have a clear purpose
> > and a set of goals to accomplish. The main issue I see at the moment is
> > going to be DOIs. Like we've seen we have three competing definitions of
> > them and it would be nice to nail it down to one that we can all agree
> > on.
> >
> > However this doesn't necessarily have to be the only thing we discuss.
> > When I post the information about the Bar BOF I am going to do a call
> > for participation for other topics as well. For all we know there might
> > be other security label people lurking in other working groups that
> > might have topics they want to discuss.
> >
> Ok. I am definitely interested.
>
> Thanks!!
>
> regards,
> Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 20:50 ` Paul Moore
@ 2008-08-27 21:33 ` David P. Quigley
2008-08-27 22:56 ` Joy Latten
2008-08-28 16:08 ` Paul Moore
2008-08-27 23:27 ` Joy Latten
1 sibling, 2 replies; 23+ messages in thread
From: David P. Quigley @ 2008-08-27 21:33 UTC (permalink / raw)
To: Paul Moore; +Cc: Joy Latten, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 16:50 -0400, Paul Moore wrote:
> Hi Joy, et al.
>
> I'll respond to the rest of you email a little bit later when I have
> some time but since you and David have been having a good discussion
> around DOI issues I wanted to add some quick comments ... (see below)
>
> On Wednesday 27 August 2008 2:41:48 pm Joy Latten wrote:
> > On Wed, 2008-08-27 at 12:49 -0400, David P. Quigley wrote:
> > > On Wed, 2008-08-27 at 11:17 -0500, Joy Latten wrote:
> > > > On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> > > > > On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > > > > > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > > > > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
>
> ...
>
> > > > > Yea, it is unfortunate that CALIPSO is only for MLS labels.
> > > > > IPv6 is still growing in its deployment so it would be nice to
> > > > > have a robust and flexible method for conveying security labels
> > > > > from the start. For now it seems as if CALIPSO will try to go
> > > > > through just as MLS labels and then DTE or other security
> > > > > labels will have to create their own IP security option.
>
> I've had many discussions with Randall regarding this topic, I even
> offered a series of edits to earlier CALIPSO (back when it was still
> SIPSO, yipee for the name change!) drafts which introduced a more
> generic DTE labeling mechanism. After much discussion Randall agreed
> that having a more generic, DTE-friendly labeling mechanism would be
> nice but he wanted to keep CALIPSO focused on MLS labeling since that
> was the feedback he had been receiving. He was very helpful and the
> discussion unveiled many potential issues with a DTE labeling protocol,
> primarily around the need to make the protocol more intermediate hop
> friendly.
>
> I am currently waiting to see how the CALIPSO specification is received
> by the general IETF SAAG community, especially the assertion that
> explicit packet labeling is an important user requirement. If the
> CALIPSO specification is well received I plan on submitting a draft
> specification which will provide a more general packet labeling
> mechanism for IPv6 and possibly IPv4.
When I was in Dublin it was suggested that I look at the CALIPSO draft
for DOI related information so they are well aware of it and it doesn't
seem to have hit much resistance yet.
>
> > > > > > > > >I'm also concerned with the implied convention of
> > > > > > > > > assigning one value to a particular implementation. In
> > > > > > > > > the SELinux case, how do you deal with a non-MLS/MCS
> > > > > > > > > policy such as Gentoo/Ubuntu talking to a MLS/MCS
> > > > > > > > > policy such as Fedora/RHEL? What about policies with
> > > > > > > > > different types? Differing numbers of MLS sensitivity
> > > > > > > > > levels or categories?
> > > > > > > >
> > > > > > > > Hmm... not sure I understand so I may not answer this
> > > > > > > > correctly...
> > > > > > > >
> > > > > > > > The algorithm indicates the security mechanism.
> > > > > > > > In a way, it identifies the syntax/semantics of the
> > > > > > > > security context to security mechanism, since security
> > > > > > > > mechanisms may use different syntax/semantics for the
> > > > > > > > security contexts. i.e. SELinux and SMACK.
> > > > > > > > The algorithm field in SELinux is used to "authorize" the
> > > > > > > > security context. In other words, SELinux only wants and
> > > > > > > > understands SELinux's security context syntax/semantics.
> > > > > > > > The "doi" would be used for further differentiation
> > > > > > > > within SELinux domain. Far example, a sysadm wants to
> > > > > > > > differentiate between SELinux policy versions in his
> > > > > > > > domain. He could used "doi" field to do this.
> > > > > > > >
> > > > > > > > I suppose if you wanted two different security mechanisms
> > > > > > > > to interoperate, a mapping of some sort would have to be
> > > > > > > > created between them. The security mechanisms would need
> > > > > > > > to indicate they accept (via the mapping) the other's
> > > > > > > > security context syntax/semantics. In other words, they
> > > > > > > > would "authorize" the two different security contexts. It
> > > > > > > > would do this via the "algorithm" and/or "doi" fields. I
> > > > > > > > am thinking in this case, "doi" could even indicate the
> > > > > > > > mapping such as CIPSO's DOI does.
> > > > > > > >
> > > > > > > > I considered the information contained in the "algorithm"
> > > > > > > > and "doi" fields required for interoperability, and the
> > > > > > > > use implementation specific.
> > > > > > > >
> > > > > > > > If this doesn't answer your question, let me know.
> > > > > > >
> > > > > > > I think what Paul might be asking is why is it better to
> > > > > > > have two fields, one for Security Mechanism and one for the
> > > > > > > DOI when that can be one field. If we go with a method
> > > > > > > similar to the second described above for DOIs you could
> > > > > > > have IANA allocate a range of DOIs for SELinux partitioning
> > > > > > > it off into a range for publicly assigned DOIs and
> > > > > > > privately managed DOIs. It is acceptable to have IANA
> > > > > > > create and populate a registry with values in the document.
> > > > > >
> > > > > > Ok, I understand now. Yes, that seems reasonable, fair, and
> > > > > > flexible. I can still keep semantics (a mechanism and ability
> > > > > > to group or differentiate).
> > > > > >
> > > > > > So, a doi field that is 32 bits, with perhaps so much for
> > > > > > SELinux, further partitioned for public and private use. The
> > > > > > same for Smack. Right? And remaining for future use.
> > > > >
> > > > > The standards people don't particularly care about specific
> > > > > security models in this case. I initially mentioned
> > > > > implementation specific details in my early labeled NFS drafts
> > > > > and was told that those aren't really a concern of the
> > > > > protocol. Since the label is a (DOI,<OPAQUE>) tuple it is up to
> > > > > whomever obtains a number from IANA to define the meaning of
> > > > > that DOI. However it should be written into the standard what
> > > > > information is recorded by IANA to bind to these numbers. Also
> > > > > do we see several registries? I really only see one registry
> > > > > that can be shared by all three of these drafts. I just hope
> > > > > they don't want us to write up an RFC for the definition and
> > > > > management of DOIs (it might happen that way though).
> > > >
> > > > Ok, gotta admit, I am a little confused as to how we could share
> > > > the same DOI registry with CALIPSO since they are using a
> > > > dotted-quad format right now? And it doesn't seem to accomodate
> > > > but one DOI from IANA which leaves me confused as to how I would
> > > > get one and then partition it for private and non-private uses.
> > >
> > > Well we might need to talk with the CALIPSO people to figure out a
> > > way that we can all use their DOI scheme. At its core their method
> > > just seems to be a dotted-quad format as you have said. IANA's job
> > > is to keep track of these dotted-quads.
>
> The CALIPSO DOI is defined as a opaque 32 bit unsigned integer, similar
> to CIPSO and your description of labeled NFS's DOI. The dotted
> notation used in part of the CALIPSO draft is just a convenient way of
> representing the value in the same way we represent IPv4 addresses.
>
> The CALIPSO specification does set aside DOI ranges for specific uses
> (is this the source of confusion?) which I think is a good idea and I
> would encourage other protocols to follow suit.
What do they mean by opaque 32 bit integer here? If they are defining
ranges and assignments to the integer it can't truly be opaque. I don't
recommend we transport the DOI as the colon separated octet group but
for the purpose of assigning DOIs and ranges and even specifying them in
programs I think the syntax is useful.
I hesitate to say this but I think it might be a good idea to draw up a
draft explaining what a DOI is and what is expected from IANA for them.
I've received emails from people working on security labels in
application layer protocols so they might be interested in a standard
method for specifying and interpreting DOIs as well.
>
> > > > Because there is already a working prototype of labeled ipsec in
> > > > Linux, I would have very much like to get assignments from IANA
> > > > now for SELinux. I would like to make necessary modifications to
> > > > Linux kernel and userspace soon as possible because it would seem
> > > > odd to me to have an internet draft and a prototype that does not
> > > > comply to it. It would also help to set a precedent of what would
> > > > be required when asking for DOI assignments ( I hope I said that
> > > > correctly).
>
> I'm sure you've gotten feedback from others on this but nothing
> involving the IETF is "quick". Be prepared for a potentially lengthy
> discussion and understand that just because the Linux Kernel already
> has a labeled IPsec implementation does not mean it will be accepted
> as-is by the IETF community.
I second Paul on this. We had an implementation of Labeled NFS at IETF
71 and I had some elements of the design in the presentation slides. One
of the members from Sun stood up and basically said that the way we were
doing certain things was completely wrong. He then suggested better ways
of handling what we wanted to do and after we went back and looked at it
all again we realized he was right. In the time between IETF 71 and 72
we actually dropped several things that we were doing since we came to
the conclusion that they weren't correct. This feedback from the Working
Groups really does help to make a better product in the end.
BTW, which working group is this a part of? It seems like it belongs to
several ADships since it could sit in security and in internet.
>
> > > About the BOF, I sent an email to the Security Area Director about
> > > setting up a BOF and it was suggested that we start with a Bar BOF
> > > first. This type of BOF isn't as formal as a normal one but regular
> > > BOFs are usually formed for the purpose of trying to start a
> > > working group. Even though it is an informal BOF it still needs to
> > > have a clear purpose and a set of goals to accomplish. The main
> > > issue I see at the moment is going to be DOIs. Like we've seen we
> > > have three competing definitions of them and it would be nice to
> > > nail it down to one that we can all agree on.
> > >
> > > However this doesn't necessarily have to be the only thing we
> > > discuss. When I post the information about the Bar BOF I am going
> > > to do a call for participation for other topics as well. For all we
> > > know there might be other security label people lurking in other
> > > working groups that might have topics they want to discuss.
>
> Please include me in the BOF notice/invite.
Will do. I hope to draw something up about this by Friday.
Dave
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 21:21 ` David P. Quigley
@ 2008-08-27 21:56 ` Paul Moore
2008-08-27 22:00 ` David P. Quigley
2008-08-28 0:22 ` Joy Latten
0 siblings, 2 replies; 23+ messages in thread
From: Paul Moore @ 2008-08-27 21:56 UTC (permalink / raw)
To: David P. Quigley; +Cc: Joy Latten, gcwilson, selinux, serue, tjaeger
On Wednesday 27 August 2008 5:21:17 pm David P. Quigley wrote:
> I would like Paul to give his opinion on this as well but I think the
> best thing at the moment would be go submit your draft where the DOI
> is a tuple of (mechanism,doi). I personally like the idea of
> representing the 32 bit value as a series of four octets for human
> readable purposes but your idea does have some merit with regards to
> what information should be stored with these numbers by IANA. By
> having your draft out there recommending your method of handling DOIs
> it gives people one more thing to consider for discussion during the
> BOF.
Our emails may have crossed in flight, but just in case it isn't clear
from the response I sent earlier this afternoon I think we are best
served with the DOI as a unified 32 bit value (the dotted notation is
just for display/readability purposes).
I would encourage us to stop thinking about specific DOI values
as "SELinux", "Smack", or whatever. There is no reason we can't get
the different labeled security implementation to work together but if
we continue to propagate the notion of implementation specific DOIs
then it becomes that much harder. I think we need to think of DOIs as
defining a mapping between an on-the-wire label format to a semantic
meaning; the actual format of the wire label isn't important, the
meaning of the label is what really counts. Once we understand what a
wire formatted label means we can internalize it however we need to so
that the implementation can do the necessary access control.
Once again, think of how we handle the MLS-only CIPSO labels today; it
is a simplified example but it demonstrates the basic concept of
internalizing implementation agnostic security labels and the
interoperability benefits that result.
--
paul moore
linux @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 21:56 ` Paul Moore
@ 2008-08-27 22:00 ` David P. Quigley
2008-08-28 15:49 ` Paul Moore
2008-08-28 0:22 ` Joy Latten
1 sibling, 1 reply; 23+ messages in thread
From: David P. Quigley @ 2008-08-27 22:00 UTC (permalink / raw)
To: Paul Moore; +Cc: Joy Latten, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 17:56 -0400, Paul Moore wrote:
> On Wednesday 27 August 2008 5:21:17 pm David P. Quigley wrote:
> > I would like Paul to give his opinion on this as well but I think the
> > best thing at the moment would be go submit your draft where the DOI
> > is a tuple of (mechanism,doi). I personally like the idea of
> > representing the 32 bit value as a series of four octets for human
> > readable purposes but your idea does have some merit with regards to
> > what information should be stored with these numbers by IANA. By
> > having your draft out there recommending your method of handling DOIs
> > it gives people one more thing to consider for discussion during the
> > BOF.
>
> Our emails may have crossed in flight, but just in case it isn't clear
> from the response I sent earlier this afternoon I think we are best
> served with the DOI as a unified 32 bit value (the dotted notation is
> just for display/readability purposes).
I completely agree.
>
> I would encourage us to stop thinking about specific DOI values
> as "SELinux", "Smack", or whatever. There is no reason we can't get
> the different labeled security implementation to work together but if
> we continue to propagate the notion of implementation specific DOIs
> then it becomes that much harder. I think we need to think of DOIs as
> defining a mapping between an on-the-wire label format to a semantic
> meaning; the actual format of the wire label isn't important, the
> meaning of the label is what really counts. Once we understand what a
> wire formatted label means we can internalize it however we need to so
> that the implementation can do the necessary access control.
Once again agreed. The issue with this though is that this generalized
on the wire label is a very difficult thing to come up with. Especially
since you really want to express concepts such as this webserver can
only serve public data. That is the kind of high level semantic you
would want to specify and then have the endpoints decide what that
means. For MLS this might translate into a category for SELinux this
might translate into a specific type. This is by no means an easy
problem.
>
> Once again, think of how we handle the MLS-only CIPSO labels today; it
> is a simplified example but it demonstrates the basic concept of
> internalizing implementation agnostic security labels and the
> interoperability benefits that result.
>
You might have to explain this to me. The issue you raise in the
paragraph above deals with talking in terms of mechanisms not
necessarily implementations. The issue with CIPSO is that it is only one
mechanism which allows them to define their labels in an implementation
agnostic manner since everyone has agreed on the mechanism. This is a
little harder when you're spanning mechanisms unless we use something
similar to what I describe above.
Dave
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 21:33 ` David P. Quigley
@ 2008-08-27 22:56 ` Joy Latten
2008-08-28 16:08 ` Paul Moore
1 sibling, 0 replies; 23+ messages in thread
From: Joy Latten @ 2008-08-27 22:56 UTC (permalink / raw)
To: David P. Quigley; +Cc: Paul Moore, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 17:33 -0400, David P. Quigley wrote:
> On Wed, 2008-08-27 at 16:50 -0400, Paul Moore wrote:
> > Hi Joy, et al.
> >
> > I'll respond to the rest of you email a little bit later when I have
> > some time but since you and David have been having a good discussion
> > around DOI issues I wanted to add some quick comments ... (see below)
> >
> > On Wednesday 27 August 2008 2:41:48 pm Joy Latten wrote:
> > > On Wed, 2008-08-27 at 12:49 -0400, David P. Quigley wrote:
> > > > On Wed, 2008-08-27 at 11:17 -0500, Joy Latten wrote:
> > > > > On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> > > > > > On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > > > > > > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > > > > > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
> >
> > ...
> >
> > > > > > Yea, it is unfortunate that CALIPSO is only for MLS labels.
> > > > > > IPv6 is still growing in its deployment so it would be nice to
> > > > > > have a robust and flexible method for conveying security labels
> > > > > > from the start. For now it seems as if CALIPSO will try to go
> > > > > > through just as MLS labels and then DTE or other security
> > > > > > labels will have to create their own IP security option.
> >
> > I've had many discussions with Randall regarding this topic, I even
> > offered a series of edits to earlier CALIPSO (back when it was still
> > SIPSO, yipee for the name change!) drafts which introduced a more
> > generic DTE labeling mechanism. After much discussion Randall agreed
> > that having a more generic, DTE-friendly labeling mechanism would be
> > nice but he wanted to keep CALIPSO focused on MLS labeling since that
> > was the feedback he had been receiving. He was very helpful and the
> > discussion unveiled many potential issues with a DTE labeling protocol,
> > primarily around the need to make the protocol more intermediate hop
> > friendly.
> >
> > I am currently waiting to see how the CALIPSO specification is received
> > by the general IETF SAAG community, especially the assertion that
> > explicit packet labeling is an important user requirement. If the
> > CALIPSO specification is well received I plan on submitting a draft
> > specification which will provide a more general packet labeling
> > mechanism for IPv6 and possibly IPv4.
>
> When I was in Dublin it was suggested that I look at the CALIPSO draft
> for DOI related information so they are well aware of it and it doesn't
> seem to have hit much resistance yet.
>
> >
> > > > > > > > > >I'm also concerned with the implied convention of
> > > > > > > > > > assigning one value to a particular implementation. In
> > > > > > > > > > the SELinux case, how do you deal with a non-MLS/MCS
> > > > > > > > > > policy such as Gentoo/Ubuntu talking to a MLS/MCS
> > > > > > > > > > policy such as Fedora/RHEL? What about policies with
> > > > > > > > > > different types? Differing numbers of MLS sensitivity
> > > > > > > > > > levels or categories?
> > > > > > > > >
> > > > > > > > > Hmm... not sure I understand so I may not answer this
> > > > > > > > > correctly...
> > > > > > > > >
> > > > > > > > > The algorithm indicates the security mechanism.
> > > > > > > > > In a way, it identifies the syntax/semantics of the
> > > > > > > > > security context to security mechanism, since security
> > > > > > > > > mechanisms may use different syntax/semantics for the
> > > > > > > > > security contexts. i.e. SELinux and SMACK.
> > > > > > > > > The algorithm field in SELinux is used to "authorize" the
> > > > > > > > > security context. In other words, SELinux only wants and
> > > > > > > > > understands SELinux's security context syntax/semantics.
> > > > > > > > > The "doi" would be used for further differentiation
> > > > > > > > > within SELinux domain. Far example, a sysadm wants to
> > > > > > > > > differentiate between SELinux policy versions in his
> > > > > > > > > domain. He could used "doi" field to do this.
> > > > > > > > >
> > > > > > > > > I suppose if you wanted two different security mechanisms
> > > > > > > > > to interoperate, a mapping of some sort would have to be
> > > > > > > > > created between them. The security mechanisms would need
> > > > > > > > > to indicate they accept (via the mapping) the other's
> > > > > > > > > security context syntax/semantics. In other words, they
> > > > > > > > > would "authorize" the two different security contexts. It
> > > > > > > > > would do this via the "algorithm" and/or "doi" fields. I
> > > > > > > > > am thinking in this case, "doi" could even indicate the
> > > > > > > > > mapping such as CIPSO's DOI does.
> > > > > > > > >
> > > > > > > > > I considered the information contained in the "algorithm"
> > > > > > > > > and "doi" fields required for interoperability, and the
> > > > > > > > > use implementation specific.
> > > > > > > > >
> > > > > > > > > If this doesn't answer your question, let me know.
> > > > > > > >
> > > > > > > > I think what Paul might be asking is why is it better to
> > > > > > > > have two fields, one for Security Mechanism and one for the
> > > > > > > > DOI when that can be one field. If we go with a method
> > > > > > > > similar to the second described above for DOIs you could
> > > > > > > > have IANA allocate a range of DOIs for SELinux partitioning
> > > > > > > > it off into a range for publicly assigned DOIs and
> > > > > > > > privately managed DOIs. It is acceptable to have IANA
> > > > > > > > create and populate a registry with values in the document.
> > > > > > >
> > > > > > > Ok, I understand now. Yes, that seems reasonable, fair, and
> > > > > > > flexible. I can still keep semantics (a mechanism and ability
> > > > > > > to group or differentiate).
> > > > > > >
> > > > > > > So, a doi field that is 32 bits, with perhaps so much for
> > > > > > > SELinux, further partitioned for public and private use. The
> > > > > > > same for Smack. Right? And remaining for future use.
> > > > > >
> > > > > > The standards people don't particularly care about specific
> > > > > > security models in this case. I initially mentioned
> > > > > > implementation specific details in my early labeled NFS drafts
> > > > > > and was told that those aren't really a concern of the
> > > > > > protocol. Since the label is a (DOI,<OPAQUE>) tuple it is up to
> > > > > > whomever obtains a number from IANA to define the meaning of
> > > > > > that DOI. However it should be written into the standard what
> > > > > > information is recorded by IANA to bind to these numbers. Also
> > > > > > do we see several registries? I really only see one registry
> > > > > > that can be shared by all three of these drafts. I just hope
> > > > > > they don't want us to write up an RFC for the definition and
> > > > > > management of DOIs (it might happen that way though).
> > > > >
> > > > > Ok, gotta admit, I am a little confused as to how we could share
> > > > > the same DOI registry with CALIPSO since they are using a
> > > > > dotted-quad format right now? And it doesn't seem to accomodate
> > > > > but one DOI from IANA which leaves me confused as to how I would
> > > > > get one and then partition it for private and non-private uses.
> > > >
> > > > Well we might need to talk with the CALIPSO people to figure out a
> > > > way that we can all use their DOI scheme. At its core their method
> > > > just seems to be a dotted-quad format as you have said. IANA's job
> > > > is to keep track of these dotted-quads.
> >
> > The CALIPSO DOI is defined as a opaque 32 bit unsigned integer, similar
> > to CIPSO and your description of labeled NFS's DOI. The dotted
> > notation used in part of the CALIPSO draft is just a convenient way of
> > representing the value in the same way we represent IPv4 addresses.
> >
> > The CALIPSO specification does set aside DOI ranges for specific uses
> > (is this the source of confusion?) which I think is a good idea and I
> > would encourage other protocols to follow suit.
>
> What do they mean by opaque 32 bit integer here? If they are defining
> ranges and assignments to the integer it can't truly be opaque. I don't
> recommend we transport the DOI as the colon separated octet group but
> for the purpose of assigning DOIs and ranges and even specifying them in
> programs I think the syntax is useful.
>
> I hesitate to say this but I think it might be a good idea to draw up a
> draft explaining what a DOI is and what is expected from IANA for them.
> I've received emails from people working on security labels in
> application layer protocols so they might be interested in a standard
> method for specifying and interpreting DOIs as well.
>
> >
> > > > > Because there is already a working prototype of labeled ipsec in
> > > > > Linux, I would have very much like to get assignments from IANA
> > > > > now for SELinux. I would like to make necessary modifications to
> > > > > Linux kernel and userspace soon as possible because it would seem
> > > > > odd to me to have an internet draft and a prototype that does not
> > > > > comply to it. It would also help to set a precedent of what would
> > > > > be required when asking for DOI assignments ( I hope I said that
> > > > > correctly).
> >
> > I'm sure you've gotten feedback from others on this but nothing
> > involving the IETF is "quick". Be prepared for a potentially lengthy
> > discussion and understand that just because the Linux Kernel already
> > has a labeled IPsec implementation does not mean it will be accepted
> > as-is by the IETF community.
>
> I second Paul on this. We had an implementation of Labeled NFS at IETF
> 71 and I had some elements of the design in the presentation slides. One
> of the members from Sun stood up and basically said that the way we were
> doing certain things was completely wrong. He then suggested better ways
> of handling what we wanted to do and after we went back and looked at it
> all again we realized he was right. In the time between IETF 71 and 72
> we actually dropped several things that we were doing since we came to
> the conclusion that they weren't correct. This feedback from the Working
> Groups really does help to make a better product in the end.
>
Ok, that is good to know.
> BTW, which working group is this a part of? It seems like it belongs to
> several ADships since it could sit in security and in internet.
>
If you are talking about labeled ipsec, I have mentioned this several
times on the IETF's IPsec WG mailing list. Just recently the IPsec WG
recently re-formed. Dublin was their first official meeting. I did
submit labeled ipsec as a possible work item, but only 3 or 4 were
selected and in all honesty they were very important. But individual
submissions are reviewed and discussed too by WG. While forming, one
of the primary focuses discussed was to filter out unnecessary IPsec
extensions. When I asked how come obsoleted IPsec Architecture RFC had
MLS networking and the updated one left it out, the response was we did
not think anyone was using it and it would be non-trivial to add it
back. Gotta admit, I have no idea what to expect. :-) Although I have
read the IPsec rfcs 3000 times (ok I am exaggerating, it just feels like
it), the feeling that I have forgotten something or misunderstood
something never leaves me. :-) So thanks for all reviews, help and
advice.
regards,
Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 20:50 ` Paul Moore
2008-08-27 21:33 ` David P. Quigley
@ 2008-08-27 23:27 ` Joy Latten
2008-08-28 15:44 ` Paul Moore
1 sibling, 1 reply; 23+ messages in thread
From: Joy Latten @ 2008-08-27 23:27 UTC (permalink / raw)
To: Paul Moore; +Cc: David P. Quigley, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 16:50 -0400, Paul Moore wrote:
> Hi Joy, et al.
>
> I'll respond to the rest of you email a little bit later when I have
> some time but since you and David have been having a good discussion
> around DOI issues I wanted to add some quick comments ... (see below)
>
> On Wednesday 27 August 2008 2:41:48 pm Joy Latten wrote:
> > On Wed, 2008-08-27 at 12:49 -0400, David P. Quigley wrote:
> > > On Wed, 2008-08-27 at 11:17 -0500, Joy Latten wrote:
> > > > On Tue, 2008-08-26 at 16:24 -0400, David P. Quigley wrote:
> > > > > On Tue, 2008-08-26 at 12:17 -0500, Joy Latten wrote:
> > > > > > On Mon, 2008-08-25 at 17:42 -0400, David P. Quigley wrote:
> > > > > > > On Mon, 2008-08-25 at 15:46 -0500, Joy Latten wrote:
>
> ...
>
> > > > > Yea, it is unfortunate that CALIPSO is only for MLS labels.
> > > > > IPv6 is still growing in its deployment so it would be nice to
> > > > > have a robust and flexible method for conveying security labels
> > > > > from the start. For now it seems as if CALIPSO will try to go
> > > > > through just as MLS labels and then DTE or other security
> > > > > labels will have to create their own IP security option.
>
> I've had many discussions with Randall regarding this topic, I even
> offered a series of edits to earlier CALIPSO (back when it was still
> SIPSO, yipee for the name change!) drafts which introduced a more
> generic DTE labeling mechanism. After much discussion Randall agreed
> that having a more generic, DTE-friendly labeling mechanism would be
> nice but he wanted to keep CALIPSO focused on MLS labeling since that
> was the feedback he had been receiving. He was very helpful and the
> discussion unveiled many potential issues with a DTE labeling protocol,
> primarily around the need to make the protocol more intermediate hop
> friendly.
>
I very much liked your idea of generic. This is kinda where I want to
go, something that would be somewhat flexible enough to possibly allow
DTE and/or MLS labels, because the information is "opaque" to the
protocol, at least the ipsec protocol.
> I am currently waiting to see how the CALIPSO specification is received
> by the general IETF SAAG community, especially the assertion that
> explicit packet labeling is an important user requirement. If the
> CALIPSO specification is well received I plan on submitting a draft
> specification which will provide a more general packet labeling
> mechanism for IPv6 and possibly IPv4.
>
Do you mean one that would take a more generic label?
> > > > > > > > >I'm also concerned with the implied convention of
> > > > > > > > > assigning one value to a particular implementation. In
> > > > > > > > > the SELinux case, how do you deal with a non-MLS/MCS
> > > > > > > > > policy such as Gentoo/Ubuntu talking to a MLS/MCS
> > > > > > > > > policy such as Fedora/RHEL? What about policies with
> > > > > > > > > different types? Differing numbers of MLS sensitivity
> > > > > > > > > levels or categories?
> > > > > > > >
> > > > > > > > Hmm... not sure I understand so I may not answer this
> > > > > > > > correctly...
> > > > > > > >
> > > > > > > > The algorithm indicates the security mechanism.
> > > > > > > > In a way, it identifies the syntax/semantics of the
> > > > > > > > security context to security mechanism, since security
> > > > > > > > mechanisms may use different syntax/semantics for the
> > > > > > > > security contexts. i.e. SELinux and SMACK.
> > > > > > > > The algorithm field in SELinux is used to "authorize" the
> > > > > > > > security context. In other words, SELinux only wants and
> > > > > > > > understands SELinux's security context syntax/semantics.
> > > > > > > > The "doi" would be used for further differentiation
> > > > > > > > within SELinux domain. Far example, a sysadm wants to
> > > > > > > > differentiate between SELinux policy versions in his
> > > > > > > > domain. He could used "doi" field to do this.
> > > > > > > >
> > > > > > > > I suppose if you wanted two different security mechanisms
> > > > > > > > to interoperate, a mapping of some sort would have to be
> > > > > > > > created between them. The security mechanisms would need
> > > > > > > > to indicate they accept (via the mapping) the other's
> > > > > > > > security context syntax/semantics. In other words, they
> > > > > > > > would "authorize" the two different security contexts. It
> > > > > > > > would do this via the "algorithm" and/or "doi" fields. I
> > > > > > > > am thinking in this case, "doi" could even indicate the
> > > > > > > > mapping such as CIPSO's DOI does.
> > > > > > > >
> > > > > > > > I considered the information contained in the "algorithm"
> > > > > > > > and "doi" fields required for interoperability, and the
> > > > > > > > use implementation specific.
> > > > > > > >
> > > > > > > > If this doesn't answer your question, let me know.
> > > > > > >
> > > > > > > I think what Paul might be asking is why is it better to
> > > > > > > have two fields, one for Security Mechanism and one for the
> > > > > > > DOI when that can be one field. If we go with a method
> > > > > > > similar to the second described above for DOIs you could
> > > > > > > have IANA allocate a range of DOIs for SELinux partitioning
> > > > > > > it off into a range for publicly assigned DOIs and
> > > > > > > privately managed DOIs. It is acceptable to have IANA
> > > > > > > create and populate a registry with values in the document.
> > > > > >
> > > > > > Ok, I understand now. Yes, that seems reasonable, fair, and
> > > > > > flexible. I can still keep semantics (a mechanism and ability
> > > > > > to group or differentiate).
> > > > > >
> > > > > > So, a doi field that is 32 bits, with perhaps so much for
> > > > > > SELinux, further partitioned for public and private use. The
> > > > > > same for Smack. Right? And remaining for future use.
> > > > >
> > > > > The standards people don't particularly care about specific
> > > > > security models in this case. I initially mentioned
> > > > > implementation specific details in my early labeled NFS drafts
> > > > > and was told that those aren't really a concern of the
> > > > > protocol. Since the label is a (DOI,<OPAQUE>) tuple it is up to
> > > > > whomever obtains a number from IANA to define the meaning of
> > > > > that DOI. However it should be written into the standard what
> > > > > information is recorded by IANA to bind to these numbers. Also
> > > > > do we see several registries? I really only see one registry
> > > > > that can be shared by all three of these drafts. I just hope
> > > > > they don't want us to write up an RFC for the definition and
> > > > > management of DOIs (it might happen that way though).
> > > >
> > > > Ok, gotta admit, I am a little confused as to how we could share
> > > > the same DOI registry with CALIPSO since they are using a
> > > > dotted-quad format right now? And it doesn't seem to accomodate
> > > > but one DOI from IANA which leaves me confused as to how I would
> > > > get one and then partition it for private and non-private uses.
> > >
> > > Well we might need to talk with the CALIPSO people to figure out a
> > > way that we can all use their DOI scheme. At its core their method
> > > just seems to be a dotted-quad format as you have said. IANA's job
> > > is to keep track of these dotted-quads.
>
> The CALIPSO DOI is defined as a opaque 32 bit unsigned integer, similar
> to CIPSO and your description of labeled NFS's DOI. The dotted
> notation used in part of the CALIPSO draft is just a convenient way of
> representing the value in the same way we represent IPv4 addresses.
>
> The CALIPSO specification does set aside DOI ranges for specific uses
> (is this the source of confusion?) which I think is a good idea and I
> would encourage other protocols to follow suit.
The CALIPSO draft restricted the amount of DOIs given to an
organization. And I am thinking that if we share a DOI registry, I will
need more than one if I want any security mechanism that uses labeled
ipsec to also have a range for private use. I wasn't sure how this would
fit into what the draft stated. Thus my confusion. But I do think it
would be really great if we could share a registry and use DOIs in such
a similar manner that we could even share the values. Am I making sense?
What I mean is labeled ipsec could use the same DOIs as labeled nfs and
CALIPSO. It would not have to allocate a separate range of them.
regards,
Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 21:56 ` Paul Moore
2008-08-27 22:00 ` David P. Quigley
@ 2008-08-28 0:22 ` Joy Latten
2008-08-28 1:30 ` Casey Schaufler
1 sibling, 1 reply; 23+ messages in thread
From: Joy Latten @ 2008-08-28 0:22 UTC (permalink / raw)
To: Paul Moore; +Cc: David P. Quigley, gcwilson, selinux, serue, tjaeger
On Wed, 2008-08-27 at 17:56 -0400, Paul Moore wrote:
> On Wednesday 27 August 2008 5:21:17 pm David P. Quigley wrote:
> > I would like Paul to give his opinion on this as well but I think the
> > best thing at the moment would be go submit your draft where the DOI
> > is a tuple of (mechanism,doi). I personally like the idea of
> > representing the 32 bit value as a series of four octets for human
> > readable purposes but your idea does have some merit with regards to
> > what information should be stored with these numbers by IANA. By
> > having your draft out there recommending your method of handling DOIs
> > it gives people one more thing to consider for discussion during the
> > BOF.
>
> Our emails may have crossed in flight, but just in case it isn't clear
> from the response I sent earlier this afternoon I think we are best
> served with the DOI as a unified 32 bit value (the dotted notation is
> just for display/readability purposes).
Ok, just for my clarification, the consensus is that I change this to a
32 bit value field and keep it generic for now as in labeled nfs doc?
>
> I would encourage us to stop thinking about specific DOI values
> as "SELinux", "Smack", or whatever. There is no reason we can't get
> the different labeled security implementation to work together but if
> we continue to propagate the notion of implementation specific DOIs
> then it becomes that much harder. I think we need to think of DOIs as
> defining a mapping between an on-the-wire label format to a semantic
> meaning; the actual format of the wire label isn't important, the
> meaning of the label is what really counts. Once we understand what a
> wire formatted label means we can internalize it however we need to so
> that the implementation can do the necessary access control.
>
Ok, yep. The label should be an "opaque" (I might be over-using that
word by now) blob to the IPsec protocol. I guess in my thinking, it just
acts as label storage for the packet and the security mechanism.
I guess my concern is this, and it may be because I am not understanding
something. My concern is defining DOI as a mapping between an
on-the-wire label format to a semantic meaning. Could the mapping be
NULL or bypassed sometimes? What I mean is that IPsec could sometimes
store things just as they are represented by the security mechanism
since it doesn't put anything on the wire. So if both endpoints are
using SELinux, it would not need a mapping. It would need a mapping when
the endpoints' security mechanisms are different. Thus why labeled ipsec
was bent on a (securitymechanism,doi) tuple. Would it be possible for
the new DOI scheme to also take this into consideration?
regards,
Joy
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-28 0:22 ` Joy Latten
@ 2008-08-28 1:30 ` Casey Schaufler
2008-08-28 15:58 ` Paul Moore
0 siblings, 1 reply; 23+ messages in thread
From: Casey Schaufler @ 2008-08-28 1:30 UTC (permalink / raw)
To: Joy Latten
Cc: Paul Moore, David P. Quigley, gcwilson, selinux, serue, tjaeger
Joy Latten wrote:
> On Wed, 2008-08-27 at 17:56 -0400, Paul Moore wrote:
>
>> On Wednesday 27 August 2008 5:21:17 pm David P. Quigley wrote:
>>
>>> I would like Paul to give his opinion on this as well but I think the
>>> best thing at the moment would be go submit your draft where the DOI
>>> is a tuple of (mechanism,doi). I personally like the idea of
>>> representing the 32 bit value as a series of four octets for human
>>> readable purposes but your idea does have some merit with regards to
>>> what information should be stored with these numbers by IANA. By
>>> having your draft out there recommending your method of handling DOIs
>>> it gives people one more thing to consider for discussion during the
>>> BOF.
>>>
>> Our emails may have crossed in flight, but just in case it isn't clear
>> from the response I sent earlier this afternoon I think we are best
>> served with the DOI as a unified 32 bit value (the dotted notation is
>> just for display/readability purposes).
>>
>
> Ok, just for my clarification, the consensus is that I change this to a
> 32 bit value field and keep it generic for now as in labeled nfs doc?
>
>
>> I would encourage us to stop thinking about specific DOI values
>> as "SELinux", "Smack", or whatever. There is no reason we can't get
>> the different labeled security implementation to work together but if
>> we continue to propagate the notion of implementation specific DOIs
>> then it becomes that much harder. I think we need to think of DOIs as
>> defining a mapping between an on-the-wire label format to a semantic
>> meaning; the actual format of the wire label isn't important, the
>> meaning of the label is what really counts. Once we understand what a
>> wire formatted label means we can internalize it however we need to so
>> that the implementation can do the necessary access control.
>>
>>
> Ok, yep. The label should be an "opaque" (I might be over-using that
> word by now) blob to the IPsec protocol. I guess in my thinking, it just
> acts as label storage for the packet and the security mechanism.
>
> I guess my concern is this, and it may be because I am not understanding
> something. My concern is defining DOI as a mapping between an
> on-the-wire label format to a semantic meaning. Could the mapping be
> NULL or bypassed sometimes? What I mean is that IPsec could sometimes
> store things just as they are represented by the security mechanism
> since it doesn't put anything on the wire. So if both endpoints are
> using SELinux, it would not need a mapping.
Well ...
> It would need a mapping when
> the endpoints' security mechanisms are different.
Which it may be if the policies on the two systems don't mesh.
For example, if one system has no apache it needs no apache_t,
hence a mapping is required to deal with that. In fact, two
SELinux systems will obviously require mapping if you're sending
sids in your opaque label and most likely require mapping even
if the label is the context unless the machines have identical
installations and policies.
> Thus why labeled ipsec
> was bent on a (securitymechanism,doi) tuple. Would it be possible for
> the new DOI scheme to also take this into consideration?
>
For the cases where securitymechanism is sufficient to describe
the structure to which a DOI is applied its specification is
useful. A securitymechanism of SELinux would need to discriminate
between MLS, MCS, and none of the above. This is a problem with
any flexible scheme, Smack has it worse than SELinux because there
is no way to even hint at a structure to the label.
Does even a DOI make sense in a case where the two ends have
irreconcilable policies? Can you get away with anything less
than label mappings maintained on each host?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 23:27 ` Joy Latten
@ 2008-08-28 15:44 ` Paul Moore
0 siblings, 0 replies; 23+ messages in thread
From: Paul Moore @ 2008-08-28 15:44 UTC (permalink / raw)
To: Joy Latten; +Cc: David P. Quigley, gcwilson, selinux, serue, tjaeger
On Wednesday 27 August 2008 7:27:38 pm Joy Latten wrote:
> On Wed, 2008-08-27 at 16:50 -0400, Paul Moore wrote:
...
> > I am currently waiting to see how the CALIPSO specification is
> > received by the general IETF SAAG community, especially the
> > assertion that explicit packet labeling is an important user
> > requirement. If the CALIPSO specification is well received I plan
> > on submitting a draft specification which will provide a more
> > general packet labeling mechanism for IPv6 and possibly IPv4.
>
> Do you mean one that would take a more generic label?
Yes. In addition, I'm starting to wonder about making it sufficiently
generic that the specification could be used beyond just security
labels; there may be other potential uses cases such as DPI which could
be greatly simplified through the use of a labeling specification.
> > The CALIPSO DOI is defined as a opaque 32 bit unsigned integer,
> > similar to CIPSO and your description of labeled NFS's DOI. The
> > dotted notation used in part of the CALIPSO draft is just a
> > convenient way of representing the value in the same way we
> > represent IPv4 addresses.
> >
> > The CALIPSO specification does set aside DOI ranges for specific
> > uses (is this the source of confusion?) which I think is a good
> > idea and I would encourage other protocols to follow suit.
>
> The CALIPSO draft restricted the amount of DOIs given to an
> organization. And I am thinking that if we share a DOI registry, I
> will need more than one if I want any security mechanism that uses
> labeled ipsec to also have a range for private use. I wasn't sure how
> this would fit into what the draft stated. Thus my confusion. But I
> do think it would be really great if we could share a registry and
> use DOIs in such a similar manner that we could even share the
> values. Am I making sense? What I mean is labeled ipsec could use the
> same DOIs as labeled nfs and CALIPSO. It would not have to allocate a
> separate range of them.
If everyone (labeled NFS, labeled networking, etc.) can agree on a
common DOI representation and registry I think this would make life
much easier for cross-domain solutions.
--
paul moore
linux @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 22:00 ` David P. Quigley
@ 2008-08-28 15:49 ` Paul Moore
0 siblings, 0 replies; 23+ messages in thread
From: Paul Moore @ 2008-08-28 15:49 UTC (permalink / raw)
To: David P. Quigley; +Cc: Joy Latten, gcwilson, selinux, serue, tjaeger
On Wednesday 27 August 2008 6:00:19 pm David P. Quigley wrote:
> On Wed, 2008-08-27 at 17:56 -0400, Paul Moore wrote:
> > I would encourage us to stop thinking about specific DOI values
> > as "SELinux", "Smack", or whatever. There is no reason we can't
> > get the different labeled security implementation to work together
> > but if we continue to propagate the notion of implementation
> > specific DOIs then it becomes that much harder. I think we need to
> > think of DOIs as defining a mapping between an on-the-wire label
> > format to a semantic meaning; the actual format of the wire label
> > isn't important, the meaning of the label is what really counts.
> > Once we understand what a wire formatted label means we can
> > internalize it however we need to so that the implementation can do
> > the necessary access control.
>
> Once again agreed. The issue with this though is that this
> generalized on the wire label is a very difficult thing to come up
> with. Especially since you really want to express concepts such as
> this webserver can only serve public data. That is the kind of high
> level semantic you would want to specify and then have the endpoints
> decide what that means. For MLS this might translate into a category
> for SELinux this might translate into a specific type. This is by no
> means an easy problem.
I never said it would be easy, I just think it is something we should
strive for :)
> > Once again, think of how we handle the MLS-only CIPSO labels today;
> > it is a simplified example but it demonstrates the basic concept of
> > internalizing implementation agnostic security labels and the
> > interoperability benefits that result.
>
> You might have to explain this to me. The issue you raise in the
> paragraph above deals with talking in terms of mechanisms not
> necessarily implementations. The issue with CIPSO is that it is only
> one mechanism which allows them to define their labels in an
> implementation agnostic manner since everyone has agreed on the
> mechanism. This is a little harder when you're spanning mechanisms
> unless we use something similar to what I describe above.
The reason I brought up CIPSO was just to highlight how an
implementation agnostic on-the-wire security label could be
internalized by a specific security/MAC implementation so that useful
access control could be done. It is just one example, and a painfully
simple one at that, but it demonstrates the basic concept and showcases
some of the benefits (and pitfalls).
--
paul moore
linux @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-28 1:30 ` Casey Schaufler
@ 2008-08-28 15:58 ` Paul Moore
0 siblings, 0 replies; 23+ messages in thread
From: Paul Moore @ 2008-08-28 15:58 UTC (permalink / raw)
To: Joy Latten
Cc: Casey Schaufler, David P. Quigley, gcwilson, selinux, serue,
tjaeger
On Wednesday 27 August 2008 9:30:59 pm Casey Schaufler wrote:
> Joy Latten wrote:
> > On Wed, 2008-08-27 at 17:56 -0400, Paul Moore wrote:
> >> On Wednesday 27 August 2008 5:21:17 pm David P. Quigley wrote:
> >>> I would like Paul to give his opinion on this as well but I think
> >>> the best thing at the moment would be go submit your draft where
> >>> the DOI is a tuple of (mechanism,doi). I personally like the idea
> >>> of representing the 32 bit value as a series of four octets for
> >>> human readable purposes but your idea does have some merit with
> >>> regards to what information should be stored with these numbers
> >>> by IANA. By having your draft out there recommending your method
> >>> of handling DOIs it gives people one more thing to consider for
> >>> discussion during the BOF.
> >>
> >> Our emails may have crossed in flight, but just in case it isn't
> >> clear from the response I sent earlier this afternoon I think we
> >> are best served with the DOI as a unified 32 bit value (the dotted
> >> notation is just for display/readability purposes).
> >
> > Ok, just for my clarification, the consensus is that I change this
> > to a 32 bit value field and keep it generic for now as in labeled
> > nfs doc?
> >
> >> I would encourage us to stop thinking about specific DOI values
> >> as "SELinux", "Smack", or whatever. There is no reason we can't
> >> get the different labeled security implementation to work together
> >> but if we continue to propagate the notion of implementation
> >> specific DOIs then it becomes that much harder. I think we need
> >> to think of DOIs as defining a mapping between an on-the-wire
> >> label format to a semantic meaning; the actual format of the wire
> >> label isn't important, the meaning of the label is what really
> >> counts. Once we understand what a wire formatted label means we
> >> can internalize it however we need to so that the implementation
> >> can do the necessary access control.
> >
> > Ok, yep. The label should be an "opaque" (I might be over-using
> > that word by now) blob to the IPsec protocol. I guess in my
> > thinking, it just acts as label storage for the packet and the
> > security mechanism.
> >
> > I guess my concern is this, and it may be because I am not
> > understanding something. My concern is defining DOI as a mapping
> > between an on-the-wire label format to a semantic meaning. Could
> > the mapping be NULL or bypassed sometimes? What I mean is that
> > IPsec could sometimes store things just as they are represented by
> > the security mechanism since it doesn't put anything on the wire.
> > So if both endpoints are using SELinux, it would not need a
> > mapping.
>
> Well ...
You can think of SELinux today as having a single, implicit DOI (this is
a bit of a simplification and doesn't address all of the issues but
just go with it for now :)) and if two SELinux systems are talking to
each other the required cross-DOI translation becomes a NULL-op. If
you look at a SELinux system talking to a TSOL system the cross-DOI
translation is not a NULL-op because you need to translate between
DTE/MLS (SELinux) and just MLS (TSOL).
> > It would need a mapping when
> > the endpoints' security mechanisms are different.
>
> Which it may be if the policies on the two systems don't mesh.
> For example, if one system has no apache it needs no apache_t,
> hence a mapping is required to deal with that. In fact, two
> SELinux systems will obviously require mapping if you're sending
> sids in your opaque label and most likely require mapping even
> if the label is the context unless the machines have identical
> installations and policies.
Bingo, this is the stuff that I ignored in the discussion above, there
is also the MLS/MCS policy versus strict DTE policy which also needs to
be addressed.
> > Thus why labeled ipsec
> > was bent on a (securitymechanism,doi) tuple. Would it be possible
> > for the new DOI scheme to also take this into consideration?
>
> For the cases where securitymechanism is sufficient to describe
> the structure to which a DOI is applied its specification is
> useful. A securitymechanism of SELinux would need to discriminate
> between MLS, MCS, and none of the above. This is a problem with
> any flexible scheme, Smack has it worse than SELinux because there
> is no way to even hint at a structure to the label.
>
> Does even a DOI make sense in a case where the two ends have
> irreconcilable policies? Can you get away with anything less
> than label mappings maintained on each host?
You need a DOI just to understand how to define/interpret the label.
However, a system should be able to decide which DOIs it wants to
support and further which cross-DOI translations it can perform ... and
no, I don't think you need to be able to map every supported DOI to
every other DOI.
--
paul moore
linux @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC 1/2] labeled ipsec internet drafts
2008-08-27 21:33 ` David P. Quigley
2008-08-27 22:56 ` Joy Latten
@ 2008-08-28 16:08 ` Paul Moore
1 sibling, 0 replies; 23+ messages in thread
From: Paul Moore @ 2008-08-28 16:08 UTC (permalink / raw)
To: David P. Quigley; +Cc: Joy Latten, gcwilson, selinux, serue, tjaeger
On Wednesday 27 August 2008 5:33:05 pm David P. Quigley wrote:
> On Wed, 2008-08-27 at 16:50 -0400, Paul Moore wrote:
> > I am currently waiting to see how the CALIPSO specification is
> > received by the general IETF SAAG community, especially the
> > assertion that explicit packet labeling is an important user
> > requirement. If the CALIPSO specification is well received I plan
> > on submitting a draft specification which will provide a more
> > general packet labeling mechanism for IPv6 and possibly IPv4.
>
> When I was in Dublin it was suggested that I look at the CALIPSO
> draft for DOI related information so they are well aware of it and it
> doesn't seem to have hit much resistance yet.
Yep, although it still hasn't really hit a really wide distribution,
the -05 draft was just recently submitted and it should see a wider
audience than previous drafts. As one would expect there is a fair
amount of political wrangling going on but so far things look good.
> > > > > > > > > >I'm also concerned with the implied convention of
> > > > > > > > > > assigning one value to a particular implementation.
> > > > > > > > > > In the SELinux case, how do you deal with a
> > > > > > > > > > non-MLS/MCS policy such as Gentoo/Ubuntu talking to
> > > > > > > > > > a MLS/MCS policy such as Fedora/RHEL? What about
> > > > > > > > > > policies with different types? Differing numbers of
> > > > > > > > > > MLS sensitivity levels or categories?
> > > > > > > > >
> > > > > > > > > Hmm... not sure I understand so I may not answer this
> > > > > > > > > correctly...
> > > > > > > > >
> > > > > > > > > The algorithm indicates the security mechanism.
> > > > > > > > > In a way, it identifies the syntax/semantics of the
> > > > > > > > > security context to security mechanism, since
> > > > > > > > > security mechanisms may use different
> > > > > > > > > syntax/semantics for the security contexts. i.e.
> > > > > > > > > SELinux and SMACK.
> > > > > > > > > The algorithm field in SELinux is used to "authorize"
> > > > > > > > > the security context. In other words, SELinux only
> > > > > > > > > wants and understands SELinux's security context
> > > > > > > > > syntax/semantics. The "doi" would be used for
> > > > > > > > > further differentiation within SELinux domain. Far
> > > > > > > > > example, a sysadm wants to differentiate between
> > > > > > > > > SELinux policy versions in his domain. He could used
> > > > > > > > > "doi" field to do this.
> > > > > > > > >
> > > > > > > > > I suppose if you wanted two different security
> > > > > > > > > mechanisms to interoperate, a mapping of some sort
> > > > > > > > > would have to be created between them. The security
> > > > > > > > > mechanisms would need to indicate they accept (via
> > > > > > > > > the mapping) the other's security context
> > > > > > > > > syntax/semantics. In other words, they would
> > > > > > > > > "authorize" the two different security contexts. It
> > > > > > > > > would do this via the "algorithm" and/or "doi"
> > > > > > > > > fields. I am thinking in this case, "doi" could even
> > > > > > > > > indicate the mapping such as CIPSO's DOI does.
> > > > > > > > >
> > > > > > > > > I considered the information contained in the
> > > > > > > > > "algorithm" and "doi" fields required for
> > > > > > > > > interoperability, and the use implementation
> > > > > > > > > specific.
> > > > > > > > >
> > > > > > > > > If this doesn't answer your question, let me know.
> > > > > > > >
> > > > > > > > I think what Paul might be asking is why is it better
> > > > > > > > to have two fields, one for Security Mechanism and one
> > > > > > > > for the DOI when that can be one field. If we go with a
> > > > > > > > method similar to the second described above for DOIs
> > > > > > > > you could have IANA allocate a range of DOIs for
> > > > > > > > SELinux partitioning it off into a range for publicly
> > > > > > > > assigned DOIs and privately managed DOIs. It is
> > > > > > > > acceptable to have IANA create and populate a registry
> > > > > > > > with values in the document.
> > > > > > >
> > > > > > > Ok, I understand now. Yes, that seems reasonable, fair,
> > > > > > > and flexible. I can still keep semantics (a mechanism and
> > > > > > > ability to group or differentiate).
> > > > > > >
> > > > > > > So, a doi field that is 32 bits, with perhaps so much for
> > > > > > > SELinux, further partitioned for public and private use.
> > > > > > > The same for Smack. Right? And remaining for future use.
> > > > > >
> > > > > > The standards people don't particularly care about specific
> > > > > > security models in this case. I initially mentioned
> > > > > > implementation specific details in my early labeled NFS
> > > > > > drafts and was told that those aren't really a concern of
> > > > > > the protocol. Since the label is a (DOI,<OPAQUE>) tuple it
> > > > > > is up to whomever obtains a number from IANA to define the
> > > > > > meaning of that DOI. However it should be written into the
> > > > > > standard what information is recorded by IANA to bind to
> > > > > > these numbers. Also do we see several registries? I really
> > > > > > only see one registry that can be shared by all three of
> > > > > > these drafts. I just hope they don't want us to write up an
> > > > > > RFC for the definition and management of DOIs (it might
> > > > > > happen that way though).
> > > > >
> > > > > Ok, gotta admit, I am a little confused as to how we could
> > > > > share the same DOI registry with CALIPSO since they are using
> > > > > a dotted-quad format right now? And it doesn't seem to
> > > > > accomodate but one DOI from IANA which leaves me confused as
> > > > > to how I would get one and then partition it for private and
> > > > > non-private uses.
> > > >
> > > > Well we might need to talk with the CALIPSO people to figure
> > > > out a way that we can all use their DOI scheme. At its core
> > > > their method just seems to be a dotted-quad format as you have
> > > > said. IANA's job is to keep track of these dotted-quads.
> >
> > The CALIPSO DOI is defined as a opaque 32 bit unsigned integer,
> > similar to CIPSO and your description of labeled NFS's DOI. The
> > dotted notation used in part of the CALIPSO draft is just a
> > convenient way of representing the value in the same way we
> > represent IPv4 addresses.
> >
> > The CALIPSO specification does set aside DOI ranges for specific
> > uses (is this the source of confusion?) which I think is a good
> > idea and I would encourage other protocols to follow suit.
>
> What do they mean by opaque 32 bit integer here? If they are defining
> ranges and assignments to the integer it can't truly be opaque. I
> don't recommend we transport the DOI as the colon separated octet
> group but for the purpose of assigning DOIs and ranges and even
> specifying them in programs I think the syntax is useful.
By opaque value I think they mean a single 32 unsigned integer that
isn't to be subdivided. While I agree that blocking off certain ranges
of DOIs for specific uses does seem to raise eyebrows in regards to
the "opaque" claim, the ranges don't violate the fact that it is still
a 32 bit unsigned integer.
How the value is represented is another matter entirely, the CALIPSO
authors chose the IPv4'esque dotted notation which seems as good as any
to me.
> I hesitate to say this but I think it might be a good idea to draw up
> a draft explaining what a DOI is and what is expected from IANA for
> them. I've received emails from people working on security labels in
> application layer protocols so they might be interested in a standard
> method for specifying and interpreting DOIs as well.
That sounds like it might be reasonable as an informational RFC. If you
are looking help I'd be more than happy to contribute or review. It is
probably a good idea to contact Randall as I think he has the most
current user/IETF feedback on DOI issues.
--
paul moore
linux @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2008-08-28 16:08 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-25 20:46 [RFC 1/2] labeled ipsec internet drafts Joy Latten
2008-08-25 21:42 ` David P. Quigley
2008-08-26 17:17 ` Joy Latten
2008-08-26 20:24 ` David P. Quigley
2008-08-27 16:17 ` Joy Latten
2008-08-27 16:49 ` David P. Quigley
2008-08-27 18:41 ` Joy Latten
2008-08-27 20:50 ` Paul Moore
2008-08-27 21:33 ` David P. Quigley
2008-08-27 22:56 ` Joy Latten
2008-08-28 16:08 ` Paul Moore
2008-08-27 23:27 ` Joy Latten
2008-08-28 15:44 ` Paul Moore
2008-08-27 21:21 ` David P. Quigley
2008-08-27 21:56 ` Paul Moore
2008-08-27 22:00 ` David P. Quigley
2008-08-28 15:49 ` Paul Moore
2008-08-28 0:22 ` Joy Latten
2008-08-28 1:30 ` Casey Schaufler
2008-08-28 15:58 ` Paul Moore
-- strict thread matches above, loose matches on Subject: below --
2008-07-25 17:51 Joy Latten
2008-07-26 16:34 ` Paul Moore
2008-07-26 16:34 ` Paul Moore
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.