|Main Archive Page > Month Archives > ipsec archives|
reading your 3GPP document, I think you have something else in mind, not exactly what NEA is planning on doing. NEA posture information may be very large, containing data about many components of the OS and applications. I believe what you are looking for is a much more limited set of hash values, similar to what you'd measure as part of TPM validation of a system. This is a very unique reqiurement right now, probably a few years ahead of NEA (their origins are with TCPA, but they're far from the Trusted Computing paradigm now). So I am not sure there is value today in integrating your requirements (and the related IKE-based solution) with NEA or even in standardizing this solution within ipsecme.
You are still free to request a notification type, so there's nothing blocking your 3GPP work from moving forward. And I am open to be convinced otherwise. Also, I suggest that you talk to the NEA chairs.
And a related technical issue: IKE is not good as a transport for large pieces of information, because everything needs to fit into a UDP packet. Your lightweight notification will not be a problem. But large NEA posture blobs will be.
Thanks for the initial feedback. I certainly agree with the view that we shouldn't duplicate the NEA protocols and I couldn't emphasize enough that the intent of the ID is purely from transport's perspective. I am grateful that you can view the ID with an open mind.
Perhaps a little background could stir up people's interest. I have drafted this ID with initial 3GPP femto application in mind. In 3GPP femto case, there are some very specific security requirements that the device authentication and device integrity validation be bound together due to the fact that the femto AP will be deployed in environments that is not very well controlled by the network operators (e.g. semi-hostile environment) Part of the device integrity validation necessitates transporting NEA information to the network for validation. 3GPP working group SA3 has chosen IKEv2 as the authentication protocol with certificate-based credentials for the femto devices. The working group has also agreed in principle that the Notify payload within IKEv2 can be used for transporting the integrity information. Please see the latest draft of the 3GPP standards for additional information. The latest draft is here: ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_56_Seattle/Docs/S3-091491.zip , which is also one of the references in the ID. Please note that I'm also the editor of this 3GPP document. We have looked at what other groups have done and it looks like that with minimal extension to IKEv2 we could piggyback the NEA transport part using the Notify payload with relative simplicity and least amount of interoperability issues, especially since IKEv2 is widely used as the de facto standard protocol for authentication and key exchange.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Yaron Sheffer
Sent: Saturday, September 12, 2009 8:29 AM To: Stephen Kent; email@example.com
Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt
I completely agree that we shouldn't be duplicating the NEA protocols. OTOH, I'm willing to consider transport of NEA information within IKE/IPsec if people are interested. Note that NEA has just only started to look at their own mainstream transport protocol (NEA-PT). This is very likely to end up being EAP.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of
> Stephen Kent
> Sent: Saturday, September 12, 2009 10:48
> To: firstname.lastname@example.org
> Cc: email@example.com
> Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt
> At 4:06 PM -0400 9/11/09, Marcus Wong wrote:
> >Steve, you are mostly right, but this I-D only deals with the integrity
> >exchange using the notify payload. Thanks.
> Thanks for the clarification. That still raises the question of why
> we ought to duplicate this NEA functionality in IKE. Does the I-D
> provide suitable motivation for that, and has the idea been passed by
> the NEA WG folks?
> IPsec mailing list
> Scanned by Check Point Total Security Gateway.
Scanned by Check Point Total Security Gateway.