Thanks for the response. Comments inline. I deleted sections that appear not to
need further discussion.
On Jun 14, 2011, at 2:11 PM, Cakulev, Violeta (Violeta) wrote:
Thanks for the comments.
Please see inline [VC].
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: Friday, June 03, 2011 4:10 PM
gen-art(_at_)ietf(_dot_)org Review Team
Cc: The IETF
Subject: Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at
Please resolve these comments along with any other Last Call comments you may
Reviewer: Ben Campbell
Review Date: 2011-06-03
IETF LC End Date: 2011-06-03
This draft is almost ready for publication as a proposed standard. I have a
question concerning the procedure for generating PSKs, and a number of minor
and editorial comments.
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?
[VC] Indeed the IKEv2 initiator needs to understand the procedure. However,
this draft focuses on IKEv2 server, as a Diameter client, to the Diameter
server communication for IKEv2 with pre-shared key based authentication, and
specifies Diameter application for this communication. It is left to
specifications that make use of this Diameter application to specify where
the PSK comes from and how it is generated. There are two 3GPP2 specs that
make use of this Diameter application and both of those specs specify
generation of the PSK. Statements to clarify this are added in v8.
The effect of this is that this spec, as written, cannot be implemented in an
interoperable way. I don't think that meets the usual expectations for a
proposed standard. Now, I realize there are some situations where the IETF has
chosen this approach, and deliberately created a standards track RFC that must
be profiled for actual use--but hopefully that's the exception rather than the
rule. I guess it's up to the IESG to decide if that is reasonable in this
instance. (I'm explicitly not counting situations where the IETF puts out a
standard as a series of modular RFCs, since I gather there's no immediate
intent to publish PSK generation RFCs.)
Additionally, whether or not PSK generation mechanisms are specified in the
IETF vs somewhere else, how does an implementation (that might support more
than one such mechanism) know which to use for any given SA? Is there a
-- section 10:
The security considerations should describe the threat models. We're talking
about requesting an authentication key from a third party, which is tricky
from a security perspective. Does the PSK have greater security concerns than
for Diameter AVPs in general? In particular, what are the consequences if the
PSK is disclosed or tampered with?
[VC] If the PSK is disclosed to an adversary then it would present a security
breach. Hence we recommend that the PSK be short-lived. As well,
the assumption is that the IKEv2 Server and the Diameter Server where the PSK
is generated are in a trusted relationship. They may be in the same
Administrative domain (typical case) or third party but nevertheless there is
a trust relationship between them. As such we assume that there is an
appropriate security mechanism to protect the communication between these
servers. For example the IKEV2 Server and the Diameter server would be
deployed in the same secure network or would utilize transport layer security
as specified by Diameter 3588 specification. We added statements in v8 to
Thanks, that probably helps (pending seeing the actual text).
-- section 10, 1st paragraph: "Furthermore, any agents that process
IKEv2-PSK-Answer messages can see the contents of the Key AVP. For this
reason, this specification strongly recommends avoiding Diameter agents when
they cannot be trusted to keep the keys secret."
Should that be normative? Is there no way to protect the PSK AVP from
diameter agents? E.g. can it be encrypted?
[VC] It is hard to use normative text here as this application can be used
for many uses cases. Depending on the use case it may be possible to encrypt
the PSK, however it is not possible to make it a requirement.
I don't see why a "SHOULD" or "RECOMMENDED" would cause problems here, along
with some short explanation of why it might not always be possible. Otherwise,
the text says "strongly recommends", when, without normative text, such
recommendation is really pretty weak.
-- section 10, 2nd paragraph: "this specification also recommends the use of
nonces included in IKEv2-PSK-Request."
Actually, the spec requires it using a normative SHALL.
[VC] In v8 it is aligned as 'recommended' throughout the document.
I'm curious why you chose to weaken the rest of the text, vs strengthening the
comment in the security considerations? (Also, is that "recommended" or
-- section 8, first paragraph: "whether the AVP MAY be encrypted."
I don't see anything about encryption in the table.
[VC] The text referring to encryption is deleted.
So how does an implementor know if it can be encrypted?
Ietf mailing list