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