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

From: [email-masked]
Date: Fri, 20 Jan 2012 14:40:31 +0800

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

----- 转发人 宗在峰008246/user/zte_ltd 时间 2012-01-20 14:33 -----

[email-masked] 
2012-01-18 16:06

收件人
[email-masked]
抄送
[email-masked]
主题
New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

A new version of I-D, draft-zong-ipsecme-ikev2-cpext4femto-00.txt has been 
successfully submitted by Zaifeng Zong and posted to the IETF repository.

Filename:                 draft-zong-ipsecme-ikev2-cpext4femto
Revision:                 00
Title:                            IKEv2 Configuration Payload Extension 
for Notarizing Femtocell in Mobile Core Network
Creation date:            2012-01-18
WG ID:                            Individual Submission
Number of pages: 12

Abstract:
   IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many
   standardized network solutions to provide the secure transport
   between network elements over third party&#39;s infrastructure.  Today
   Femtocell deployment requires the mobile operator&#39;s Femtocell AP
   (FAP) to leverage the IPSec IKEv2 to support mutual authentication
   and data protection between the insecure Femtocell, which typically
   deployed in customer&#39;s premise, and its corresponding mobile core
   network.

   A known security threat exists in Femto architecture for failing to
   validate the FAP&#39;s identity and information provided by FAP at the
   mobile operator&#39;s core network.

   This document reviews this security threat and proposes a simple
   extension of the IKEv2 to resolve the issue.

The IETF Secretariat

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Jan 2012 09:30:46 +0200

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

---

From: [email-masked]
Date: Sat, 21 Jan 2012 17:08:01 +0800

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-masked]> 
2012-01-21 15:30

收件人
"<[email-masked]> <[email-masked]>" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 22 Jan 2012 17:04:20 +0200

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-masked] [mailto:[email-masked]]
Sent: 21 January 2012 11:08
To: Yoav Nir
Cc: [email-masked]
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.

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

2012-01-21 15:30

收件人
"<[email-masked]> <[email-masked]>"        <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [IPsec] [IPSec]: New Version Notification for        draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Zaifeng

Thanks,

Yoav

---

From: [email-masked]
Date: Sun, 22 Jan 2012 14:55:15 -0800

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-masked]> 
Sent by: [email-masked]
01/22/2012 07:04 AM

To
"[email-masked]'" <[email-masked]>
cc
"[email-masked]" <[email-masked]>
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...

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-masked] [mailto:[email-masked]] 
Sent: 21 January 2012 11:08
To: Yoav Nir
Cc: [email-masked]
Subject: 答复: Re: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Yoav: 

BR 
Zaifeng 

收件人

Hi Zaifeng

Thanks,

Yoav

> Please send your comments to the list. Thanks! 

_______________________________________________
IPsec mailing list
[email-masked]
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.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Jan 2012 13:50:31 -0500

>Please send your comments to the list. Thanks!

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.

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.

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.

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.

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.

Steve

---

From: [email-masked]
Date: Thu, 26 Jan 2012 21:31:14 -0800

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

>Please send your comments to the list. Thanks!

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?  

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.      

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. 

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. 

Tricci > I hope that you can understand that what you described above is 
NOT what we proposed.  Thank you for your comments.

Steve

---

From: [email-masked]
Date: Sun, 29 Jan 2012 17:27:22 +0800

Hi Yoav:

Thanks for your email and sorry for my late response. Since Tricci has 
answered some of your questions, I would like to focus on "time-limited" 
issue. From my understanding, those FAP information (e.g. mode and allowed 
memeber groups) are relatively stable, hence, I assume the change of these 
information is quite rare, only in case the network is re-configured. 
Wouldn't you think that it is reasonable to assume that the FAP need to 
restart when the network is reconfigured? Since there is the femto 
management system, it is not hard to reboot the FAP by issuing an order 
from the femto management system remotely, without the involvement of 
human interference. Hence, I assumed that the core network always get the 
information from FAP, and the SeGW will not need to replay the notarized 
data to the core network. Does this make sense to you?

Thanks!

BR
Zaifeng

2012-01-22 23:04

收件人
"[email-masked]'" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: Re: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

 

 
Thanks
 
Yoav

Hi Yoav: 

BR 
Zaifeng 

收件人

Hi Zaifeng

Thanks,

Yoav

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jan 2012 10:00:22 -0500

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

>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