Encrypting PANA AVPs: Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs
How PANA lets selected attribute-value pairs travel encrypted instead of in the clear.
Yegin, A. and R. Cragie, "Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786, November 2012, <https://www.rfc-editor.org/info/rfc6786>.
@misc{rfc6786,
series = {Request for Comments},
number = 6786,
howpublished = {RFC 6786},
publisher = {RFC Editor},
doi = {10.17487/RFC6786},
url = {https://www.rfc-editor.org/info/rfc6786},
author = {A. Yegin and R. Cragie},
title = {{Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs}},
pagetotal = 11,
year = 2012,
month = nov,
} RFC text
Contents
Internet Engineering Task Force (IETF) A. Yegin
Request for Comments: 6786 Samsung
Category: Standards Track R. Cragie
ISSN: 2070-1721 Gridmerge Ltd.
November 2012
Encrypting the Protocol for Carrying Authentication for
Network Access (PANA) Attribute-Value Pairs
Abstract
This document specifies a mechanism for delivering the Protocol for
Carrying Authentication for Network Access (PANA) Attribute-Value
Pairs (AVPs) in encrypted form.
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 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.
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
PANA [RFC5191] is a UDP-based protocol to perform an Extensible
Authentication Protocol (EAP) authentication between a PANA Client
(PaC) and a PANA Authentication Agent (PAA).
Various types of payload are exchanged as part of the network access
authentication and authorization. These payloads are carried in PANA
Attribute-Value Pairs (AVPs). AVPs can be integrity protected using
the AUTH AVP when EAP authentication generates cryptographic keying
material. AVPs are transmitted in the clear (i.e., not encrypted).
Certain payload types 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
This document extends the AVP set defined in Section 8 of [RFC5191]
by defining 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 defined to encrypt
AVPs from the PaC to the PAA and AVPs from the PAA to the PaC,
respectively (see Section 3).
When encryption is needed, 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. 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 key 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 a 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. Therefore, 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. The format of the Encryption-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.
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, and 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 PANA_Success value and any
subsequent message within the same PANA session.
6. Encryption Policy
The specification of any AVP SHOULD state that the AVP either shall
or shall not be encrypted using the Encryption-Encap AVP. The
specification of an AVP MAY state that the AVP may (or may not) be
encrypted using the Encryption-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 the Encryption-Encap AVP, this implies
that the AVP MAY be encrypted using the Encryption-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 the Encryption-Encap
AVP.
The table uses the following symbols:
Y: The AVP SHALL be encrypted using the Encryption-Encap AVP. If the
AVP is encountered not encrypted using the Encryption-Encap AVP,
it SHALL be considered invalid and the message containing the AVP
SHALL be discarded.
N: The AVP SHALL NOT be encrypted using the Encryption-Encap AVP. If
the AVP is encountered encrypted using the Encryption-Encap AVP,
it SHALL be considered invalid and the message containing the AVP
SHALL be discarded.
X: The AVP MAY be encrypted using the Encryption-Encap AVP. If the
AVP is encountered either encrypted or not encrypted using the
Encryption-Encap AVP, it SHALL be considered valid.
The legitimate occurrence of unencrypted AVPs and AVPs after
decryption and unencapsulation SHALL be subject to the AVP Occurrence
Table (Figure 4 in [RFC5191]).
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 | 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 [RFC6345]:
Attribute Name |Enc|
----------------------+---+
PaC-Information | N |
Relayed-Message | N |
----------------------+---+
The following table shows the encryption requirements for the AVPs
defined in this document:
Attribute Name |Enc|
----------------------+---+
Encryption-Algorithm | N |
Encryption-Encap | N |
----------------------+---+
The following table is an example showing the encryption requirements
for a newly defined AVP, Example-AVP:
Attribute Name |Enc|
----------------------+---+
Example-AVP | Y |
----------------------+---+
The guidance for specifying the encryption requirements for a newly
defined AVP is as follows:
Y: If the payload needs privacy against eavesdroppers (e.g., carrying
a secret key).
N: If the payload may need to be observed by on-path network elements
(i.e., subject to deep packet inspection).
X: If neither concern applies.
7. Security Considerations
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 purposes
other than those specified in this document. Compromise of these
keys would lead to compromise of the secret information protected by
these keys.
7.1. AES-CTR Security Considerations
The use of AES-CTR encryption has its own security considerations,
which are detailed in the Security Considerations section of
[RFC3686]. Specifically:
- The nonce specified in Section 4.1 meets the requirement of
uniqueness-per-key usage.
- Section 4.1 of [RFC5191] states that if the EAP method
generates cryptographic keys, an AUTH AVP will always be
present in every PANA message after key generation. Therefore,
an Encryption-Encap AVP will always be sent in conjunction with
an AUTH AVP. This meets the requirement of a companion
authentication function.
8. IANA Considerations
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 additional encryption policy for
AVP codes has also been registered.
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:
o A standard AVP code of 12 for the Encryption-Encap AVP.
o 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":
o An AVP value of 1 for AES128_CTR.
o All other AVP values (0, 2-4294967295) are unassigned.
The registration procedures are IETF Review or IESG Approval in
accordance with [RFC5872].
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 and
has been applied to all existing AVP codes and those defined in this
specification.
9. Acknowledgments
The authors would like 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.
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.
[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
AI ELI5
On this page
§1Why PANA Needs Encryption
PANA, defined in RFC 5191, is a UDP-based protocol that runs an Extensible Authentication Protocol (EAP) exchange between a PANA Client (PaC) and a PANA Authentication Agent (PAA). Its payloads travel in Attribute-Value Pairs (AVPs).
AVPs can be integrity protected with the AUTH AVP when the EAP method generates cryptographic keying material, but they are sent unencrypted. Some payloads, for example network keys and private identifiers, need to be delivered privately. RFC 6786 defines a way to encrypt selected AVPs.
PANA messages are like postcards anyone can read. Some things written on them are secrets, so we need a way to hide just those parts.
§2Negotiating the Algorithm
RFC 6786 adds two AVPs to the set in RFC 5191: the Encryption-Algorithm AVP and the Encryption-Encap AVP. It also defines two new keys, PANA_PAC_ENCR_KEY for traffic from the PaC to the PAA and PANA_PAA_ENCR_KEY for traffic from the PAA to the PaC.
When encryption is needed, the PAA MUST send the initial PANA-Auth-Request carrying one or more Encryption-Algorithm AVPs that it supports. The PaC MUST pick one and answer with the initial PANA-Auth-Answer carrying one Encryption-Algorithm AVP for its choice. Once both keys exist, a PANA message MAY contain an Encryption-Encap AVP.
The Encryption-Algorithm AVP has AVP code 13 and an Unsigned32 value. Only AES128_CTR (value 1) is defined here. Other values are reserved for future specifications, and unless an application profile says otherwise, all implementations MUST support AES128_CTR.
First the two sides agree on which secret code to use. One offers a list, and the other picks one from it.
- PANA-Auth-Request (initial)Carries one or more Encryption-Algorithm AVPs the PAA supports.
- PANA-Auth-Answer (initial)Carries one Encryption-Algorithm AVP for the selected algorithm.
§3The Encryption Keys
Each key is computed with the prf+ function from the Internet Key Exchange protocol version 2, keyed with the master session key (MSK) from the EAP method. The inputs are a label ("IETF PANA PaC Encr" or "IETF PANA PAA Encr"), the initial PANA-Auth-Request and PANA-Auth-Answer messages, the PaC and PAA nonces, and the value of the Key-Id AVP.
The pseudo-random function used inside prf+ is the one negotiated with the PRF-Algorithm AVP in the initial exchange. The keys MUST be recalculated whenever the EAP method generates a new MSK, and their length depends on the encryption algorithm in use.
The keys are secret and shared between the PaC and the PAA. They MUST NOT be used for anything other than what this document specifies.
Both sides take a shared secret they already have and mix it with some one-time numbers to make two fresh keys, one for each direction.
§4AES128_CTR Encryption
AES128_CTR uses the AES-CTR (counter) mode of operation from NIST SP 800-38A with the AES-128 block cipher. The formatting and counter generation functions come from Appendix A of NIST SP 800-38C, with n = 12 and q = 3.
The 12-octet nonce is made of a 4-octet Key-Id, a 4-octet Session ID and a 4-octet Sequence Number, in that order, each in network byte order. The Session ID and Sequence Number are the same as in the PANA message that carries the Encryption-Encap AVP. The RFC works through an example in which Key-Id 0x55667788, Session ID 0xaabbccdd and Sequence Number 0x11223344 give a first counter block of 0x0255667788aabbccdd11223344000001.
The nonce is unique per key as long as the sequence number does not wrap. If a sender is about to wrap the sequence number, the PaC (for traffic to the PAA) or the PAA (for traffic to the PaC) MUST start PANA re-authentication, which produces a new MSK and therefore new keys.
The scrambler uses a counter that goes up each time, so no two messages are ever scrambled the same way. Before the counter runs out, the two sides start over with new keys.
§5The Encryption-Encap AVP
The Encryption-Encap AVP (AVP code 12) holds one or more encrypted PANA AVPs. With AES128_CTR, its data payload is the encrypted AVPs. A PANA message SHALL contain only one Encryption-Encap AVP, and every AVP that needs encryption SHALL go inside it.
It SHALL be used only if the EAP method generates cryptographic keys. The PaC MAY use it once PANA_PAC_ENCR_KEY exists, and the PAA MAY use it once PANA_PAA_ENCR_KEY exists, after the algorithm has been negotiated. It MAY appear in the very first message carrying the Result-Code AVP set to PANA_Success, and in any later message of the same PANA session.
The Encryption-Encap AVP is the locked envelope. Everything secret goes inside one envelope, and only one envelope is allowed per message.
§6Encryption Policy for AVPs
The specification of any AVP SHOULD say whether the AVP shall or shall not be encrypted with Encryption-Encap, using a table with three symbols. If a specification is silent, the AVP MAY be encrypted.
Y: the AVP SHALL be encrypted. If it arrives unencrypted it is invalid and the message is discarded.N: the AVP SHALL NOT be encrypted. If it arrives encrypted it is invalid and the message is discarded.X: the AVP MAY be encrypted, and either form is valid.
Guidance: use Y if the payload needs privacy against eavesdroppers (for example a secret key), N if on-path network elements may need to see it, and X if neither applies. For the existing AVPs, the RFC marks EAP-Payload, Session-Lifetime and Termination-Cause as X. AUTH, Integrity-Algorithm, Key-Id, Nonce, PRF-Algorithm and Result-Code are N, as are PaC-Information, Relayed-Message and the two new AVPs.
Every kind of note gets a rule: always lock it, never lock it, or either way is fine. If the rule is broken, the message is thrown away.
- YMust encrypt — Unencrypted AVP is invalid; message is discarded.
- NMust not encrypt — Encrypted AVP is invalid; message is discarded.
- XMay encrypt — Either form is valid.
§7Security Considerations
Compromise of PANA_PAC_ENCR_KEY or PANA_PAA_ENCR_KEY would compromise the secret information they protect, which is why they SHALL NOT be reused for other purposes.
AES-CTR has its own considerations, listed in RFC 3686. The nonce meets the uniqueness-per-key requirement. AES-CTR also needs a companion authentication function, and this is met because, once the EAP method has generated keys, an AUTH AVP is present in every PANA message, so an Encryption-Encap AVP always travels with an AUTH AVP.
If someone steals the keys, they can read the secrets, so the keys must be used only for this job. Each locked message also carries a signature that shows nobody tampered with it.
§8IANA Registrations
IANA registered standard AVP code 12 for Encryption-Encap and code 13 for Encryption-Algorithm. In the new Encryption-Algorithm sub-registry, value 1 is AES128_CTR and the other values (0, 2-4294967295) are unassigned. New values need IETF Review or IESG Approval.
An "Enc" column holding the policy from the previous section was also added to the "AVP Codes" sub-registry and filled in for all existing AVP codes and the ones defined here.
The official list of PANA codes got two new entries and a new column telling which items get locked.