Dear Stephen, Sincerely thanks for your expert advice on my colleague's (ZaiFeng's) proposal. Since she is still on Chinese Spring Festival holiday, please allow me to respond on behalf of her to get more valuable inputs from you.
Please see my comments and questions inline below (sorry for the long email below). Thanks in advance. Tricci Stephen Kent <[email protected]> Sent by: [email protected] 01/26/2012 10:50 AM To [email protected] cc [email protected] Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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. Tricci > Fully agree with you that, we need to make a proposal to be consistent with IETF standards. In addition, I am also hoping you would agree that, as the solution is proposed to fix a generic issue for Femto network, we need to also consider the impact of the final solution towards the Femto's existing deployment as long as we did not break IKE. Would this be acceptable to you? 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. Tricci > The reason that we choose the words "notarization" because the design of this proposal is to have a trusted-party (i.e. SeGW) of the target network (i.e. Mobile Core Network) to notarize the untrusted-party (i.e. FAP) so that the untrusted-party can leverage the trusted-party's notarized signature to be present to the target network to gain its trust and confident on the identity of the untrusted party as well as the info presented by the untrusted party to the target network. This approach is very similar to today notarization process in the legal process. Tricci > However, if you truly feel strongly against this word, we don't really have strong opinion on this one. We respect your expertise to suggest the better wording for us. Tricci > One important aspect that I would like to clarify is that, in our perspective, the info that is carried by the IKE is not really an opaque. In our perspective, the info is just not defined by IETF, but by the network/SDO which is responsible to utilize such solution to define the content of the info. If you think that it is necessary, we can add the note to the draft to specify that, whichever the network solution or SDO that chooses to use this solution must indicate what are the info which will be conveyed between the two IKE peers in advance. For example, if 3GPP decides to use this IKE feature as described in this draft to mitigate the FAP security issue, 3GPP should specify what and how the info is carried by the CP. 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. Tricci > It is important to point out that, the SeGW does NOT pass on the CP info to the Mobile core network. What was described in the draft is that: Tricci > (1) FAP (i.e. IKE-initiator) includes the "Client Notarized Info" in the CP-Request during the mutual authentication exchange to SeGW (i.e. IKE-Responder) Tricci > (2) Once the SeGW authenticates the FAP (i.e. successful authentication), the SeGW will then notarize the info to derive "Server Notarized Signature" (algorithm is determined by network operator or standard SDO) which will then be included in the CP-Reply to the FAP. Tricci > (3) FAP will then include this Server Notarized Signature info in its own control signaling communication with the mobile core network which deploys the SeGW. The FAP's signaling contains the SeGW's Notarized Signature and they are encapsulated within the IPsec tunnel. Hence, SeGW is NOT involved in passing the CP's info to the Mobile Core Network. 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. Tricci > If I understand your proposal correctly, you suggested to have the SeGW to generate the additional cert to be used by the FAP to present to the target network, isn't it? Tricci > Unfortunately, this approach does not address the issue that we are trying to resolve. First of all, both FAP and SeGW already have their own certs to support their mutual authentication. Secondly, the new cert that you proposed will not contain the "specific" info that we require for the SeGW to certify/notarize for the FAP such that the FAP can present the certified/notarized info to the target mobile core network. Tricci > In summary, what we are trying to achieve is to have the SeGW, which is the trusted party of the Mobile Core network, to certify/notarize the "specific" configuration and access control info provided by the FAP to be notarized by the SeGW. This is how the Mobile Core network to verify the FAP's true identity and the associated info provided by the FAP is trust-worthy. Tricci > As for your last sentence above saying "That way the SecGW would not have to pass on data to the core network.". Again, please note that SeGW does NOT explicitly pass the CP info to the Mobile Core Network, it is the FAP to include the notarized signature in its signaling which is part of the IPsec payload to be sent to the Mobile 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. Tricci > I hope that you can understand that what you described above is NOT what we proposed. Thank you for your comments. Steve _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
