Subject: [Gen-art] Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Jun 2011 15:09:47 -0500

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 resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-dime-ikev2-psk-diameter-07
Reviewer: Ben Campbell
Review Date: 2011-06-03
IETF LC End Date: 2011-06-03

Summary:

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.

Major issues:

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?

Minor issues:

-- section 4.1, 1st paragraph:"The IDi payload extracted from the IKE_AUTH message MUST contain an identity that is meaningful for the Diameter infrastructure, such as a Network Access Identifier (NAI), since it is used by the IKEv2 Server to populate the User-Name AVP in the Diameter message. "

Do you mean that as a normative MUST, or a statement of fact? If normative, isn't that a requirement on the initiator?

-- 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? 

-- 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?

-- 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.

Nits/editorial comments:

-- IDNits reports an out-of-date reference

-- Section 1, general:

It's probably worth elaborating that we are talking about a PSK used during the IKEv2 authentication process, which is distinct from any shared secrets negotiated by IKE for use in the resulting SA.

-- Section 1, paragraph 1, 1st sentence:

The use, and lack of, commas in this sentence is confusing. It's easy to parse as saying IKE2 is a protocol and a set of algorithms, when I think you meant to say that the resulting SA has a set of algorithms along with the shared secret.

-- section 4.1, 2nd paragraph: "message is routed to the IKEv2 Peer’s HAAA."

What routes it? ( be careful not to let passive voice obscure responsibilities)

-- section 4.2, paragraph 1: "The HAAA may maintain state or may be stateless"

What kind of state? I assume from the following sentences you mean Diameter session state, but it should be explicit.

-- "indicated by presence or absence of the Auth-Session-State AVP."

In what message(s)?

-- section 4.2, paragraph 2:

This sentence is long and hard to parse. Can it be broken up?

-- section 5.1, last paragraph: "SHALL be used to identify the appropriate PSK."

Shall be used by what? (passive voice obscures responsibility)

-- 5.2, last paragraph: "associated key SHALL NOT be used if the lifetime has expired."

SHALL NOT be used by what?

-- section 8, first paragraph: "whether the AVP MAY be encrypted."

I don't see anything about encryption in the table.

-- section 8, AVP table:

Are all the Key* AVPs intended to have the same code? I assume not, but mixing in TBD with the various TBD* placeholders is confusing.

-- section 9:

Consider a note to the RFC editor to change all occurances of TBD(x) with the IANA assignment throughout the entire document. Since these are scattered throughout the doc, the intent may not be obvious to them.

---

From: "Cakulev, Violeta (Violeta)" <[email-masked]>
Date: Tue, 14 Jun 2011 14:11:08 -0500

Ben,
Thanks for the comments.
Please see inline [VC].

-Violeta

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Friday, June 03, 2011 4:10 PM
To: [email-masked]; [email-masked] Review Team
Cc: The IETF
Subject: Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07

Summary:

Major issues:

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.

Minor issues:

Do you mean that as a normative MUST, or a statement of fact? If normative, isn't that a requirement on the initiator?
[VC] Good point. It is changed to statement of fact in v8.

-- 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 reflect this.

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.

Actually, the spec requires it using a normative SHALL.
[VC] In v8 it is aligned as 'recommended' throughout the document.

Nits/editorial comments:

-- IDNits reports an out-of-date reference
[VC] I missed this one in v8. This will be fixed in v9.

-- Section 1, general:

It's probably worth elaborating that we are talking about a PSK used during the IKEv2 authentication process, which is distinct from any shared secrets negotiated by IKE for use in the resulting SA.
[VC] In v8 there are statements clarifying that it is a PSK used for IKEv2 authentication.

The use, and lack of, commas in this sentence is confusing. It's easy to parse as saying IKE2 is a protocol and a set of algorithms, when I think you meant to say that the resulting SA has a set of algorithms along with the shared secret.
[VC] Changed in v8 to 'The Internet Key Exchange version 2 (IKEv2) protocol [RFC5996] is
   used to mutually authenticate two parities and to establish a
   security association (SA) that can be used to efficiently secure the
   communication between the IKEv2 Peer and Server, for example, using
   Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
   Header (AH) [RFC4302].'

-- section 4.1, 2nd paragraph: "message is routed to the IKEv2 Peer's HAAA."

What routes it? ( be careful not to let passive voice obscure responsibilities)
[VC] Changed in v8 to 'The IKEv2 Server sends the IKEv2-PSK-Request message to the IKEv2
   Peer's HAAA.'

What kind of state? I assume from the following sentences you mean Diameter session state, but it should be explicit.
[VC] Changed in v8 to 'The HAAA may maintain Diameter session state or may be stateless.'

In what message(s)?
[VC] This is clarified by adding that it is the Answer message.

This sentence is long and hard to parse. Can it be broken up?
[VC] Based on some other comments this sentence is removed.

Shall be used by what? (passive voice obscures responsibility)
[VC] Changed in v8 to 'If
   included, it contains the Security Parameter Index (SPI) that HAAA
   SHALL use to identify the appropriate PSK.'

SHALL NOT be used by what?
[VC] In v8 changed to: 'The Key-Lifetime AVP may be
   included and if it is included then the associated key SHALL NOT be
   used by the receiver of the answer if the lifetime has expired.'

I don't see anything about encryption in the table.
[VC] The text referring to encryption is deleted.

-- section 8, AVP table:

Are all the Key* AVPs intended to have the same code? I assume not, but mixing in TBD with the various TBD* placeholders is confusing.
[VC] These AVPs are being defined in another ietf draft that has not been published yet. There is Note 1 clarifying it.

-- section 9:

[VC] We will do that.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Jun 2011 11:01:54 -0500

Thanks for the response. Comments inline. I deleted sections that appear not to need further discussion.

Thanks!

Ben.

> [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…

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 negotiation mechanism?

> Minor issues:

[...]

> 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…

Thanks, that probably helps (pending seeing the actual text).

> [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 i…

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.

> [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 "RECOMMENDED"?)

> Nits/editorial comments:

[...]

> [VC] The text referring to encryption is deleted.

So how does an implementor know if it can be encrypted?

[...]

---

From: Avi Lior <[email-masked]>
Date: Wed, 15 Jun 2011 14:00:00 -0400

Hi Ben,

Please see inline...

-- Avi Lior
--Bridgewater Systems

>>eview 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.
>> 
>> 
>> Major issues:
>> 
>> 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 negotiation mechanism?

I agree with your comments in general. What we need to keep in mind though
is the intent of this draft, which is to deliver the PSK key to the IKEv2
server.  The issues you discuss relating to PSK are issues that are there
with or without this document.  The document uses all the information that
is available in IKEv2 to fetch that PSK and to allow a PSK to be derived
(via the nonces).  

>[...]
>
>> 
>> -- 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.

I may be okay with using stronger terms (SHOULD or RECOMMEND).  I actually
wish now that this entire paragraph be deleted. The reason being is that
the security issues relating to multi-hop Diameter communication is well
understood and documented in 3588 (and we already make a reference to that
document).  I don't see a need for recommendation.

[...]

>So how does an implementor know if it can be encrypted?

We used an old style of table which is not really used.  There is no end
to end encryption mechanisms in Diameter.  And Diameter provides transport
level security (integrity and privacy protection).  If the end to end
encryption that is between the Diameter Client (IKEv2 Server) and the
Diameter Server (where the PSK is stored/generated) is needed it would
have to be built on-top of this document - so the implementor will know.