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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
