One document matched: draft-yegin-pana-encr-avp-03.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC5191 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml'>
<!ENTITY RFC5996 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc iprnotified="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc inline="no"?>
<rfc ipr="trust200902" category='std' docName='draft-yegin-pana-encr-avp-03'>
<front>
<title abbrev="PANA AVP Encryption">Encrypting PANA AVPs</title>
<author initials="A." surname="Yegin" fullname="Alper Yegin">
<organization>Samsung</organization>
<address>
<postal>
<street></street>
<city>Istanbul</city>
<country>Turkey</country>
</postal>
<email>alper.yegin@yegin.org</email>
</address>
</author>
<author initials="R." surname="Cragie" fullname="Robert Cragie">
<organization>Gridmerge Ltd.</organization>
<address>
<postal>
<street>89 Greenfield Crescent</street>
<city>Wakefield, WF4 4WA</city>
<country>UK</country>
</postal>
<email>robert.cragie@gridmerge.com</email>
</address>
</author>
<date day="5" month="July" year="2012"/>
<area>Internet</area>
<abstract>
<t>This document specifies a mechanism for delivering PANA (Protocol for Carrying Authentication for Network Access) AVPs (Attribute-Value Pairs) in encrypted form.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>PANA <xref target='RFC5191' /> is a UDP-based protocol to perform EAP authentication between a PaC (PANA Client) and a PAA (PANA Authentication Agent).</t>
<t>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).</t>
<t>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.</t>
<section title="Specification of Requirements">
<t>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 <xref target='RFC2119'/>.</t>
</section>
</section>
<section title="Details">
<t>Encr-Encap AVP is used for delivering AVPs in encrypted form.</t>
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Encryption Key">
<t>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.</t>
<figure>
<artwork xml:space="preserve"><![CDATA[
PANA_ENCR_KEY = prf+(MSK, "IETF PANA Encryption Key" | I_PAR |
I_PAN | PaC_nonce | PAA_nonce | Key_ID)
]]>
</artwork>
</figure>
<t>where:</t>
<t>
<list>
<t>- The prf+ function is defined in IKEv2 <xref target='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.</t>
<t>- MSK is the master session key generated by the EAP method.</t>
<t>- "IETF PANA Encryption Key" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it).</t>
<t>- 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.</t>
<t>- 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.</t>
<t>- Key_ID is the value of the Key-Id AVP.</t>
</list>
</t>
<t>The length of PANA_ENCR_KEY depends on the encryption algorithm in use.</t>
</section>
<section title='Encryption-Algorithm AVP'>
<t>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.</t>
<t>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.</t>
<t>
<list>
<t>AES128_CTR: 1</t>
</list>
</t>
<t>
<list>
<t>AES-CTR (Counter) encryption algorithm as specified in <xref target="NIST_SP800_38A"></xref> using AES-128 block cipher. The formatting function and counter generation function as specified in Appendix A of <xref target="NIST_SP800_38C"></xref> are used, with the following parameters:</t>
</list>
<figure>
<artwork xml:space="preserve"><![CDATA[
n = 12,
q = 3
]]>
</artwork>
</figure>
</t>
<t>
<list>
<t>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.</t>
</list>
<list>
<t>Note the first counter block used for encryption is Ctr_1, where "_1" denotes "subscript 1". For example, given the following:</t>
</list>
<figure>
<artwork xml:space="preserve"><![CDATA[
Key-Id = 0x55667788,
Session ID = 0xaabbccdd,
Sequence Number = 0x11223344
]]>
</artwork>
</figure>
<list>
<t>The first counter block used for encryption will be:</t>
</list>
<figure>
<artwork xml:space="preserve"><![CDATA[
0x0255667788aabbccdd11223344000001
]]>
</artwork>
</figure>
</t>
<t>In the absence of an application profile specifying otherwise, all implementations SHALL support AES128_CTR.</t>
</section>
<section title='Encr-Encap AVP'>
<t>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.</t>
<t>When the negotiated encryption algorithm is AES128_CTR (code 1), AVP data payload is occupied by the encrypted AVPs.</t>
</section>
<section title='Encryption Policy'>
<t>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 <xref target='encr_pol_spec' />. 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.</t>
<section anchor='encr_pol_spec' title='Encryption Policy Specification'>
<t>This section defines a table format for the specification of whether an AVP shall or shall not be encrypted using Encr-Encap AVP.</t>
<t>The table uses the following symbols:</t>
<t>
<list style='hanging'>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>
</t>
<t>The following table shows the encryption requirements for the existing AVPs defined in <xref target='RFC5191' />:</t>
<figure>
<artwork xml:space="preserve"><![CDATA[
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 |
----------------------+---+
]]>
</artwork>
</figure>
<t>The following table shows the encryption requirements for the AVPs defined in this document:</t>
<figure>
<artwork xml:space="preserve"><![CDATA[
Attribute Name |Enc|
----------------------+---+
Encr-Algorithm | N |
Encr-Encap | N |
----------------------+---+
]]>
</artwork>
</figure>
<t>The following table is an example of showing the encryption requirements for a newly-defined AVP, Example-AVP:</t>
<figure>
<artwork xml:space="preserve"><![CDATA[
Attribute Name |Enc|
----------------------+---+
Example-AVP | Y |
----------------------+---+
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="sec-security-considerations" title='Security Considerations'>
<t>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.</t>
</section>
<section title='IANA Considerations'>
<t>The following IANA actions are required by this specification:</t>
<t>
<list>
<t>- Assignment of a standard PANA AVP code TBD for Encr-Encap AVP.</t>
<t>- Assignment of a standard PANA AVP code TBD for Encryption-Algorithm AVP.</t>
<t>- Creation of encryption algorithm identifier space for PANA.</t>
<t>- Assignment of an encryption code 1 for AES128_CTR in the PANA encryption algorithm identifier space.</t>
</list>
</t>
</section>
<section title='Acknowledgments'>
<t>The authors would like to thank Yoshihiro Ohba and Yasuyuki Tanaka for their valuable comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5191;
&RFC5996;
<reference anchor='NIST_SP800_38A'>
<front>
<title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title>
<author initials="M." surname="Dworkin" fullname="Morris Dworkin"><organization>National Institute of Standards and Technology</organization></author>
<date year='2001' month='December' />
</front>
</reference>
<reference anchor='NIST_SP800_38C'>
<front>
<title>Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality</title>
<author initials="M." surname="Dworkin" fullname="Morris Dworkin"><organization>National Institute of Standards and Technology</organization></author>
<date year='2004' month='May' />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 18:19:19 |