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.
Use of a MUST in the draft that does not specify the end-point affected by this
MUST is entirely incorrect.
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.
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.
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(_dot_)Mizikovsky(_at_)alcatel-lucent(_dot_)com
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(_at_)nostrum(_dot_)com]
Sent: Friday, August 26, 2011 5:41 PM
To: draft-ietf-dime-ikev2-psk-diameter(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: gen-art(_at_)ietf(_dot_)org 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf