| Network Working Group | A. Yegin |
| Internet-Draft | Samsung |
| Intended status: Standards Track | R. Cragie |
| Expires: January 04, 2013 | Gridmerge Ltd. |
| July 5, 2012 |
Encrypting PANA AVPs
draft-yegin-pana-encr-avp-03
This document specifies a mechanism for delivering PANA (Protocol for Carrying Authentication for Network Access) AVPs (Attribute-Value Pairs) in encrypted form.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 04, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
PANA [RFC5191] is a UDP-based protocol to perform EAP authentication between a PaC (PANA Client) and a PAA (PANA Authentication Agent).
Various types of payloads are exchanged as part of the network access authentication and authorization. These payloads are carried in AVPs. AVPs can be integrity-protected using the AUTH AVP when EAP authentication generates cryptographic keying material. PANA AVPs are transmitted in the clear (i.e., not encrypted).
There are certain types of payloads that need to be delivered privately (e.g., network keys, private identifiers, etc.). This document defines a mechanism for applying encryption to selected AVPs.
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Encr-Encap AVP is used for delivering AVPs in encrypted form.
Each AVP that requires encryption SHALL be encapsulated inside an Encr-Encap AVP. Encr-Encap AVP can encapsulate one or more AVPs. There SHALL be only one Encr-Encap AVP in a PANA message.
Encr-Encap AVP uses the PANA_ENCR_KEY and the encryption algorithm negotiated by the Encr-Algorithm AVP. These AVPs SHALL NOT be used if the EAP method does not generate cryptographic keys (more specifically, MSK).
When encryption needs to be used, the required algorithm is negotiated as follows: the PAA SHALL send the initial PANA-Auth-Request carrying one or more Encryption-Algorithm AVPs supported by it. The PaC SHALL select one of the algorithms from this AVP, and it SHALL respond with the initial PANA-Auth-Answer carrying one Encryption-Algorithm AVP for the selected algorithm.
Encr-Encap AVP MAY be used in any PANA message once the encryption algorithm is successfully negotiated and the PANA_ENCR_KEY is generated. The PRF used for computing the PANA_ENCR_KEY SHALL be negotiated by the PRF-Algorithm-AVP according to RFC 5191.
PANA_ENCR_KEY is used for encrypting the AVP payload of the Encr-Encap AVP. PANA_ENCR_KEY SHALL be computed according to the following formula.
PANA_ENCR_KEY = prf+(MSK, "IETF PANA Encryption Key" | I_PAR |
I_PAN | PaC_nonce | PAA_nonce | Key_ID)
where:
The length of PANA_ENCR_KEY depends on the encryption algorithm in use.
The Encryption-Algorithm AVP (AVP Code 12 ** needs IANA allocation **) is used for conveying the encryption algorithm to be used with the Encr-Encap AVP. The AVP data is of type Unsigned32.
Only AES128_CTR (code 1) is identified by this document. Algorithm codes other than 1 are reserved for future use. Future specifications are allowed to extend this list.
n = 12,
q = 3
Key-Id = 0x55667788,
Session ID = 0xaabbccdd,
Sequence Number = 0x11223344
0x0255667788aabbccdd11223344000001
In the absence of an application profile specifying otherwise, all implementations SHALL support AES128_CTR.
The Encr-Encap AVP (AVP Code 13 ** needs IANA allocation **) is used to encrypt one or more PANA AVPs. Format of the Encr-Encap AVP depends on the negotiated encryption algorithm.
When the negotiated encryption algorithm is AES128_CTR (code 1), AVP data payload is occupied by the encrypted AVPs.
The specification of any AVP SHOULD state that the AVP either shall or shall not be encrypted using Encr-Encap AVP. The specification of an AVP MAY state that the AVP may (or may not) be encrypted using Encr-Encap AVP. The specification SHOULD use a table in the format specified in Section 6.1. If the specification of an AVP is silent about whether the AVP shall or shall not be encrypted using Encr-Encap AVP, this implies that the AVP MAY be encrypted using Encr-Encap AVP.
This section defines a table format for the specification of whether an AVP shall or shall not be encrypted using Encr-Encap AVP.
The table uses the following symbols:
The following table shows the encryption requirements for the existing AVPs defined in [RFC5191]:
Attribute Name |Enc|
----------------------+---+
AUTH | N |
EAP-Payload | X |
Integrity-Algorithm | N |
Key-Id | N |
Nonce | X |
PRF-Algorithm | N |
Result-Code | N |
Session-Lifetime | X |
Termination-Cause | X |
----------------------+---+
The following table shows the encryption requirements for the AVPs defined in this document:
Attribute Name |Enc|
----------------------+---+
Encr-Algorithm | N |
Encr-Encap | N |
----------------------+---+
The following table is an example of showing the encryption requirements for a newly-defined AVP, Example-AVP:
Attribute Name |Enc|
----------------------+---+
Example-AVP | Y |
----------------------+---+
PANA_ENCR_KEY is a secret key shared between the PaC and the PAA. It SHALL NOT be used for purposes other than the one specified in this document. Compromise of this key would lead to compromise of the secret information protected by this key.
The following IANA actions are required by this specification:
The authors would like to thank Yoshihiro Ohba and Yasuyuki Tanaka for their valuable comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5191] | Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. |
| [RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
| [NIST_SP800_38A] | Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", December 2001. |
| [NIST_SP800_38C] | Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", May 2004. |