RFC 6786

Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs

📅 published November 2012, from ietf

Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs 🎀

RFC 6786 🦋 Authors: A. Yegin (Samsung) and R. Cragie (Gridmerge Ltd.) 💖 Category: Standards Track ✨ ISSN: 2070-1721 Date: November 2012 🌸 Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈

Abstract ✨

okay so this doc is all about making PANA AVPs (the little attribute-value chunks that carry network-access authentication stuff) get delivered in encrypted form instead of just floating around in the clear 🔐 it's giving privacy, bestie 💅

Status of This Memo 📜

This is an Internet Standards Track document. 🔥

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 💜

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6786. 🧚

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. 📚

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Specification of Requirements ..............................2
2. Details .........................................................3
3. Encryption Keys .................................................3
4. Encryption-Algorithm AVP ........................................4
   4.1. AES128_CTR Encryption Algorithm ............................5
5. Encryption-Encap AVP ............................................6
6. Encryption Policy ...............................................6
   6.1. Encryption Policy Specification ............................7
7. Security Considerations .........................................8
   7.1. AES-CTR Security Considerations ............................9
8. IANA Considerations .............................................9
   8.1. PANA AVP Codes .............................................9
   8.2. PANA Encryption-Algorithm AVP Values .......................9
   8.3. PANA AVP Codes Encryption Policy ..........................10
9. Acknowledgments ................................................10
10. Normative References ..........................................10

1. Introduction 🌸

okay so PANA [RFC5191] is a UDP-based protocol that runs an Extensible Authentication Protocol (EAP) authentication between a PANA Client (PaC) and a PANA Authentication Agent (PAA) 🦋

Different kinds of payload get swapped during network access authentication and authorization, and they travel inside PANA Attribute-Value Pairs (AVPs) ✨ AVPs can be integrity protected with the AUTH AVP when EAP authentication makes cryptographic keying material. BUT, and this is the tea, AVPs are sent in the clear (aka not encrypted) 🫣

Some payloads really need to stay private, like network keys, private identifiers, and similar stuff 🔑 So this document defines a mechanism for applying encryption to selected AVPs. It's giving main character energy 👑

1.1. Specification of Requirements 📏

Okay so here's the rule-book bit: this document uses several words to signal the requirements of the spec, and they're 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 🔍

This document extends the AVP set defined in Section 8 of [RFC5191] by adding two new AVPs: the Encryption-Algorithm AVP (see Section 4) and the Encryption-Encap AVP (see Section 5). Two new encryption keys, PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY, are also defined. They encrypt AVPs going from the PaC to the PAA and AVPs going from the PAA to the PaC, respectively (see Section 3). 🧚

When encryption is needed, the algorithm gets negotiated like this 🤝 The PAA SHALL send the initial PANA-Auth-Request carrying one or more Encryption-Algorithm AVPs that it supports. 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. Once PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY have been generated, a PANA message MAY contain an Encryption-Encap AVP. ✨

3. Encryption Keys 🔑

PANA_PAC_ENCR_KEY is used for encrypting the AVP payload of the Encryption-Encap AVP sent in a PANA message from the PaC to the PAA. 💖

PANA_PAC_ENCR_KEY SHALL be computed according to the following formula:

PANA_PAC_ENCR_KEY = prf+(MSK, "IETF PANA PaC Encr" | I_PAR |
                      I_PAN | PaC_nonce | PAA_nonce | Key_ID)

PANA_PAA_ENCR_KEY is used for encrypting the AVP payload of the Encryption-Encap AVP sent in a PANA message from the PAA to the PaC. PANA_PAA_ENCR_KEY SHALL be computed according to the following formula:

PANA_PAA_ENCR_KEY = prf+(MSK, "IETF PANA PAA Encr" | I_PAR |
                      I_PAN | PaC_nonce | PAA_nonce | Key_ID)

In both cases:

  • The prf+ function is defined in the Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996]. 📐
  • The pseudo-random function (PRF) to be used for the prf+ function SHALL be negotiated using the PRF-Algorithm AVP in the initial PANA-Auth-Request and PANA-Auth-Answer exchange with the 'S' (Start) bit set, as described in Section 4.1 of [RFC5191]. 🤓
  • MSK is the master session key (MSK) generated by the EAP method [RFC3748]. PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY MUST be recalculated whenever a new MSK is generated by the EAP method. 🔄
  • "IETF PANA PaC Encr" and "IETF PANA PAA Encr" are the ASCII code representations of the respective non-NULL terminated strings (excluding the double quotes around them). 🔤
  • 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 the '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_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY depends on the encryption algorithm in use. 📏

4. Encryption-Algorithm AVP 🧩

The Encryption-Algorithm AVP (AVP code 13) is used for conveying the encryption algorithm to be used with the Encryption-Encap AVP. The AVP value data is of type Unsigned32. 🔢

