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. Thanks, Marcus -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Saturday, September 12, 2009 8:29 AM To: Stephen Kent; mw...@huawei.com Cc: ipsec@ietf.org 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. Thanks, Yaron > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Stephen Kent > Sent: Saturday, September 12, 2009 10:48 > To: mw...@huawei.com > Cc: ipsec@ietf.org > 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 > data > >exchange using the notify payload. Thanks. > > > >Marcus > > > > 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? > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
