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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