Only one encryption algorithm identifier, AES128_CTR (code 1), is identified by this document. Encryption algorithm identifier values other than 1 are reserved for future use. Future specifications are allowed to extend this list. 🔮

AES128_CTR: 1

In the absence of an application profile specifying otherwise, all implementations SHALL support AES128_CTR. 🫡

4.1. AES128_CTR Encryption Algorithm 🔐

The AES128_CTR encryption algorithm uses the AES-CTR (Counter) mode of operation as specified in [NIST_SP800_38A], using the 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 Encryption-Encap AVP. The Key-Id value SHALL be the same as the one used for deriving PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY. The output blocks of the encryption processing are encoded as OctetString data in the Value field of an Encryption-Encap AVP. 🧁

Note that the first counter block used for encryption is Ctr_1, where "_1" denotes "subscript 1" as described in Appendix A.3 of [NIST_SP800_38C]. For example, given the following:

Key-Id = 0x55667788,
Session ID = 0xaabbccdd,
Sequence Number = 0x11223344

The first counter block used for encryption will be:

0x0255667788aabbccdd11223344000001

where the initial 0x02 represents the Flags field of the counter block. 🎯

The nonce meets the requirement of uniqueness-per-key usage provided that the sequence number does not wrap. So, for the purpose of generating new keys:

  • If Encryption-Encap AVPs are being sent from the PaC to the PAA and the sequence number is about to wrap, the PaC SHALL initiate PANA re-authentication as described in Section 4.3 of [RFC5191]. 🚨
  • If Encryption-Encap AVPs are being sent from the PAA to the PaC and the sequence number is about to wrap, the PAA SHALL initiate PANA re-authentication as described in Section 4.3 of [RFC5191]. 🚨

Re-authentication ensures the generation of a new MSK [RFC3748], and thus a new PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY. 🔁

5. Encryption-Encap AVP 🎁

The Encryption-Encap AVP (AVP code 12) is used to encrypt one or more PANA AVPs. Its format depends on the negotiated encryption algorithm. 🫧

When the negotiated encryption algorithm identifier is AES128_CTR (code 1), the AVP data payload is occupied by the encrypted AVPs. 🔒

There SHALL be only one Encryption-Encap AVP in a PANA message. All AVPs that require encryption SHALL be encapsulated within the Encryption-Encap AVP. 📦

The Encryption-Encap AVP uses either PANA_PAC_ENCR_KEY or PANA_PAA_ENCR_KEY, along with the encryption algorithm negotiated by the Encryption-Algorithm AVP. The Encryption-Encap AVP SHALL only be used if the EAP method generates cryptographic keys (specifically, the MSK [RFC3748]). 🗝️

The Encryption-Encap AVP MAY be used in a PANA message from the PaC to the PAA when the encryption algorithm has been successfully negotiated and once PANA_PAC_ENCR_KEY has been generated. 💜

The Encryption-Encap AVP MAY be used in a PANA message from the PAA to the PaC when the encryption algorithm has been successfully negotiated and once PANA_PAA_ENCR_KEY has been generated. 💜

The Encryption-Encap AVP MAY be used in the very first PANA message carrying the Result-Code AVP set to the PANA_Success value, and in any subsequent message within the same PANA session. 🥳

6. Encryption Policy 🔐

okay bestie, every AVP spec SHOULD spell out whether that AVP shall or shall not get wrapped up in the Encryption-Encap AVP 💅 A spec CAN also say the AVP MAY be encrypted, or MAY NOT be, if it's flexible. And if a spec is totally silent about it, that just means the AVP MAY be encrypted using the Encryption-Encap AVP. Main character energy for the flexible ones 🦋

The spec SHOULD use a table in the format from Section 6.1, so everyone's on the same page 📋

6.1. Encryption Policy Specification ✨

this section is where we define the table format for saying whether an AVP shall or shall not be encrypted with the Encryption-Encap AVP 🎀

The table uses three symbols:

  • Y: The AVP SHALL be encrypted using the Encryption-Encap AVP. If it shows up not encrypted with the Encryption-Encap AVP, it SHALL be considered invalid, and the message holding it SHALL be discarded. Absolutely no exceptions, it's giving strict 🚫
  • N: The AVP SHALL NOT be encrypted using the Encryption-Encap AVP. If it shows up encrypted with the Encryption-Encap AVP, it SHALL be considered invalid, and the message holding it SHALL be discarded. Keep it bare, babe 🙈
  • X: The AVP MAY be encrypted using the Encryption-Encap AVP. If it shows up either encrypted or not encrypted with the Encryption-Encap AVP, it SHALL be considered valid. Both are iconic 🌈

The legit occurrence of unencrypted AVPs, and of AVPs after decryption and unencapsulation, SHALL be checked against the AVP Occurrence Table (Figure 4 in [RFC5191]). That's the rulebook, so don't skip it 📖

Here's the encryption requirements table for the existing AVPs defined in [RFC5191]:

         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 |
         ----------------------+---+

