Dear Stephen, Sincerely thanks for your patient to provide us so much inputs for this draft.
Now I understand of your consideration of the cert approach. But I must confess that it is still not clear to me how are we going to use the cert as your suggested to address our problem. Since ZaiFeng is back from holiday. I will leave it to you and her to discuss further on this subject. Truly appreciate your kind advice, always. Cheers. Tricci Stephen Kent <k...@bbn.com> 01/30/2012 07:00 AM To t...@zteusa.com cc ipsec@ietf.org, zong.zaif...@zte.com.cn, t...@zteusa.com Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt At 9:31 PM -0800 1/26/12, t...@zteusa.com wrote: ... 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? yes, so long as the proposed solution makes good use of existing IETF standards, or proposes new ones where existing standards are not applicable. ... 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. There is an analogy to notarization in the legal sense, but in the technical context, the function performed by the SecGW is highly analogous to that of a CA or AA. 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. I think it is preferable to use terms that relate to existing, very relevant security technologies, when one makes a technical proposal such as this. 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. If different technologies carry different data in the same IKE payload, that is questionable. The content of a payload should be evident from the payload ID. And the content should be defined in an IETF doc, if it is not vendor-specific. ... 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) the SecGW sends the signed data to the FAP, which passes it to the core network. So the SecGW is passing the data to the core network via the FAP. I was not clear in my comment. 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. again, this seems to be a case where the full spec of what is being carried by IKE should be defined in RFCs. Using IKE to transport arbitrary data, specified by other SDOs, is questionable. 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. see my reply above. ... 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. how can you say that a new cert, the content of which I did not describe, will not contain the "specific info" required? the intent of having the SecGW generate a cert for the FAP is to put the appropriate info into it. 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. Perhaps I don't understand the term "specific" here. The SecGW must understand the data provided by the FAP, otherwise it cannot verify and sign it. Can you provide example of the data that is to be signed, for 3GPP and LTE? Maybe that would help. 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. Yes, I understand. ... Tricci > I hope that you can understand that what you described above is NOT what we proposed. Thank you for your comments. I understand that you propose using a single IKE payload to transport arbitrary data, data that will differ based on network context, and that the IKE entities at the SecGW and the FAP are NOT the consumers of this info. That seems like a bad use of IKE. Steve -------------------------------------------------------- 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
