At 2:40 PM +0800 1/20/12, [email protected] wrote:
Hi Folks:
There is a new draft available that some of you may be interested
in looking at.
The draft is available via the following link:
http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt
Please send your comments to the list. Thanks!
BR
Zaifeng
Lookig very briefly at your doc, it seems that there might be a cleaner way to
provide this capability, one that is more consistent with IETF standards.
The term "notarization" seems a bit out of place here. The term
"certifies" makes more sense, and suggests an alternative solution
approach. Also, IKE is used to convey info between IPsec (note
correct spelling) entities for use in key management and SA
management,including access control. Having IKEv2 carry opaque info
for use by an entity other than the IPsec implementation seems
inappropriate.
The doc suggests that the proposed new payload has minimal impact on
IPsec/IKE. One must look not only at the bits on the wire, but also
the IKEv2 communication paths at the endpoints. Carrying this data in
IKEv2, for use by the "core network" also seems to require that
IKEv2 pass the date on to external entities outside of the IPsec
environment. That is a non-trivial change to what IKE does. In this
case both the FAP and the SecGW are extracting signed data from IKE
and passing it on to the core network, to authenticate the identify
of the FAP and related FAP attributes.
The SecGW is digitally signing an attestation about capabilities
(including the identity) of the FAP. In PKI standards, this sort of
info is usually expressed via an attribute cert. I doubt that many
IKE implementations would know what to do with an attribute cert, but
that's irrelevant here because IKE is not really consuming the signed
data. The SecGW would seem to be acting as a CA or an AA. Why not
have the SecGW issue a cert (or an attribute cert) to the FAP? Then
have that cert be passed by the FAP to whatever really needs to
consume it, along with signed data that establishes that the FAP is
bound to the cert. That way the SecGW would not have to pass on data
to the core network.
One might also consider other, IETF standard mechanisms for passing
around authentication and authorization data that is to be consumed
by a 3rd party. Thsi sort of function is not what IKE is intended to
perform.
Steve
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
