Network Working Group A. Yegin
Internet-Draft Samsung
Intended status: Standards Track R. Cragie
Expires: February 3, 2013 Gridmerge Ltd.
August 02, 2012
Encrypting PANA AVPs
draft-yegin-pana-encr-avp-04
Abstract
This document specifies a mechanism for delivering PANA (Protocol for
Carrying Authentication for Network Access) AVPs (Attribute-Value
Pairs) in encrypted form.
Status of this Memo
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 February 3, 2013.
Copyright Notice
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.
Yegin & Cragie Expires February 3, 2013 [Page 1]
Internet-Draft PANA AVP Encryption August 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Encryption-Algorithm AVP . . . . . . . . . . . . . . . . . . . 4
5. Encr-Encap AVP . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Encryption Policy . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Encryption Policy Specification . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Yegin & Cragie Expires February 3, 2013 [Page 2]
Internet-Draft PANA AVP Encryption August 2012
1. Introduction
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.
1.1. Specification of Requirements
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].
2. Details
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
Yegin & Cragie Expires February 3, 2013 [Page 3]
Internet-Draft PANA AVP Encryption August 2012
negotiated by the PRF-Algorithm-AVP according to RFC 5191.
3. Encryption Key
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 prf+ function is defined in IKEv2 [RFC5996]. The pseudo-
random function to be used for the prf+ function is negotiated
using PRF-Algorithm AVP in the initial PANA-Auth-Request and PANA-
Auth-Answer exchange with 'S' (Start) bit set.
- MSK is the master session key generated by the EAP method.
- "IETF PANA Encryption Key" is the ASCII code representation of
the non-NULL terminated string (excluding the double quotes around
it).
- I_PAR and I_PAN are the initial PANA-Auth-Request and PANA-Auth-
Answer messages (the PANA header and the following PANA AVPs) with
'S' (Start) bit set, respectively.
- PaC_nonce and PAA_nonce are values of the Nonce AVP carried in
the first non-initial PANA-Auth-Answer and PANA-Auth-Request
messages in the authentication and authorization phase or the
first PANA-Auth-Answer and PANA-Auth-Request messages in the re-
authentication phase, respectively.
- Key_ID is the value of the Key-Id AVP.
The length of PANA_ENCR_KEY depends on the encryption algorithm in
use.
4. Encryption-Algorithm AVP
The Encryption-Algorithm AVP (AVP Code TBD1) is used for conveying
the encryption algorithm to be used with the Encr-Encap AVP. The AVP
data is of type Unsigned32.
Yegin & Cragie Expires February 3, 2013 [Page 4]
Internet-Draft PANA AVP Encryption August 2012
Only encryption algorithm identifier AES128_CTR (code 1) is
identified by this document. Encryption algorithm identifier codes
other than 1 are reserved for future use. Future specifications are
allowed to extend this list.
AES128_CTR: 1
AES-CTR (Counter) encryption algorithm as specified in
[NIST_SP800_38A] using AES-128 block cipher. The formatting
function and counter generation function as specified in Appendix
A of [NIST_SP800_38C] are used, with the following parameters:
n = 12,
q = 3
The 12-octet nonce consists of a 4-octet Key-Id, a 4-octet Session
ID and a 4-octet Sequence Number in that order where each 4-octet
value is encoded in network byte order. The Session ID and
Sequence Number values SHALL be the same as those in the PANA
message carrying the key Encr-Encap AVP. The Key-Id value SHALL
be the same as the one used for deriving the PANA_ENCR_KEY. The
output blocks of the encryption processing are encoded as
OctetString data in the Value field of a Encr-Encap AVP.
Note the first counter block used for encryption is Ctr_1, where
"_1" denotes "subscript 1". For example, given the following:
Key-Id = 0x55667788,
Session ID = 0xaabbccdd,
Sequence Number = 0x11223344
The first counter block used for encryption will be:
0x0255667788aabbccdd11223344000001
In the absence of an application profile specifying otherwise, all
implementations SHALL support AES128_CTR.
5. Encr-Encap AVP
The Encr-Encap AVP (AVP Code TBD2) is used to encrypt one or more
Yegin & Cragie Expires February 3, 2013 [Page 5]
Internet-Draft PANA AVP Encryption August 2012
PANA AVPs. Format of the Encr-Encap AVP depends on the negotiated
encryption algorithm.
When the negotiated encryption algorithm identifier is AES128_CTR
(code 1), AVP data payload is occupied by the encrypted AVPs.
6. Encryption Policy
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.
6.1. Encryption Policy Specification
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:
Y: The AVP SHALL be encrypted using Encr-Encap AVP. If the AVP is
encountered not encrypted using Encr-Encap AVP, it SHALL be
considered invalid and the message containing the AVP SHALL be
discarded.
N: The AVP SHALL NOT be encrypted using Encr-Encap AVP. If the AVP
is encountered encrypted using Encr-Encap AVP, it SHALL be
considered invalid and the message containing the AVP SHALL be
discarded.
X: The AVP MAY be encrypted using Encr-Encap AVP. If the AVP is
encountered either encrypted or not encrypted using Encr-Encap
AVP, it SHALL be considered valid.
The following table shows the encryption requirements for the
existing AVPs defined in [RFC5191]:
Yegin & Cragie Expires February 3, 2013 [Page 6]
Internet-Draft PANA AVP Encryption August 2012
Attribute Name |Enc|
----------------------+---+
AUTH | N |
EAP-Payload | X |
Integrity-Algorithm | N |
Key-Id | N |
Nonce | N |
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 |
----------------------+---+
7. Security Considerations
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.
8. IANA Considerations
The following IANA actions are required by this specification:
Yegin & Cragie Expires February 3, 2013 [Page 7]
Internet-Draft PANA AVP Encryption August 2012
- Assignment of a standard PANA AVP code TBD1 (suggested value 12)
for Encr-Encap AVP.
- Assignment of a standard PANA AVP code TBD2 (suggested value 13)
for Encryption-Algorithm AVP.
- Creation of the PANA encryption algorithm identifier space.
- Assignment of an encryption algorithm identifier code 1 for
AES128_CTR in the PANA encryption algorithm identifier space.
9. Acknowledgments
The authors would like to thank Yoshihiro Ohba and Yasuyuki Tanaka
for their valuable comments.
10. Normative References
[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.
[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.
Yegin & Cragie Expires February 3, 2013 [Page 8]
Internet-Draft PANA AVP Encryption August 2012
Authors' Addresses
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@yegin.org
Robert Cragie
Gridmerge Ltd.
89 Greenfield Crescent
Wakefield, WF4 4WA
UK
Email: robert.cragie@gridmerge.com
Yegin & Cragie Expires February 3, 2013 [Page 9]