Ben, please see in-line.
Simon
SEMYON (SIMON)
MIZIKOVSKY
600 Mountain Avenue
ALCATEL-LUCENT
DIRECTOR
WIRELESS
SECURITY STANDARDS
600/700 Mountain Ave., Rm. 3C-506
Murray Hill, NJ 07974-0636 USA
T: +1
908 582 0729
M: +1 732 239
7533
F: +1
908 743 4361
Simon.Mizikovsky@xxxxxxxxxxxxxxxxxx
Note: This message, and any attachments, is intended only for
the recipient(s) identified above. The information contained in this
message may be privileged, confidential or proprietary, and its use or
disclosure by other than intended recipient(s) is prohibited and may be
unlawful. If you have received this message in error, please delete it,
and do not distribute or retain a copy of it.
From: Ben Campbell
[mailto:ben@xxxxxxxxxxx]
Sent: Friday, August 26, 2011 7:49
PM
To: Mizikovsky, Semyon B (Simon)
Cc: draft-ietf-dime-ikev2-psk-diameter.all@xxxxxxxxxxxxxx;
gen-art@xxxxxxxx Review Team; The IETF
Subject: Re: [Gen-art] Followup on
Gen-ART Telechat Review of draft-ietf-dime-ikev2-psk-diameter-08
Hi, thanks for the response. Please keep in mind that
my comments are no more binding than any other, so if everyone else is
convinced I am wrong, that's okay :-)
Specific comments inline:
On Aug 26, 2011, at 6:24 PM, Mizikovsky, Semyon B (Simon) wrote:
> Ben, thank you for your comment.
> We do not specify the protocol between IKEv2 Peer and HAAA. We specify the
protocol between Diameter Client and Diameter Server. The Diameter Server
happens to be the HAAA. The Diameter Client happens to be the IKEv2 Server. The
protocol we specify simply delivers the key material to the Diameter Client.
Nothing else. We also allow the HAAA the benefit of using the freshness
elements that became available from the IKEv2 layer. But it is entirely up-to
the HAAA how these elements, namely Ni and Nr, are used, although we provide
the hint as a RECOMMENDATION.
I would concur that, if this draft was being produced in conjunction with, or
normatively references other drafts that describe the relationship between the
IKEv2 peer and the HAAA, then it would make sense to defer this to them. But if
you want an arbitrary IKEv2 peer to be able to interop with an arbitrary IKEv2
server/HAAA pair, then this sort of thing needs to be defined _somewhere_.
[SBM] Ben, assumption of our draft is that the pair is IKEv2
Peer and HAAA. The IKEv2 Server is a contacted intermediary. The IKEv2 Peer and
IKEv2 Server in our assumption very rarely have relations. The Server is
discovered and contacted for resources. The HAAA should have business relations
with HAAA for at least accepting and trusting Authorization, but
subscription-based relationship is still between the IKEv2 Peer and HAAA.
> Use of a MUST in the draft that does not specify the end-point affected by
this MUST is entirely incorrect.
I recognize that this draft can't specify the IKEv2 peer behavior, so maybe it
can't solve the problem by itself. Is it defined _normatively_ somewhere else?
> Now, allow me to examine your assumption that the Client and HAAA somehow
may use different rules for choosing or creating the PSK:
> The Client is surely known to the HAAA, otherwise we would have to assume
that there is no prior relations between them (no shared secret) and therefore
the PSK scheme can't work by definition. For instance, this could happen if the
IKEv2 Server can not resolve the IDi reported by the IKEv2 Peer into a correct
User Identity, and therefore can not associate it with specific proper Diameter
Server. In such case, the default AAA will be accessed, and due to the lack of
a common shared secret a failure is the only possible result. Any attempt of
negotiations will also fail.
> On the other hand, if the IDi is resolvable, and the proper HAAA is
located, than it is obvious that HAAA surely knows about this Client with
proper subscription and has the shared key with it. It obviously knows also
which PSK computation procedure is pre-configured in the Client, so no
negotiations are necessary either.
> But my point is: all these procedures and assumptions are completely and
totally outside of scope of the draft which simply describes DELIVERY of the
already computed PSK from the Diameter Server to the Diameter Client.
You are conflating administrative relationships with implementation
relationships. If the IKEv2 client _implementation_ does not share a key
generation mechanism with the HAAA, then no amount of prior relationships and
configuration are going to make them work together. Basically, you get a high
chance that an IKE client from Vendor A cannot, under any circumstances,
interoperate with a peer that depends on an HAAA from Vendor B.
[SBM] Allow me to disagree. Case in point is the
subscription relations between mobile-based credentials and authentication
functions and the HSS-based same. The authentication cryptographic functions (Comp128,
Milenage, Sha1, etc.) are agreed to between the UICC/USIM/SIM/UIM placed in the
mobile, and the HLR/HSS. One operator may use Comp128, another –
Milenage, etc., and it would still be irrelevant because in any case the USIM
will provide the session-specific computed CK/IK or Kasme, and the same will be
provided by the HSS. Similar solution is in 3GPP2 MIPv6 standard, where the
MN-HA is computed from the EMSK derived from the prior EAP authentication. In
other words, derivation of the IKEv2 PSK is done by EXTERNAL APPLICATION which
has nothing to do with either IKEv2 or Diameter. The resulting computed key is
PROVIDED to the IKEv2 application. This is what RFC5996 expects, and this is
what we specify in this draft, for the Diameter side.
Why don’t we specify it for the client side too? Because
the reference point on the client side is not defined. The IKEv2 Peer and
external client which supplies the PSK to it are likely co-located, and not
externally standardized. While the IKEv2 Server and HAAA are very likely
dislocated and the reference point between them uses Diameter protocol to
communicate. We focus on this reference point.
> Yes, we specify the default PSK computation procedure in this draft on
insistence of reviewers. It is specified for those external applications which
do not specify their own, so "here is the right way to do it". But it
is entirely up-to the external application how to use it, configure it, benefit
from it, or even ignore it.
Can you remind me again what you mean by "external application"? From
most of the draft, I assume the external application is "IKEv2-PSK".
Are we talking about something along the lines of a 3GPP named interface, where
implementations for that context would not be expected to work with
implementations from some other context?
[SBM] No, this is not correct. The external application has
nothing to do with IKEv2. It supplies the key material. How it obtains it –
is outside the scope of this draft. We provide one default example of how to
obtain it. The key material is supplied to the IKEv2-PSK application as the PSK
expected according to the RFC5996. We hope to make it clear in the draft. If
you think we need to clarify it more, please let us know which wording causes
confusion.
Thank you very much again for spending your Friday evening
thinking of us :)
Simon
> Simon.
>
>
>
>
> Semyon (Simon) MIZIKOVSKY
> 600 Mountain Avenue
> ALCATEL-LUCENT
> DIRECTOR
> WIRELESS SECURITY STANDARDS
> 600/700 Mountain Ave.,
Rm. 3C-506
> Murray Hill, NJ 07974-0636
USA
> T: +1 908 582 0729
> M: +1 732 239 7533
> F: +1 908 743 4361
> Simon.Mizikovsky@xxxxxxxxxxxxxxxxxx
>
> Note: This message, and any attachments, is intended only for the
recipient(s) identified above. The information contained in this message
may be privileged, confidential or proprietary, and its use or disclosure by
other than intended recipient(s) is prohibited and may be unlawful. If
you have received this message in error, please delete it, and do not
distribute or retain a copy of it.
> -----Original Message-----
> From: Ben Campbell [mailto:ben@xxxxxxxxxxx]
> Sent: Friday, August 26, 2011 5:41 PM
> To: draft-ietf-dime-ikev2-psk-diameter.all@xxxxxxxxxxxxxx
> Cc: gen-art@xxxxxxxx Review Team; The IETF
> Subject: Followup on Gen-ART Telechat Review of
> draft-ietf-dime-ikev2-psk-diameter-08
>
> This is a followup on my previous gen-art reviews of
draft-ietf-dime-ikev2-psk-diameter based on version 09. I realize that came out
a couple of weeks ago, and this followup may be overtaken by events. I am
sending it anyway on the off chance it's still meaningful.
>
> This version partially addresses my concerns (below), in that it now
specifies a default mechanism for PSK generation. If I understand correctly,
use of this mechanism is completely optional. That is, the actual mechanism
chosen is still a matter of out-of-band agreement between the HAAA and the
IKEv2 peer. And if I read correctly, there is still no way for either to
declare or negotiate what mechanism they plan to use.
>
> I realize the draft assumes that this will be used in the context of a
"protocol leveraging this diameter application", and that said
protocol should specify the key derivation mechanism to be used. I interpret
(perhaps incorrectly) to mean that a given IKEv2 peer and a given HAAA are
expected to be implemented for a particular context, and that the authors do
not expect an IKEv2 peer from one context to work with an HAAA from another.
Furthermore, it appears to me that if 2 such mismatched peers tried to
communicate, the only way they could determine they were incompatible would be
through authentication failures due to a key mismatch. I'm not sure that's an
appropriate assumption for an IETF proposed standard.
>
> Ideally, I think things would be improved if the included key
derivation procedure was promoted to MUST implement, and a mechanism were added
where the peers can declare or negotiate the intent to use some other procedure
if they choose to do so. At the minimum, it would be good to have a way where
two peers could detect a key derivation mismatch early in the process.
>
>
> On Jun 17, 2011, at 5:10 PM, Ben Campbell wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at <
>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Please wait for direction from your document shepherd or AD before
>> posting a new version of the draft.
>>
>> Document: draft-ietf-dime-ikev2-psk-diameter-08
>> Reviewer: Ben Campbell
>> Review Date: 2011-06-17
>> IESG Telechat date: 2011-06-23
>>
>> Summary: This draft is almost ready for publication as a proposed
standard. I still have a concern about the generation of the PSK.
>>
>> Major issues:
>>
>> In my initial Gen-ART review, I made the following comment: The draft
says that the procedure that the HAAA follows to generate the PSK is out of
scope. But doesn't the IKE2 initiator need to understand the procedure? If the
procedure is not defined somewhere, how you achieve any degree of interoperability?
>>
>> The author responded that the PSK generation was in fact important for
interoperability, but that the specific procedures have been intentionally left
to other specifications. It is up to specifications that use this Diameter
application to define the PSK generation mechanism. Further, the author
indicated 2 3GPP2 specs that have done this.
>>
>> I am still concerned that this means that this specification cannot be
implemented in an interoperable way without effectively profiling it. There is
no apparent coordination on how such profiling may be done, and by whom. I
think this is likely to result in implementation islands that can't talk to
each other. I recognize that there is precedent for doing this, but I think it
is something that should not be done without careful consideration,
particularly in a standards track RFC. I leave it to the IESG to confirm
whether it is appropriate in this circumstance.
>>
>> I further note that there is no apparent way to negotiate or
declare what PSK generation mechanism might be used, if an implementation
supports more than one.
>>
>> Minor Issues: None
>> Editorial Comments: None
>>
>>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art