ietf
[Top] [All Lists]

Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07

2011-06-06 12:00:05
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.


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>