Dear Yoav, Sincerely thanks for your kind responses to my colleague ZaiFeng.
Since it is Chinese Spring Festival holiday starting today and will last for another week, I have promised ZaiFeng to take care of the Q&A regarding her IETF draft on the mailing list. Hence, please allow me to respond to your questions. You asked us excellent questions regarding the clarifications on the roles and responsibilities for the SeGW and the Core Network. Yoav said: >>>>> I would think that the SeGW could instead look at the decrypted protocol between the FAP and the core network (it is decrypting it after all), and block it if it contains "lies". A change like this would require modifying only the SeGW. I may be showing some serious firewall vendor bias here... >>>>> The reason that we did not consider the SeGW to "interpret" the contents of the CP in order to perform the interception because of the following three reasons: (1) As you have already known that, the CP's contents are not expected to be defined by IETF. (2) The SeGW is a generic network element which is commonly employed by the Femto architecture across the 3GPP, 3GPP2, WiMAX and Femto Forum, and is not specific to a particular mobile technology, hence, in order for the SeGW to perform the interception, it will have the full knowledge on "how" to interpret the CP's contents according to the 3GPP, 3GPP2 or WiMAX design decision which leads to the next reason .. (3) There is no standardized interface between the SeGW and the Mobile Core Network, hence, there is no way to allow the mobile core network to dynamically configure the info to the SeGW that is corresponding to the given mobile technology Given the above three considerations, we decide that by emulating today "notary" behavior for allowing the trusted party to notarize the untrusted party which is communicating with the 3rd party is a better approach to address the architecture restrictions that I explained above. Yoav said: >>>>> Regarding the term "notarized", I would prefer not to bring in a new term that is burdened with other meaning. But legal notaries are obscure enough that it doesn't matter much. Perhaps some explanation as to what it means in the draft would help. >>>>> The reason that we borrow the term "notary" is because of the design that we propose is almost identical to the concept of notary - i.e. - FAP is the untrusted party for the mobile core network and is resided at the customer's premises - SeGW is the trusted party for the mobile core network and is resided at the gateway entry of the mobile core network - SeGW has full knowledge of the true identity of the FAP and hence, once it authenticates and authorizes the FAP, it can then notarize the information that is presented by the FAP - Mobile core network that entrusts to SeGW will verify the notarized info present by the FAP in order to determine the legitimacy of the FAP's information Hence, I would like to follow your advice to propose the following explanations added to the zong's draft "terminology" section for the concepts of "notarized info" and "notarized signature": Notarized Info - Information that is originated by the untrusted party (e.g. FAP) to the trusted party (e.g. SeGW) for the certification of the identity of the untrusted party based on PKI. Notarized Signature - Signature provided by the trusted party who has the full authority to certify the true identity of the untrusted party based on the PKI, and using the PKI information to certify the specific contents were originated by the untrusted party. Regarding to the sizes of the notarized information and the notarized signature, we don't expect them to be very large. However, since it is implementation decision, it is hard for us to respond to you on the exact size right now. If the size is a concern, could we limit it to no more than 100 bytes if this is acceptable to you. Your thought is most appreciated. Sincerely thanks in advance for your kind advice. Cheers. Tricci Yoav Nir <[email protected]> Sent by: [email protected] 01/22/2012 07:04 AM To "'[email protected]'" <[email protected]> cc "[email protected]" <[email protected]> Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt So if I understand this correctly, the notarized data contains the acceptable mode and the allowed member groups, signed (and time-limited?) by the SeGW. The tunneled protocol between the FAP and the core network would change, so that instead of the FAP sending unsubstantiated claims, it would replay the notarized data from the SeGW. Wouldn't this require an update of both core network components, SeGW and FAPs? I would think that the SeGW could instead look at the decrypted protocol between the FAP and the core network (it is decrypting it after all), and block it if it contains "lies". A change like this would require modifying only the SeGW. I may be showing some serious firewall vendor bias here... Anyway, yes, your clarification helped me very much. Regarding the term "notarized", I would prefer not to bring in a new term that is burdened with other meaning. But legal notaries are obscure enough that it doesn't matter much. Perhaps some explanation as to what it means in the draft would help. You are correct in the draft, that it is out of scope for the working group what the exact content of the new attribute is. However, the CP payload is contained in the biggest packet of all of IKE - the IKE_AUTH packets. Can you tell us how large these attributes may be? Since IKE is still UDP-only, size matters very much. Thanks Yoav From: [email protected] [mailto:[email protected]] Sent: 21 January 2012 11:08 To: Yoav Nir Cc: [email protected] Subject: 答复: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Yoav: Thank you for your email. Regarding to your question on "what is the malicious FAP lying about", I would like to give you some further background. In real femto deployment, not every mobile terminal is allowed to attach via an FAP. In fact, in the real deployment, there are 3 kinds of FAPs: open mode FAP, close mode FAP, and hybrid mode FAP. The open mode means that the FAP is open to everyone, close mode means the FAP only allows a closed group of members to access, and the hybrid mode means that the FAP is open to everyone, but only a closed group of members will have higher priority or have authority to visit certain resources. According to some SDO (e.g. 3GPP), the access control of the mobile terminals attaching via a FAP is done in core network, thus, it is the core network that decide whether the mobile terminal can attach to an FAP. In order to help the core network make decision on whether the mobile terminal can attach to an FAP, the FAP needs to send information, such as the mode of the FAP, and the allowed member group of the FAP, to the core network. A compromised FAP could send false mode and false allowed member group to the core network, so that a not allowed mobile terminal could be allowed by the core network. I wish the above clarification helps you understand the problem. Regarding to the term notarized, since I am green to this group, I am not sure, do you prefer to replace the notarize with signature? Please let me know, thank you! BR Zaifeng Yoav Nir <[email protected]> 2012-01-21 15:30 收件人 "<[email protected]> <[email protected]>" <[email protected]> 抄送 "[email protected]" <[email protected]> 主题 Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Zaifeng Reading your draft, I'm trying to understand the problem you are solving. It is about the FAP being compromised and sending false information through the tunnel. What is the malicious FAP lying about? How does sending some information (does "notarized" mean "signed"?) from the SeGW to the (compromised) FAP help? One general comment: "notarized" is a legal term, similar to "signature". Although there is some analogy between the legal concept of signature and the digital signatures, such analogies only go so far. Using such a borrowed term has IMHO led to more confusion than clarity. I would rather not use legal terms in protocols (although "protocol" is also a borrowed term) Thanks, Yoav On Jan 20, 2012, at 8:40 AM, <[email protected]> <[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 _______________________________________________ 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
