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

From: [email-masked]
Date: Sun, 29 Jan 2012 16:39:45 +0800

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 <[email-masked]>
抄送
[email-masked], [email-masked], 
ZongZaiFeng008246/user/zte_ltd@zte_ltd, [email-masked]
主题
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 <[email-masked]> 
Sent by: [email-masked]
01/26/2012 10:50 AM

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

At 2:40 PM +0800 1/20/12, [email-masked] 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-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jan 2012 16:59:21 -0500

At 4:39 PM +0800 1/29/12, [email-masked] wrote:
>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.

no problem. Happy New Year.

>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?

not quite. I was wrong to suggest that the SecGW sent the signed data 
directly to the core network. The data that the SecGW signs is 
presented by the FAP to the core network. My principle concern is 
that it is inappropriate to use an
IKE payload to transport data to be signed, and then the signed data, 
when the consumer of this data is not IPsec. IKE payloads are used to 
convey data needed to create and manage SAs, including key material, 
data for authentication, etc. This signed data appears to be for 
authorization decisions effected by some element of the core network, 
outside of the IPsec SA itself.

>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?

I don't want to suggest design options for you, as I am not familiar with
the environment in which you are working. Also, lots of flexibility 
may not be a good ideas in a secruity context. I'm merely suggesting 
that using IKE payloads seems inappropriate for what I believe you 
are trying to do, based on reading one very brief document.

Steve