Skip to main content

Last Call Review of draft-yegin-pana-encr-avp-

Request Review of draft-yegin-pana-encr-avp
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-08-02
Requested 2012-07-13
Authors Alper E. Yegin , Robert Cragie
I-D last updated 2012-07-19
Completed reviews Genart Last Call review of -?? by Brian E. Carpenter
Genart Last Call review of -?? by Brian E. Carpenter
Secdir Last Call review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer
State Completed
Request Last Call review on draft-yegin-pana-encr-avp by Security Area Directorate Assigned
Result Ready w/issues
Completed 2012-07-19
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This protocol defines a new AVP that encapsulates multiple PANA AVPs 

within one message, and encrypts them. The encryption key is derived 

from EAP's MSK, and the only encryption algorithm defined is AES128-CTR.


I'm a bit worried about the quality of the proposed cryptographic
solution. While using Counter Mode as the preferred encryption mode is
completely legit, it does require some extra care.


Please note that I am neither a PANA expert nor a cryptographer.

- Sec. 2: I am not clear why MSK is used for deriving the keys, in 

preference to EMSK. I understand that one of the main differences 

between the two is that MSK is possibly shared with an Authenticator 

server (where one exists), but the EMSK is not. It would seem to me that 

a generic confidentiality mechanism should use the key that's shared 

with fewer partners.

- Sec. 2: please clarify whether Encr-Encap can already be used in the 

first message that completes negotiation of the algorithm, i.e. the 

initial PANA-Auth-Answer.

- Sec. 2: according to RFC 5191 (PANA), Sec. 5.4, the AUTH AVP is not 

mandatory (or am I missing something?) It should be made mandatory for 

messages that contain an Encr-Encap (possibly with the exception of 

authenticated encryption algorithms, but none are defined in the current 

document). Emphatically so if Counter Mode is used.

- Sec. 3: I understand why the nonces are used in the derivation. I do 

not understand why the initial messages are used - cryptographic binding 

of message contents is appropriate for authentication 

(integrity-protection) messages, but seems redundant for generation of 

confidentiality keys.

- Sec. 4: Counter Mode is infamous for being extremely sensitive to the 

quality of the IV (a.k.a. "nonce"). So I would expect a random nonce to 

be used for this purpose, rather than the concatenation of 3 protocol 

values. Specifically, what is the likelihood of these parameters 

repeating after a reboot?

- Sec. 4: please explain where the initial 02 octet of the counter block 

comes from.

- Sec. 5: The value of the Encr-Encap AVP is defined as 13 here, but is 

left open in the IANA Considerations.

- Sec. 5: I suppose there is no (block cipher) padding. Please say so 

explicitly. In fact this AVP cannot be generic if neither padding nor IV 

are catered for. In other words, it's good for Counter Mode but for 

little else.

- Sec. 6.1: the Nonce AVPs used for deriving the encryption key 

obviously cannot be encrypted.