Hi Stephen, Tricci: Sorry that I didn't respond this email on time due to the chinese spring festival. I would like to thank Stephen first for reviewing the draft and giving me your suggestions.
From reading Stephen's email, if my understanding is correct, you assumed that SeGW will pass some information to the core network in order that the core network can verify the "notarized" FAP information? And you think that the information exchange betwen SeGW and the core network is a big change to IKE, is this correct understanding of your email? If my understanding of your email is correct, then please let me clarify a little bit more to make the draft more clear. In our draft, we have not expected to have information exchange between SeGW and core network, in our original design, we assumed that the core network will be configured with information that is needed to verify the certificate signed by the SeGW, i.e. the core network is configured with the algorithm and key to be used to verify the signature sent from the FAP to the core network. I understand that this configuration based assumption may have some limits, I think that to generate a cert by the SeGW and send it to the FAP and then from the FAP to the core network is a good implementation option. Perhaps I should make the CP flexible enough to adapt to all the implementation options. If you have any good idea on how the CP should be designed, could you kindly give me your suggestion? Thanks! BR Zaifeng TricciSo052785/user/zte_ltd 2012-01-27 13:31 收件人 Stephen Kent <k...@bbn.com> 抄送 ipsec@ietf.org, ipsec-boun...@ietf.org, ZongZaiFeng008246/user/zte_ltd@zte_ltd, t...@zteusa.com 主题 Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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 <k...@bbn.com> Sent by: ipsec-boun...@ietf.org 01/26/2012 10:50 AM To zong.zaif...@zte.com.cn cc ipsec@ietf.org Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt At 2:40 PM +0800 1/20/12, zong.zaif...@zte.com.cn 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
