Subject: Re: [IPsec] question regarding ikev2 rfc

From: Joy Latten <[email-masked]>
Date: Wed, 13 Feb 2008 18:36:57 -0600

I apologize for the delay in my response.

>>My colleagues and I implemented technology that uses "labeled" SAs
>>to enforce mandatory access control on the network. We introduced a
>>new security attribute to allow IKE to communicate an opaque
>>security label when negotiating an SA. The IPsec DOI (rfc 2407)
>>contained a SIT_SECRECY and SIT_INTEGRITY but these were not
>>sufficient. I also noticed they are not in IKEv2.
>>
>>It had been our intention to create an addendum to IPsec DOI and
>>receive number from IANA for the security attribute. Thus allowing
>>interoperability. But IKEv2 has obsoleted IPsec DOI and IKEv1.
>>
>>Perhaps it could be considered an addendum to IKEv2, but I am not
>>sure if it would be considered a transform type? Any suggestions
>>would be greatly appreciated.
>>
>RFC 2301 discussed using IPSO labels for mandatory access control, 
>but there was so little interest in the community that the discussion 
>was removed from 4301. I presume you're using IPSO or CIPSO, right?
>
We are not using IPSO or CIPSO. My underlying security 
mechanism is SELinux which uses type enforcement, RBAC, and 
multi-level security to enforce MAC. All objects and subjects
within the OS are labeled.  The security label is a string
formatted as  user:role:type:sensitivity-level.

CIPSO accomodated the sensitivity level, but not the entire
SELinux label.  Thus, we extended ISAKMP/IPsec DOI  to
include an attribute that negotiated a security label string.
We tried to make this an "opaque blob" to IKE such that different
security mechanisms can utilize.

We do not communicate, but negotiate the label. If the label
is not an acceptable one for responder, then negotiation ends.
However, this requires communication with kernel or underlying
security mechanism to determine. (Big hack and needs better solution.)
This way, inbound processing only needs spi to pull
up correct SA. This is different from 2401 which says for inbound processing, 
you SHOULD first check the packet's label (as defined in SA) against
interfaces label for validity.

>Use of security labels would require additions to many parts of 
>IPsec, e.g.,  the PAD and SPD, as well as IKE for carriage of labels 
>to be used to negotiate child SAs.

Yes, I understand. Our implementation referenced
the older set of RFCs and the internet-draft I'd started was an
addendum to ISAKMP/IPsec DOI, which are obsoleted by IKEv2. 
I'd be happy to do an internet-draft or to assist someone else.
We used this feature in IPsec to acquire LSPP certification
and others have indicated interest. Especially since it
accomodates ipv6 too. 

I have included a pointer to a very high level design description.
It is a little out-dated and references the Linux kernel,
but provides a basic description if anyone is interested. 
http://www.cse.psu.edu/~tjaeger/papers/securecomm06.pdf

regards,
Joy 
_______________________________________________
IPsec mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipsec