Last Call Review of draft-yegin-pana-encr-avp-
review-yegin-pana-encr-avp-secdir-lc-sheffer-2012-07-19-00

Request Review of draft-yegin-pana-encr-avp
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-08-02
Requested 2012-07-13
Draft last updated 2012-07-19
Completed reviews Genart Last Call review of -?? by Brian Carpenter
Genart Last Call review of -?? by Brian Carpenter
Secdir Last Call review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer
State Completed
Review review-yegin-pana-encr-avp-secdir-lc-sheffer-2012-07-19
Review result Ready with Issues
Review completed: 2012-07-19

Review
review-yegin-pana-encr-avp-secdir-lc-sheffer-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.




Summary

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.

Details

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.




Thanks,
     Yaron