And for the AVPs defined in [RFC6345]:

         Attribute Name        |Enc|
         ----------------------+---+
         PaC-Information       | N |
         Relayed-Message       | N |
         ----------------------+---+

And for the AVPs defined in this document:

         Attribute Name        |Enc|
         ----------------------+---+
         Encryption-Algorithm  | N |
         Encryption-Encap      | N |
         ----------------------+---+

Here's an example table showing the encryption requirements for a newly defined AVP, Example-AVP:

         Attribute Name        |Enc|
         ----------------------+---+
         Example-AVP           | Y |
         ----------------------+---+

Okay, so if you're defining a brand-new AVP, here's how to pick its encryption vibe 🧚

  • Y: If the payload needs privacy against eavesdroppers (e.g., carrying a secret key). Secrets stay secret 🤫
  • N: If the payload may need to be observed by on-path network elements (i.e., subject to deep packet inspection). Let the middle boxes peek 👀
  • X: If neither concern applies. Easy mode 💜

7. Security Considerations 🚨

okay this part is SERIOUS bestie 😭 PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY are secret keys shared between the PaC and the PAA. They SHALL NOT be used for anything other than what this document specifies. If these keys get compromised, the secret info they protect gets compromised too. Guard them like your ex's passwords 🔒💀

7.1. AES-CTR Security Considerations 🎀

AES-CTR encryption has its own security considerations, and they're detailed in the Security Considerations section of [RFC3686]. The big ones:

  • The nonce specified in Section 4.1 meets the requirement of uniqueness-per-key usage. Unique nonce per key, no repeats, we love a clean record 💅
  • Section 4.1 of [RFC5191] says that if the EAP method generates cryptographic keys, an AUTH AVP will always be present in every PANA message after key generation. So an Encryption-Encap AVP will always be sent alongside an AUTH AVP. That covers the requirement of a companion authentication function 🫶

8. IANA Considerations 📚

so as described in Sections 4 and 5, and following the IANA allocation policy on PANA messages [RFC5872], two PANA AVP codes and one set of AVP values have been registered. An extra encryption policy for AVP codes has been registered too. The registry glow-up is real ✨

8.1. PANA AVP Codes 🔢

The following AVP codes have been registered in the "AVP Codes" sub-registry of the "Protocol for Carrying Authentication for Network Access (PANA) Parameters" registry:

  • A standard AVP code of 12 for the Encryption-Encap AVP. 🧁
  • A standard AVP code of 13 for the Encryption-Algorithm AVP. 🍓

8.2. PANA Encryption-Algorithm AVP Values 🌸

The following AVP values, representing the encryption algorithm identifier for the Encryption-Algorithm AVP code, have been assigned in the "Encryption-Algorithm (AVP Code 13) AVP Values" sub-registry under the "Protocol for Carrying Authentication for Network Access (PANA) Parameters" registry":

  • An AVP value of 1 for AES128_CTR. The one and only queen 👑
  • All other AVP values (0, 2-4294967295) are unassigned. Still open for business 🦋

The registration procedures are IETF Review or IESG Approval in accordance with [RFC5872]. Two ways in, both legit 🚪

8.3. PANA AVP Codes Encryption Policy 💜

The additional encryption policy defined in Section 6.1 has been added as a column labeled "Enc" in the "AVP Codes" sub-registry. It's been applied to all the existing AVP codes and the ones defined in this specification. Full coverage, no notes 🌈

9. Acknowledgments 🫶

the authors want to thank Yoshihiro Ohba, Yasuyuki Tanaka, Adrian Farrel, Brian Carpenter, Yaron Sheffer, Ralph Droms, Stephen Farrell, Barry Leiba, and Sean Turner for their valuable comments. Real ones, showing up for the people who showed up 💖

10. Normative References 📖

here are the normative references, with every detail kept exactly as the original has them:

[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.

[RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
           Counter Mode With IPsec Encapsulating Security Payload
           (ESP)", RFC 3686, January 2004.

[RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
           Levkowetz, Ed., "Extensible Authentication Protocol
           (EAP)", RFC 3748, June 2004.

[RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
           and A. Yegin, "Protocol for Carrying Authentication for
           Network Access (PANA)", RFC 5191, May 2008.

[RFC5872]  Arkko, J. and A. Yegin, "IANA Rules for the Protocol for
           Carrying Authentication for Network Access (PANA)", RFC
           5872, May 2010.

[RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
           "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
           5996, September 2010.

[RFC6345]  Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and
           A. Yegin, "Protocol for Carrying Authentication for
           Network Access (PANA) Relay Element", RFC 6345, August
           2011.

Authors' Addresses 🎀

Alper Yegin
Samsung
Istanbul
Turkey

EMail: alper.yegin@yegin.org


Robert Cragie
Gridmerge Ltd.
89 Greenfield Crescent
Wakefield, WF4 4WA
United Kingdom

EMail: robert.cragie@gridmerge.com
📦 where this page comes from