Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

From: [email-masked]
Date: Wed, 1 Feb 2012 00:46:46 -0800

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 <[email-masked]> 
01/30/2012 07:00 AM

To
[email-masked]
cc
[email-masked], [email-masked], [email-masked]
Subject
Re: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

At 9:31 PM -0800 1/26/12, [email-masked] 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.