< draft-ietf-pana-pana-17.txt   draft-ietf-pana-pana-18.txt >
PANA Working Group D. Forsberg PANA Working Group D. Forsberg
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track Y. Ohba (Ed.) Intended status: Standards Track Y. Ohba (Ed.)
Expires: December 19, 2007 Toshiba Expires: March 9, 2008 Toshiba
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
A. Yegin A. Yegin
Samsung Samsung
June 17, 2007 September 6, 2007
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-17 draft-ietf-pana-pana-18
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 19, 2007. This Internet-Draft will expire on March 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the Protocol for Carrying Authentication for This document defines the Protocol for Carrying Authentication for
Network Access (PANA), a network-layer transport for Extensible Network Access (PANA), a network-layer transport for Extensible
Authentication Protocol (EAP) to enable network access authentication Authentication Protocol (EAP) to enable network access authentication
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification of Requirements . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Authentication and Authorization Phase . . . . . . . . . . 9 4.1. Authentication and Authorization Phase . . . . . . . . . . 9
4.2. Access Phase . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Access Phase . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Re-authentication Phase . . . . . . . . . . . . . . . . . 12 4.3. Re-authentication Phase . . . . . . . . . . . . . . . . . 13
4.4. Termination Phase . . . . . . . . . . . . . . . . . . . . 14 4.4. Termination Phase . . . . . . . . . . . . . . . . . . . . 14
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 15 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Sequence Number and Retransmission . . . . . . . . . . . . 15 5.2. Sequence Number and Retransmission . . . . . . . . . . . . 15
5.3. PANA Security Association . . . . . . . . . . . . . . . . 16 5.3. PANA Security Association . . . . . . . . . . . . . . . . 16
5.4. Message Authentication . . . . . . . . . . . . . . . . . . 18 5.4. Message Authentication . . . . . . . . . . . . . . . . . . 18
5.5. Message Validity Check . . . . . . . . . . . . . . . . . . 18 5.5. Message Validity Check . . . . . . . . . . . . . . . . . . 18
5.6. PaC Updating its IP Address . . . . . . . . . . . . . . . 19 5.6. PaC Updating its IP Address . . . . . . . . . . . . . . . 19
5.7. Session Lifetime . . . . . . . . . . . . . . . . . . . . . 20 5.7. Session Lifetime . . . . . . . . . . . . . . . . . . . . . 20
6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 21 6.1. IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 21
6.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 21 6.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 21
6.3. AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 23
7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . . 26 7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. PANA-Client-Initiation (PCI) . . . . . . . . . . . . . . . 28 7.1. PANA-Client-Initiation (PCI) . . . . . . . . . . . . . . . 28
7.2. PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 28 7.2. PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 29
7.3. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 29 7.3. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 29
7.4. PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 29 7.4. PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 29
7.5. PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 29 7.5. PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 30
7.6. PANA-Notification-Request (PNR) . . . . . . . . . . . . . 30 7.6. PANA-Notification-Request (PNR) . . . . . . . . . . . . . 30
7.7. PANA-Notification-Answer (PNA) . . . . . . . . . . . . . . 30 7.7. PANA-Notification-Answer (PNA) . . . . . . . . . . . . . . 30
8. AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Algorithm AVP . . . . . . . . . . . . . . . . . . . . . . 31 8.1. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 32
8.3. EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 32 8.3. Integrity-Algorithm AVP . . . . . . . . . . . . . . . . . 32
8.4. Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 32 8.4. Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 32
8.5. Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 32 8.5. Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 32
8.6. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 33 8.6. PRF-Algorithm AVP . . . . . . . . . . . . . . . . . . . . 33
8.7. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 33 8.7. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 33
8.8. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 33 8.8. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 33
8.9. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 33
9. Retransmission Timers . . . . . . . . . . . . . . . . . . . . 35 9. Retransmission Timers . . . . . . . . . . . . . . . . . . . . 35
9.1. Transmission and Retransmission Parameters . . . . . . . . 36 9.1. Transmission and Retransmission Parameters . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10.1. PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 37 10.1. PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 37
10.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 37 10.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 37
10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 37 10.2.1. Message Type . . . . . . . . . . . . . . . . . . . . 37
10.2.2. Message Type . . . . . . . . . . . . . . . . . . . . 37 10.2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 38
10.2.3. Flags . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 38 10.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3.1. AVP Code . . . . . . . . . . . . . . . . . . . . . . 38 10.3.1. AVP Code . . . . . . . . . . . . . . . . . . . . . . 38
10.3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 39 10.3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 39
10.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 39 10.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 39
10.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 39 10.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 39
10.4.2. Termination-Cause AVP Values . . . . . . . . . . . . 39 10.4.2. Termination-Cause AVP Values . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. General Security Measures . . . . . . . . . . . . . . . . 40 11.1. General Security Measures . . . . . . . . . . . . . . . . 40
11.2. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 41 11.2. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 41
11.3. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 42 11.3. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 41
11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 42 11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 42
11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 42 11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 42
11.6. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 43 11.6. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 42
11.7. Liveness Test . . . . . . . . . . . . . . . . . . . . . . 43 11.7. Liveness Test . . . . . . . . . . . . . . . . . . . . . . 43
11.8. Early Termination of a Session . . . . . . . . . . . . . . 43 11.8. Early Termination of a Session . . . . . . . . . . . . . . 43
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Introduction 1. Introduction
skipping to change at page 4, line 36 skipping to change at page 4, line 36
network-layer access authentication protocol are discussed in network-layer access authentication protocol are discussed in
[RFC4016]. These have been essential in defining the requirements [RFC4016]. These have been essential in defining the requirements
[RFC4058] on the PANA protocol. Note that some of these requirements [RFC4058] on the PANA protocol. Note that some of these requirements
are imposed by the chosen payload, EAP [RFC3748]. are imposed by the chosen payload, EAP [RFC3748].
There are components that are part of a complete secure network There are components that are part of a complete secure network
access solution but are outside of the PANA protocol specification, access solution but are outside of the PANA protocol specification,
including authentication method choice, data traffic protection, including authentication method choice, data traffic protection,
PAA-EP protocol, and PAA discovery. PANA authentication output is PAA-EP protocol, and PAA discovery. PANA authentication output is
used for creating access control filters. These components are used for creating access control filters. These components are
described in separate documents (see [I-D.ietf-pana-framework], described in separate documents (see [I-D.ietf-pana-framework] and
[I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]). The readers are [I-D.ietf-dhc-paa-option]). The readers are recommended to read the
recommended to read the PANA Framework document PANA Framework document [I-D.ietf-pana-framework] prior to reading
[I-D.ietf-pana-framework] prior to reading this protocol this protocol specification document.
specification document.
1.1. Specification of Requirements 1.1. Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
skipping to change at page 9, line 44 skipping to change at page 9, line 44
can learn the IP address of the PaC are outside the scope of this can learn the IP address of the PaC are outside the scope of this
specification. specification.
A session identifier for the session is assigned by the PAA and A session identifier for the session is assigned by the PAA and
carried in the initial PANA-Auth-Request message. The same session carried in the initial PANA-Auth-Request message. The same session
identifier MUST be carried in the subsequent messages exchanged identifier MUST be carried in the subsequent messages exchanged
between the PAA and PaC throughout the session. between the PAA and PaC throughout the session.
When the PaC receives the initial PANA-Auth-Request message from a When the PaC receives the initial PANA-Auth-Request message from a
PAA, it responds with a PANA-Auth-Answer message, if it wishes to PAA, it responds with a PANA-Auth-Answer message, if it wishes to
continue the PANA session. continue the PANA session. Otherwise, it silently discards the PANA-
Auth-Request message.
The initial PANA-Auth-Request and PANA-Auth-Answer messages MUST have The initial PANA-Auth-Request and PANA-Auth-Answer messages MUST have
the 'S' (Start) bit set, regardless of whether the session is the 'S' (Start) bit set, regardless of whether the session is
initiated by the PaC or the PAA. Non-initial PANA-Auth-Request and initiated by the PaC or the PAA. Non-initial PANA-Auth-Request and
PANA-Auth-Answer messages as well as any other messages MUST NOT have PANA-Auth-Answer messages as well as any other messages MUST NOT have
the 'S' (Start) bit set. the 'S' (Start) bit set.
It is recommended that the PAA limit the rate it processes incoming It is recommended that the PAA limit the rate it processes incoming
PANA-Client-Initiation messages to provide robustness against PANA-Client-Initiation messages to provide robustness against
denial-of service (DoS) attacks. Details of rate limiting are denial-of service (DoS) attacks. Details of rate limiting are
outside the scope of this specification. outside the scope of this specification.
An Algorithm AVP MAY be included in the initial PANA-Auth-Request in If a PANA SA needs to be established with use of a key-generating EAP
order to indicate required and available capabilities for the network method, PRF and integrity algorithms to be used for PANA_AUTH_KEY
access. This AVP MAY be used by the PaC for assessing the capability derivation (see Section 5.3) and AUTH AVP calculation (see
match even before the authentication takes place. Since this AVP is Section 5.4) are negotiated as follows. The PAA sends the initial
provided in the insecure initial request, there are certain security PANA-Auth-Request carrying one or more PRF-Algorithm AVPs and one or
risks involved in using the provided information. See Section 11 for more Integrity-Algorithm AVPs for the PRF and integrity algorithms
further discussion on this. supported by it, respectively. The PaC then selects one PRF
algorithm and one integrity algorithm from these AVPs carried in the
initial PANA-Auth-Request and responds with the initial
PANA-Auth-Answer carrying one PRF-Algorithm AVP and one Integrity-
Algorithm AVP for the selected algorithms. The negotiation is
protected after the MSK is available, as described in Section 5.3.
If the PAA wants to stay stateless in response to a If the PAA wants to stay stateless in response to a
PANA-Client-Initiation message, it doesn't include an EAP-Payload AVP PANA-Client-Initiation message, it doesn't include an EAP-Payload AVP
in the initial PANA-Auth-Request message, and it should not re- in the initial PANA-Auth-Request message, and it should not re-
transmit the message on a timer. For this reason, the PaC MUST transmit the message on a timer. For this reason, the PaC MUST
retransmit the PANA-Client-Initiation message until it receives the retransmit the PANA-Client-Initiation message until it receives the
second PANA-Auth-Request message (not a retransmission of the initial second PANA-Auth-Request message (not a retransmission of the initial
one) from the PAA. one) from the PAA.
It is possible that both the PAA and the PaC initiate the PANA It is possible that both the PAA and the PaC initiate the PANA
skipping to change at page 11, line 11 skipping to change at page 11, line 17
The result of PANA authentication is carried in the last The result of PANA authentication is carried in the last
PANA-Auth-Request message sent from the PAA to the PaC. This message PANA-Auth-Request message sent from the PAA to the PaC. This message
carries the EAP authentication result and the result of PANA carries the EAP authentication result and the result of PANA
authentication. The last PANA-Auth-Request message MUST be authentication. The last PANA-Auth-Request message MUST be
acknowledged with a PANA-Auth-Answer message. The last acknowledged with a PANA-Auth-Answer message. The last
PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'C' PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'C'
(Complete) bit set, and any other message MUST NOT have the 'C' (Complete) bit set, and any other message MUST NOT have the 'C'
(Complete) bit set. Figure 1 shows an example sequence in the (Complete) bit set. Figure 1 shows an example sequence in the
authentication and authorization phase for a PaC-initiated session. authentication and authorization phase for a PaC-initiated session.
PaC PAA Message(sequence number)[AVPs] PaC PAA Message(sequence number)[AVPs]
-------------------------------------------------------------------- --------------------------------------------------------------------
-----> PANA-Client-Initiation(0) -----> PANA-Client-Initiation(0)
<----- PANA-Auth-Request(x) // The 'S' (Start) bit set <----- PANA-Auth-Request(x)[PRF-Algorithm, Integrity-Algorithm]
-----> PANA-Auth-Answer(x) // The 'S' (Start) bit set // The 'S' (Start) bit set
<----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] -----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm]
-----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP // The 'S' (Start) bit set
-----> PANA-Auth-Request(y)[EAP-Payload] <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload]
<----- PANA-Auth-Answer(y) -----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP
<----- PANA-Auth-Request(x+2)[EAP-Payload] -----> PANA-Auth-Request(y)[EAP-Payload]
-----> PANA-Auth-Answer(x+2)[EAP-Payload] <----- PANA-Auth-Answer(y)
// Piggybacking EAP <----- PANA-Auth-Request(x+2)[EAP-Payload]
<----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, -----> PANA-Auth-Answer(x+2)[EAP-Payload]
Key-Id, Algorithm, // Piggybacking EAP
Session-Lifetime, AUTH] <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload,
// The 'C' (Complete) bit set Key-Id, Session-Lifetime, AUTH]
-----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] // The 'C' (Complete) bit set
// The 'C' (Complete) bit set -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH]
// The 'C' (Complete) bit set
Figure 1: Example sequence for the authentication and authorization Figure 1: Example sequence for the authentication and authorization
phase for a PaC-initiated session ("Piggybacking EAP" is the case in phase for a PaC-initiated session ("Piggybacking EAP" is the case in
which an EAP-Payload AVP is carried in PAN.) which an EAP-Payload AVP is carried in PAN.)
When an EAP method that is capable of deriving keys is used during If a PANA SA needs to be established with use of a key-generating EAP
the authentication and authorization phase and the keys are method and an MSK is successfully generated, the last
successfully derived, the last PANA-Auth-Request message with the 'C' PANA-Auth-Request message with the 'C' (Complete) bit set MUST
(Complete) bit set MUST contain a Key-Id AVP and an AUTH AVP, and an contain a Key-Id AVP and an AUTH AVP for the first derivation of keys
Algorithm AVP for the first derivation of keys in the session, and in the session, and any subsequent message MUST contain an AUTH AVP.
any subsequent message MUST contain an AUTH AVP. An Algorithm AVP
MUST NOT be contained in any PANA-Auth-Request message after the
first derivation of keys in the session.
EAP authentication can fail at a pass-through authenticator without EAP authentication can fail at a pass-through authenticator without
sending an EAP Failure message [RFC4137]. When this occurs, the PAA sending an EAP Failure message [RFC4137]. When this occurs, the PAA
SHOULD silently terminate the session, expecting that a session SHOULD silently terminate the session, expecting that a session
timeout on the PaC will clean up the state on the PaC. timeout on the PaC will clean up the state on the PaC.
There is a case where EAP authentication succeeds with producing an There is a case where EAP authentication succeeds with producing an
EAP Success message but network access authorization fails due to, EAP Success message but network access authorization fails due to,
e.g., authorization rejected by a AAA or authorization locally e.g., authorization rejected by a AAA or authorization locally
rejected by the PAA. When this occurs, the PAA MUST send the last rejected by the PAA. When this occurs, the PAA MUST send the last
PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED. If PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED. If
an MSK is available, the last PANA-Auth-Request and PANA-Auth-Answer an MSK is available, the last PANA-Auth-Request and PANA-Auth-Answer
messages with the 'C' (Complete) bit set MUST be protected with an messages with the 'C' (Complete) bit set MUST be protected with an
AUTH AVP and carry a Key-Id AVP. The last PANA-Auth-Request message AUTH AVP and carry a Key-Id AVP. The PANA session MUST be terminated
MUST also carry an Algorithm AVP if it is for the first derivation of immediately after the last PANA-Auth message exchange.
keys in the session. The PANA session MUST be terminated immediately
after the last PANA-Auth message exchange. The PaC may need to reconfigure IP address after successful
authentication and authorization phase to obtain an IP address that
is usable for exchanging data traffic through EP. In this case, the
PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request
messages in the authentication and authorization phase to indicate
the PaC the need for IP address reconfiguration. How IP address
reconfiguration is performed is outside the scope of this document.
4.2. Access Phase 4.2. Access Phase
Once the authentication and authorization phase successfully Once the authentication and authorization phase successfully
completes, the PaC gains access to the network and can send and completes, the PaC gains access to the network and can send and
receive IP data traffic through the EP(s) and the PANA session enters receive IP data traffic through the EP(s) and the PANA session enters
the access phase. In this phase, PANA-Notification-Request and the access phase. In this phase, PANA-Notification-Request and
PANA-Notification-Answer messages with the 'P' (Ping) bit set (ping PANA-Notification-Answer messages with the 'P' (Ping) bit set (ping
request and ping answer messages, respectively) can be used for request and ping answer messages, respectively) can be used for
testing the liveness of the PANA session on the PANA peer. Both the testing the liveness of the PANA session on the PANA peer. Both the
skipping to change at page 14, line 18 skipping to change at page 14, line 18
// The 'A' (re-Authentication) bit set // The 'A' (re-Authentication) bit set
<----- PANA-Notification-Answer(q)[AUTH] <----- PANA-Notification-Answer(q)[AUTH]
// The 'A' (re-Authentication) bit set // The 'A' (re-Authentication) bit set
<----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH] <----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH]
-----> PANA-Auth-Answer(p)[AUTH, Nonce] -----> PANA-Auth-Answer(p)[AUTH, Nonce]
-----> PANA-Auth-Request(q+1)[EAP-Payload, AUTH] -----> PANA-Auth-Request(q+1)[EAP-Payload, AUTH]
<----- PANA-Auth-Answer(q+1)[AUTH] <----- PANA-Auth-Answer(q+1)[AUTH]
<----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH]
-----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH]
<----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload,
Key-Id, Algorithm, Key-Id, Session-Lifetime, AUTH]
Session-Lifetime, AUTH]
// The 'C' (Complete) bit set // The 'C' (Complete) bit set
-----> PANA-Auth-Answer(p+2)[Key-Id, AUTH] -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH]
// The 'C' (Complete) bit set // The 'C' (Complete) bit set
Figure 2: Example sequence for the re-authentication phase initiated Figure 2: Example sequence for the re-authentication phase initiated
by PaC by PaC
4.4. Termination Phase 4.4. Termination Phase
A procedure for explicitly terminating a PANA session can be A procedure for explicitly terminating a PANA session can be
skipping to change at page 17, line 37 skipping to change at page 17, line 37
* PANA_AUTH_KEY * PANA_AUTH_KEY
* Pseudo-random function * Pseudo-random function
* Integrity algorithm * Integrity algorithm
The PANA_AUTH_KEY is derived from the available MSK and it is used to The PANA_AUTH_KEY is derived from the available MSK and it is used to
integrity protect PANA messages. The PANA_AUTH_KEY is computed in integrity protect PANA messages. The PANA_AUTH_KEY is computed in
the following way: the following way:
PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID) PANA_AUTH_KEY = prf+(MSK, I_PAR|I_PAN|PaC_nonce|PAA_nonce|Key_ID)
where the prf+ function is defined in IKEv2 [RFC4306]. The where the prf+ function is defined in IKEv2 [RFC4306]. The
pseudo-random function to be used for the prf+ function is specified pseudo-random function to be used for the prf+ function is negotiated
in the Algorithm AVP in the last PANA-Auth-Request message. The using PRF-Algorithm AVP in the initial PANA-Auth-Request and
length of PANA_AUTH_KEY depends on the integrity algorithm in use. PANA-Auth-Answer exchange with 'S' (Start) bit set. The length of
See Section 5.4 for the detailed usage of the PANA_AUTH_KEY. PANA_AUTH_KEY depends on the integrity algorithm in use. See
PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the Section 5.4 for the detailed usage of the PANA_AUTH_KEY. I_PAR and
first non-initial PANA-Auth-Answer and PANA-Auth-Request messages in I_PAN are the initial PANA-Auth-Request and PANA-Auth-Answer messages
the authentication and authorization phase or the first (the PANA header and the following PANA AVPs) with 'S' (Start) bit
PANA-Auth-Answer and PANA-Auth-Request messages in the set, respectively. PaC_nonce and PAA_nonce are values of the Nonce
re-authentication phase, respectively. Session_ID is the session AVP carried in the first non-initial PANA-Auth-Answer and
identifier of the session. Key_ID is the value of the Key-Id AVP. 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.
5.4. Message Authentication 5.4. Message Authentication
A PANA message can contain an AUTH AVP for cryptographically A PANA message can contain an AUTH AVP for cryptographically
protecting the message. protecting the message.
When an AUTH AVP is included in a PANA message, the value field of When an AUTH AVP is included in a PANA message, the value field of
the AUTH AVP is calculated by using the PANA_AUTH_KEY in the the AUTH AVP is calculated by using the PANA_AUTH_KEY in the
following way: following way:
AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)
where PANA_PDU is the PANA message including the PANA header, with where PANA_PDU is the PANA message including the PANA header, with
the AUTH AVP value field first initialized to 0. PANA_AUTH_HASH the AUTH AVP value field first initialized to 0. PANA_AUTH_HASH
represents the integrity algorithm specified in the Algorithm AVP in represents the integrity algorithm negotiated using Integrity-
the last PANA-Auth-Request message. The PaC and PAA MUST use the Algorithm AVP in the initial PANA-Auth-Request and PANA-Auth-Answer
same integrity algorithm to calculate an AUTH AVP they originate and exchange with 'S' (Start) bit set. The PaC and PAA MUST use the same
receive. The algorithm is determined by the PAA. When the PaC does integrity algorithm to calculate an AUTH AVP they originate and
not support the integrity algorithm specified in the last receive.
PANA-Auth-Request message, it MUST silently discard the message.
5.5. Message Validity Check 5.5. Message Validity Check
When a PANA message is received, the message is considered to be When a PANA message is received, the message is considered to be
invalid at least when one of the following conditions are not met: invalid at least when one of the following conditions are not met:
o Each field in the message header contains a valid value including o Each field in the message header contains a valid value including
sequence number, message length, message type, version number, sequence number, message length, message type, flags, session
flags, session identifier, etc. identifier, etc.
o The message type is one of the expected types in the current o The message type is one of the expected types in the current
state. Specifically the following messages are unexpected and state. Specifically the following messages are unexpected and
invalid: invalid:
* In the authentication and authorization phase: * In the authentication and authorization phase:
+ PANA-Client-Initiation after completion of the initial + PANA-Client-Initiation after completion of the initial
PANA-Auth-Request and PANA-Auth-Answer exchange. PANA-Auth-Request and PANA-Auth-Answer exchange with 'S'
(Start) bit set.
+ Re-authentication request. + Re-authentication request.
+ The last PANA-Auth-Request as well as ping request before + Ping request.
completion of the initial PANA-Auth-Request and
PANA-Auth-Answer exchange.
+ The initial PANA-Auth-Request after a PaC receives a valid + The last PANA-Auth-Request with 'C' (Complete) bit set
non-initial PANA-Auth-Request. before completion of the initial PANA-Auth-Request and
PANA-Auth-Answer exchange with 'S' (Start) bit set.
+ The initial PANA-Auth-Request with 'S' (Start) bit set after
a PaC receives a valid non-initial PANA-Auth-Request with
'S' (Start) bit cleared.
+ PANA-Termination-Request. + PANA-Termination-Request.
* In the re-authentication phase: * In the re-authentication phase:
+ PANA-Client-Initiation. + PANA-Client-Initiation.
+ The initial PANA-Auth-Request. + The initial PANA-Auth-Request.
* In the access phase: * In the access phase:
skipping to change at page 19, line 30 skipping to change at page 19, line 31
+ PANA-Client-Initiation. + PANA-Client-Initiation.
+ All requests but PANA-Termination-Request and ping request. + All requests but PANA-Termination-Request and ping request.
o The message payload contains a valid set of AVPs allowed for the o The message payload contains a valid set of AVPs allowed for the
message type and there is no missing AVP that needs to be included message type and there is no missing AVP that needs to be included
in the payload and no AVP, which needs to be at a fixed position, in the payload and no AVP, which needs to be at a fixed position,
is included in a position different from this fixed position. is included in a position different from this fixed position.
o Each AVP is decoded correctly. o Each AVP is recognized and decoded correctly.
o When an AUTH AVP is included, the AVP value matches the hash value
computed against the received message.
o When an Algorithm AVP is included, the algorithms indicated in the o Once the PANA authentication succeeds using a key-generating EAP
AVP value is supported. method, the PANA-Auth-Request message that carries the EAP Success
and any subsequent message in that session contain an AUTH AVP.
The AVP value matches the hash value computed against the received
message.
Invalid messages MUST be discarded in order to provide robustness Invalid messages MUST be discarded in order to provide robustness
against DoS attacks. against DoS attacks.
5.6. PaC Updating its IP Address 5.6. PaC Updating its IP Address
A PaC's IP address used for PANA can change in certain situations, A PaC's IP address used for PANA can change in certain situations,
e.g., when the PaC moves from one IP link to another within the same e.g., when IP address reconfiguration is needed for the PaC to obtain
an IP address after successful PANA authentication (see Section 4.1)
or when the PaC moves from one IP link to another within the same
PAA's realm. In order to maintain the PANA session, the PAA needs to PAA's realm. In order to maintain the PANA session, the PAA needs to
be notified about the change of PaC address. be notified about the change of PaC address.
After the PaC has changed its IP address used for PANA, it MUST send After the PaC has changed its IP address used for PANA, it MUST send
any valid PANA message. If the message that carries the new PaC IP any valid PANA message. If the message that carries the new PaC IP
address in the Source Address field of the IP header is valid, the address in the Source Address field of the IP header is valid, the
PAA MUST update the PANA session with the new PaC address. If there PAA MUST update the PANA session with the new PaC address. If there
is an established PANA SA, the message MUST be protected with an AUTH is an established PANA SA, the message MUST be protected with an AUTH
AVP. AVP.
skipping to change at page 21, line 14 skipping to change at page 21, line 14
6. Message Format 6. Message Format
This section defines message formats for PANA protocol. This section defines message formats for PANA protocol.
6.1. IP and UDP Headers 6.1. IP and UDP Headers
Any PANA message is unicast between the PaC and the PAA. Any PANA message is unicast between the PaC and the PAA.
For any PANA message sent from the peer that has initiated the PANA For any PANA message sent from the peer that has initiated the PANA
session, the UDP source port is set to any number and the destination session, the UDP source port is set to any number on which the peer
port is set to the assigned PANA port number (to be assigned by can receive incoming PANA messages and the destination port is set to
IANA). For any PANA message sent from the other peer, the source the assigned PANA port number (to be assigned by IANA). For any PANA
port is set to the assigned PANA port number (to be assigned by IANA) message sent from the other peer, the source port is set to the
and the destination port is copied from the source port of the last assigned PANA port number (to be assigned by IANA) and the
received message. In case both the PaC and PAA initiates the session destination port is copied from the source port of the last received
(i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request message. In case both the PaC and PAA initiates the session (i.e.,
messages cross each other), then the PaC is identified as the PANA-Client-Initiation and unsolicited PANA-Auth-Request messages
initiator. cross each other), then the PaC is identified as the initiator. All
PANA peers MUST listen on the assigned PANA port number (to be
assigned by IANA).
6.2. PANA Message Header 6.2. PANA Message Header
A summary of the PANA message header format is shown below. The A summary of the PANA message header format is shown below. The
fields are transmitted in network byte order. fields are transmitted in network byte order.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Length | | Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Message Type | | Flags | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ... | AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
Version
This Version field MUST be set to 1 to indicate PANA Version 1.
Reserved Reserved
This 8-bit field is reserved for future use, and MUST be set to This 16-bit field is reserved for future use, and MUST be set to
zero, and ignored by the receiver. zero, and ignored by the receiver.
Message Length Message Length
The Message Length field is two octets and indicates the length of The Message Length field is two octets and indicates the length of
the PANA message including the header fields. the PANA message including the header fields.
Flags Flags
The Flags field is two octets. The following bits are assigned: The Flags field is two octets. The following bits are assigned:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S C A P r r r r r r r r r r r| |R S C A P I r r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Request) R (Request)
If set, the message is a request. If cleared, the message is If set, the message is a request. If cleared, the message is
an answer. an answer.
S (Start) S (Start)
If set, the message is the first PANA-Auth-Request or PANA- If set, the message is the first PANA-Auth-Request or PANA-
skipping to change at page 22, line 49 skipping to change at page 22, line 49
If set, the message is a PANA-Notification-Request or PANA- If set, the message is a PANA-Notification-Request or PANA-
Notification-Answer to initiate re-authentication. For other Notification-Answer to initiate re-authentication. For other
messages this bit MUST be cleared. messages this bit MUST be cleared.
P (Ping) P (Ping)
If set, the message is a PANA-Notification-Request or PANA- If set, the message is a PANA-Notification-Request or PANA-
Notification-Answer for liveness test. For other messages this Notification-Answer for liveness test. For other messages this
bit MUST be cleared. bit MUST be cleared.
I (IP Reconfiguration)
If set, it indicates that the PaC is required to perform IP
address reconfiguration after successful authentication and
authorization phase to configure an IP address that is usable
for exchanging data traffic across EP. This bit is set by the
PAA and only for PANA-Auth-Request messages in the
authentication and authorization phase. For other messages,
this bit MUST be cleared .
r (reserved) r (reserved)
These flag bits are reserved for future use, and MUST be set to These flag bits are reserved for future use, and MUST be set to
zero, and ignored by the receiver. zero, and ignored by the receiver.
Message Type Message Type
The Message Type field is two octets, and is used in order to The Message Type field is two octets, and is used in order to
communicate the message type with the message. Message Type communicate the message type with the message. Message Type
allocation is managed by IANA [ianaweb]. allocation is managed by IANA [ianaweb].
skipping to change at page 24, line 32 skipping to change at page 24, line 32
attribute. attribute.
AVP Flags AVP Flags
The AVP Flags field is two octets. The following bits are The AVP Flags field is two octets. The following bits are
assigned: assigned:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r r r r r r r r r| |V r r r r r r r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V (Vendor) V (Vendor)
The 'V' (Vendor) bit indicates whether the optional Vendor-Id The 'V' (Vendor) bit indicates whether the optional Vendor-Id
field is present in the AVP header. When set the AVP Code field is present in the AVP header. When set the AVP Code
belongs to the specific vendor code address space. belongs to the specific vendor code address space. All AVPs
defined in this document MUST have the 'V' (Vendor) bit
M (Mandatory) cleared.
The 'M' (Mandatory) bit indicates whether support of the AVP is
required. If an AVP with the 'M' (Mandatory) bit set is
received by the PaC or PAA and either the AVP or its value is
unrecognized, the message MUST be considered as invalid. AVPs
with the 'M' (Mandatory) bit cleared are informational only and
a receiver that receives a message with such an AVP that is not
recognized, or whose value is not recognized, MAY simply ignore
the AVP.
r (reserved) r (reserved)
These flag bits are reserved for future use, and MUST be set to These flag bits are reserved for future use, and MUST be set to
zero, and ignored by the receiver. zero, and ignored by the receiver.
AVP Length AVP Length
The AVP Length field is two octets, and indicates the number of The AVP Length field is two octets, and indicates the number of
octets in the Value field. The length of the AVP Code, AVP octets in the Value field. The length of the AVP Code, AVP
skipping to change at page 25, line 41 skipping to change at page 26, line 5
other vendor's vendor-specific AVP(s), nor with future IETF other vendor's vendor-specific AVP(s), nor with future IETF
applications. applications.
Value Value
The Value field is zero or more octets and contains information The Value field is zero or more octets and contains information
specific to the Attribute. The format of the Value field is specific to the Attribute. The format of the Value field is
determined by the AVP Code and Vendor-Id fields. The length of determined by the AVP Code and Vendor-Id fields. The length of
the Value field is determined by the AVP Length field. the Value field is determined by the AVP Length field.
Unless otherwise noted, AVPs defined in this document will have the
following default AVP Flags field settings: The 'M' (Mandatory) bit
MUST be set. The 'V' (Vendor) bit MUST NOT be set.
7. PANA Messages 7. PANA Messages
Each Request/Answer message pair is assigned a Sequence Number, and Each Request/Answer message pair is assigned a Sequence Number, and
the sub-type (i.e., request or answer) is identified via the 'R' the sub-type (i.e., request or answer) is identified via the 'R'
(Request) bit in the Message Flags field of the PANA message header. (Request) bit in the Message Flags field of the PANA message header.
Every PANA message MUST contain a message type in its header's Every PANA message MUST contain a message type in its header's
Message Type field, which is used to determine the action that is to Message Type field, which is used to determine the action that is to
be taken for a particular message. Figure 3 lists all PANA messages be taken for a particular message. Figure 3 lists all PANA messages
defined in this document: defined in this document:
skipping to change at page 26, line 30 skipping to change at page 26, line 30
PANA-Auth-Request PAR 2 <-------> 7.2 PANA-Auth-Request PAR 2 <-------> 7.2
PANA-Auth-Answer PAN 2 <-------> 7.3 PANA-Auth-Answer PAN 2 <-------> 7.3
PANA-Termination-Request PTR 3 <-------> 7.4 PANA-Termination-Request PTR 3 <-------> 7.4
PANA-Termination-Answer PTA 3 <-------> 7.5 PANA-Termination-Answer PTA 3 <-------> 7.5
PANA-Notification-Request PNR 4 <-------> 7.6 PANA-Notification-Request PNR 4 <-------> 7.6
PANA-Notification-Answer PNA 4 <-------> 7.7 PANA-Notification-Answer PNA 4 <-------> 7.7
---------------------------------------------------------------- ----------------------------------------------------------------
Figure 3: Table of PANA Messages Figure 3: Table of PANA Messages
PANA message definitions include a corresponding ABNF [RFC4234] The language used for PANA message definitions (i.e., AVPs valid for
specification, which is used to define the AVPs for that PANA message that PANA message type) in Section 7.1 through Section 7.7 is defined
type, and whether or not each AVP is Mandatory. The following format using ABNF [RFC4234] as follows:
is used in the definition:
message-def = Message-Name "::=" PANA-message message-def = Message-Name LWSP "::=" LWSP PANA-message
message-name = PANA-name Message-Name = PANA-name
PANA-name = ALPHA *(ALPHA / DIGIT / "-") PANA-name = ALPHA *(ALPHA / DIGIT / "-")
PANA-message = header [ *fixed] [ *required] [ *optional] PANA-message = header LWSP *fixed LWSP *required
[ *fixed] LWSP *optional LWSP *fixed
header = "< PANA-Header: " Message-Type header = "<" LWSP "PANA-Header:" LWSP Message-Type
[r-bit] [s-bit] [c-bit] [a-bit] [p-bit] ">" [r-bit] [s-bit] [c-bit] [a-bit] [p-bit] [i-bit]
LWSP ">"
Message-Type = 1*DIGIT Message-Type = 1*DIGIT
; The Message Type assigned to the message ; The Message Type assigned to the message
r-bit = ", REQ" r-bit = ",REQ"
; If present, the 'R' (Request) bit in the Message ; If present, the 'R' (Request) bit in the Message
; Flags is set, indicating that the message ; Flags is set, indicating that the message
; is a request, as opposed to an answer. ; is a request, as opposed to an answer.
s-bit = ", STA" s-bit = ",STA"
; If present, the 'S' (Start) bit in the Message ; If present, the 'S' (Start) bit in the Message
; Flags is set, indicating that the message ; Flags is set, indicating that the message
; is the initial PAR or PAN in authentication ; is the initial PAR or PAN in authentication
; and authorization phase. ; and authorization phase.
c-bit = ", COM" c-bit = ",COM"
; If present, the 'C' bit in the Message ; If present, the 'C' bit in the Message
; Flags is set, indicating that the message ; Flags is set, indicating that the message
; is the final PAR and PAN in authentication ; is the final PAR and PAN in authentication
; and authorization phase or re-authentication ; and authorization phase or re-authentication
; phase. ; phase.
a-bit = ", REA" a-bit = ",REA"
; If present, the 'A' (re-Authentication) bit ; If present, the 'A' (re-Authentication) bit
; in the Message Flags is set, indicating that ; in the Message Flags is set, indicating that
; the message is a re-authentication request or ; the message is a re-authentication request or
; answer. ; answer.
p-bit = ", PIN" p-bit = ",PIN"
; If present, the 'P' (Ping) bit in the Message ; If present, the 'P' (Ping) bit in the Message
; Flags is set, indicating that the message ; Flags is set, indicating that the message
; is a ping request or answer. ; is a ping request or answer.
fixed = [qual] "<" avp-spec ">" i-bit = ",IPR"
; If present, the 'I' (IP Reconfiguration) bit
; in the Message Flags is set, indicating that
; the PaC requires IP address reconfiguration
; after successful authentication and
; authorization phase.
fixed = [qual] "<" LWSP avp-spec LWSP ">"
; Defines the fixed position of an AVP. ; Defines the fixed position of an AVP.
required = [qual] "{" avp-spec "}" required = [qual] "{" LWSP avp-spec LWSP "}"
; The AVP MUST be present and can appear ; The AVP MUST be present and can appear
; anywhere in the message. ; anywhere in the message.
optional = [qual] "[" avp-name "]" optional = [qual] "[" LWSP avp-name LWSP "]"
; The avp-name in the 'optional' rule cannot ; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included ; evaluate to any AVP Name which is included
; in a fixed or required rule. The AVP can ; in a fixed or required rule. The AVP can
; appear anywhere in the message. ; appear anywhere in the message.
qual = [min] "*" [max] qual = [min] "*" [max]
; See ABNF conventions, RFC 4234 Section 3.6. ; See ABNF conventions, RFC 4234 Section 3.6.
; The absence of any qualifiers depends on whether ; The absence of any qualifiers depends on whether
; it precedes a fixed, required, or optional ; it precedes a fixed, required, or optional
; rule. If a fixed or required rule has no ; rule. If a fixed or required rule has no
; qualifier, then exactly one such AVP MUST ; qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no ; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be ; qualifier, then 0 or 1 such AVP may be
; present. ; present.
; ;
; NOTE: "[" and "]" have a different meaning ; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above). ; than in ABNF (see the optional rule, above).
; These braces cannot be used to express ; These braces cannot be used to express
; optional fixed rules (such as an optional ; optional fixed rules (such as an optional
; AUTH at the end). To do this, the convention ; AUTH at the end). To do this, the convention
; is '0*1fixed'. ; is '0*1fixed'.
min = 1*DIGIT min = 1*DIGIT
; The minimum number of times the element may ; The minimum number of times the element may
skipping to change at page 28, line 41 skipping to change at page 28, line 48
; required or fixed position AVPs defined in ; required or fixed position AVPs defined in
; the message definition. ; the message definition.
7.1. PANA-Client-Initiation (PCI) 7.1. PANA-Client-Initiation (PCI)
The PANA-Client-Initiation (PCI) message is used for PaC-initiated The PANA-Client-Initiation (PCI) message is used for PaC-initiated
session. The Sequence Number and Session Identifier fields in this session. The Sequence Number and Session Identifier fields in this
message MUST be set to zero (0). message MUST be set to zero (0).
PANA-Client-Initiation ::= < PANA-Header: 1 > PANA-Client-Initiation ::= < PANA-Header: 1 >
* [ AVP ] *[ AVP ]
7.2. PANA-Auth-Request (PAR) 7.2. PANA-Auth-Request (PAR)
The PANA-Auth-Request (PAR) message is either sent by the PAA or the The PANA-Auth-Request (PAR) message is either sent by the PAA or the
PaC. PaC.
The message MUST NOT have both the 'S' (Start) and 'C' (Complete) The message MUST NOT have both the 'S' (Start) and 'C' (Complete)
bits set. bits set.
PANA-Auth-Request ::= < PANA-Header: 2, REQ[,STA][,COM] > PANA-Auth-Request ::= < PANA-Header: 2,REQ[,STA][,COM][,IPR] >
[ EAP-Payload ] [ EAP-Payload ]
[ Algorithm ]
[ Nonce ] [ Nonce ]
*[ PRF-Algorithm ]
*[ Integrity-Algorithm ]
[ Result-Code ] [ Result-Code ]
[ Session-Lifetime ] [ Session-Lifetime ]
[ Key-Id ] [ Key-Id ]
* [ AVP ] *[ AVP ]
0*1 < AUTH > 0*1< AUTH >
7.3. PANA-Auth-Answer (PAN) 7.3. PANA-Auth-Answer (PAN)
The PANA-Auth-Answer (PAN) message is sent by either the PaC or the The PANA-Auth-Answer (PAN) message is sent by either the PaC or the
PAA in response to a PANA-Auth-Request message. PAA in response to a PANA-Auth-Request message.
The message MUST NOT have both the 'S' (Start) and 'C' (Complete) The message MUST NOT have both the 'S' (Start) and 'C' (Complete)
bits set. bits set.
PANA-Auth-Answer ::= < PANA-Header: 2 [,STA][,COM] > PANA-Auth-Answer ::= < PANA-Header: 2[,STA][,COM] >
[ Nonce ] [ Nonce ]
[ PRF-Algorithm ]
[ Integrity-Algorithm ]
[ EAP-Payload ] [ EAP-Payload ]
[ Key-Id ] [ Key-Id ]
* [ AVP ] *[ AVP ]
0*1 < AUTH > 0*1< AUTH >
7.4. PANA-Termination-Request (PTR) 7.4. PANA-Termination-Request (PTR)
The PANA-Termination-Request (PTR) message is sent either by the PaC The PANA-Termination-Request (PTR) message is sent either by the PaC
or the PAA to terminate a PANA session. or the PAA to terminate a PANA session.
PANA-Termination-Request ::= < PANA-Header: 3, REQ > PANA-Termination-Request ::= < PANA-Header: 3,REQ >
< Termination-Cause > < Termination-Cause >
* [ AVP ] *[ AVP ]
0*1 < AUTH > 0*1< AUTH >
7.5. PANA-Termination-Answer (PTA) 7.5. PANA-Termination-Answer (PTA)
The PANA-Termination-Answer (PTA) message is sent either by the PaC The PANA-Termination-Answer (PTA) message is sent either by the PaC
or the PAA in response to PANA-Termination-Request. or the PAA in response to PANA-Termination-Request.
PANA-Termination-Answer ::= < PANA-Header: 3 > PANA-Termination-Answer ::= < PANA-Header: 3 >
* [ AVP ] *[ AVP ]
0*1 < AUTH > 0*1< AUTH >
7.6. PANA-Notification-Request (PNR) 7.6. PANA-Notification-Request (PNR)
The PANA-Notification-Request (PNR) message is sent either by the PaC The PANA-Notification-Request (PNR) message is used for signaling re-
or the PAA for signaling re-authentication and performing liveness authentication and performing liveness test. See Section 4.3 and
test. Section 4.2 for details on re-authentication and liveness test,
respectively.
The message MUST have one of the 'A' (re-Authentication) and 'P' The message MUST have one of the 'A' (re-Authentication) and 'P'
(Ping) bits exclusively set. (Ping) bits exclusively set.
PANA-Notification-Request ::= < PANA-Header: 4, REQ[,REA][,PIN] > PANA-Notification-Request ::= < PANA-Header: 4,REQ[,REA][,PIN] >
* [ AVP ] *[ AVP ]
0*1 < AUTH > 0*1< AUTH >
7.7. PANA-Notification-Answer (PNA) 7.7. PANA-Notification-Answer (PNA)
The PANA-Notification-Answer (PNA) message is sent by the PAA (PaC) The PANA-Notification-Answer (PNA) message is sent by the PAA (PaC)
to the PaC (PAA) in response to a PANA-Notification-Request from the to the PaC (PAA) in response to a PANA-Notification-Request from the
PaC (PAA). PaC (PAA).
The message MUST have one of the 'A' (re-Authentication) and 'P' The message MUST have one of the 'A' (re-Authentication) and 'P'
(Ping) bits exclusively set. (Ping) bits exclusively set.
PANA-Notification-Answer ::= < PANA-Header: 4, REQ[,REA][,PIN] > PANA-Notification-Answer ::= < PANA-Header: 4[,REA][,PIN] >
* [ AVP ] *[ AVP ]
0*1 < AUTH > 0*1< AUTH >
8. AVPs in PANA 8. AVPs in PANA
This document uses AVP Value Format such as 'OctetString' and This document uses AVP Value Format such as 'OctetString' and
'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions 'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions
of these data formats are not repeated in this document. of these data formats are not repeated in this document.
The following table lists the AVPs used in this document, and The following table lists the AVPs used in this document, and
specifies in which PANA messages they MAY, or MAY NOT be present. specifies in which PANA messages they MAY, or MAY NOT be present.
The table uses the following symbols: The table uses the following symbols:
0 The AVP MUST NOT be present in the message. 0 The AVP MUST NOT be present in the message.
0-1 Zero or one instance of the AVP MAY be present in the message. 0-1 Zero or one instance of the AVP MAY be present in the message.
It is considered an error if there are more than one instance It is considered an error if there are more than one instance
of the AVP. of the AVP.
1 One instance of the AVP MUST be present in the message. 1 One instance of the AVP MUST be present in the message.
0+ Zero or more instance of the AVP MAY be present in the message.
+---------------------------+ +---------------------------+
| Message Type | | Message Type |
+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA| Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA|
----------------------+---+---+---+---+---+---+---+ ----------------------+---+---+---+---+---+---+---+
Algorithm | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
AUTH | 0 |0-1|0-1|0-1|0-1|0-1|0-1| AUTH | 0 |0-1|0-1|0-1|0-1|0-1|0-1|
EAP-Payload | 0 |0-1|0-1| 0 | 0 | 0 | 0 | EAP-Payload | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
Integrity-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
Key-Id | 0 |0-1|0-1| 0 | 0 | 0 | 0 | Key-Id | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
Nonce | 0 |0-1|0-1| 0 | 0 | 0 | 0 | Nonce | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
PRF-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
Result-Code | 0 |0-1| 0 | 0 | 0 | 0 | 0 | Result-Code | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
Session-Lifetime | 0 |0-1| 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
Termination-Cause | 0 | 0 | 0 | 1 | 0 | 0 | 0 | Termination-Cause | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
----------------------+---+---+---+---+---+---+---+ ----------------------+---+---+---+---+---+---+---+
Figure 4: AVP Occurrence Table Figure 4: AVP Occurrence Table
8.1. Algorithm AVP 8.1. AUTH AVP
The Algorithm AVP (AVP Code 1) is used for conveying the
pseudo-random function to derive PANA_AUTH_KEY as well as the
integrity algorithm to compute an AUTH AVP. The AVP data is of type
Unsigned32.
The first 16-bit of the AVP data contains an IKEv2 Transform ID of
Transform Type 2 [RFC4306] corresponding to the key derivation
function.
The last 16-bit of the AVP data contains an IKEv2 Transform ID of
Transform Type 3 [RFC4306] for the integrity algorithm.
All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104] for
the key derivation algorithm and AUTH_HMAC_SHA1_160 (7) [RFC4595]
corresponding to the integrity algorithm.
8.2. AUTH AVP
The AUTH AVP (AVP Code 2) is used to integrity protect PANA messages. The AUTH AVP (AVP Code 1) is used to integrity protect PANA messages.
The AVP data payload contains the Message Authentication Code encoded The AVP data payload contains the Message Authentication Code encoded
in network byte order. The AVP length varies depending on the in network byte order. The AVP length varies depending on the
integrity algorithm specified in an Algorithm AVP. The AVP data is integrity algorithm used. The AVP data is of type OctetString.
of type OctetString.
8.3. EAP-Payload AVP 8.2. EAP-Payload AVP
The EAP-Payload AVP (AVP Code 3) is used for encapsulating the actual The EAP-Payload AVP (AVP Code 2) is used for encapsulating the actual
EAP message that is being exchanged between the EAP peer and the EAP EAP message that is being exchanged between the EAP peer and the EAP
authenticator. The AVP data is of type OctetString. authenticator. The AVP data is of type OctetString.
8.3. Integrity-Algorithm AVP
The Integrity-Algorithm AVP (AVP Code 3) is used for conveying the
the integrity algorithm to compute an AUTH AVP. The AVP data is of
type Unsigned32. The AVP data contains an IKEv2 Transform ID of
Transform Type 3 [RFC4306] for the integrity algorithm. All PANA
implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595].
8.4. Key-Id AVP 8.4. Key-Id AVP
The Key-Id AVP (AVP Code 4) is of type Integer32, and contains an MSK The Key-Id AVP (AVP Code 4) is of type Integer32, and contains an MSK
identifier. The MSK identifier is assigned by PAA and MUST be unique identifier. The MSK identifier is assigned by PAA and MUST be unique
within the PANA session. within the PANA session.
8.5. Nonce AVP 8.5. Nonce AVP
The Nonce AVP (AVP Code 5) carries a randomly chosen value that is The Nonce AVP (AVP Code 5) carries a randomly chosen value that is
used in cryptographic key computations. The recommendations in used in cryptographic key computations. The recommendations in
skipping to change at page 33, line 13 skipping to change at page 33, line 4
case of HMAC-SHA1). case of HMAC-SHA1).
2. The PaC and the PAA each are not trusted with regard to the 2. The PaC and the PAA each are not trusted with regard to the
computation of a random nonce (according to [RFC4086]). The computation of a random nonce (according to [RFC4086]). The
length of the nonce has to have the full length of the PRF key length of the nonce has to have the full length of the PRF key
(e.g., 20 octets in the case of HMAC-SHA1). (e.g., 20 octets in the case of HMAC-SHA1).
Furthermore, the strongest available PRF available for PANA has to be Furthermore, the strongest available PRF available for PANA has to be
considered in this computation. Currently, only a single PRF (namely considered in this computation. Currently, only a single PRF (namely
HMAC-SHA1) is available and therefore the maximum output length is 20 HMAC-SHA1) is available and therefore the maximum output length is 20
octets). The maximum length of the nonce value in PANA Version 1 octets). The maximum length of the nonce value SHOULD be therefore
SHOULD be therefore 20 octets. 20 octets.
8.6. Result-Code AVP 8.6. PRF-Algorithm AVP
The Result-Code AVP (AVP Code 6) is of type Unsigned32 and indicates The PRF-Algorithm AVP (AVP Code 6) is used for conveying the pseudo-
random function to derive PANA_AUTH_KEY. The AVP data is of type
Unsigned32. The AVP data contains an IKEv2 Transform ID of Transform
Type 2 [RFC4306]. All PANA implementations MUST support
PRF_HMAC_SHA1 (2) [RFC2104].
8.7. Result-Code AVP
The Result-Code AVP (AVP Code 7) is of type Unsigned32 and indicates
whether an EAP authentication was completed successfully. Result- whether an EAP authentication was completed successfully. Result-
Code AVP values are described below. Code AVP values are described below.
PANA_SUCCESS 0 PANA_SUCCESS 0
Both authentication and authorization processes are successful. Both authentication and authorization processes are successful.
PANA_AUTHENTICATION_REJECTED 1 PANA_AUTHENTICATION_REJECTED 1
Authentication has failed. When this error is returned, When Authentication has failed. When authentication fails,
authentication fails, authorization is also considered to have authorization is also considered to have failed.
failed.
PANA_AUTHORIZATION_REJECTED 2 PANA_AUTHORIZATION_REJECTED 2
The authorization process has failed. This error could occur when The authorization process has failed. This error could occur when
authorization is rejected by a AAA server or rejected locally by a authorization is rejected by a AAA server or rejected locally by a
PAA, even if the authentication procedure has succeeded. PAA, even if the authentication procedure has succeeded.
8.7. Session-Lifetime AVP 8.8. Session-Lifetime AVP
The Session-Lifetime AVP (AVP Code 7) contains the number of seconds The Session-Lifetime AVP (AVP Code 8) contains the number of seconds
remaining before the current session is considered expired. The AVP remaining before the current session is considered expired. The AVP
data is of type Unsigned32. data is of type Unsigned32.
8.8. Termination-Cause AVP 8.9. Termination-Cause AVP
The Termination-Cause AVP (AVP Code 8) is used for indicating the The Termination-Cause AVP (AVP Code 9) is used for indicating the
reason why a session is terminated by the requester. The AVP data is reason why a session is terminated by the requester. The AVP data is
of type Enumerated. The following Termination-Cause data values are of type Enumerated. The following Termination-Cause data values are
used with PANA. used with PANA.
LOGOUT 1 (PaC -> PAA) LOGOUT 1 (PaC -> PAA)
The client initiated a disconnect The client initiated a disconnect
ADMINISTRATIVE 4 (PAA -> PaC) ADMINISTRATIVE 4 (PAA -> PaC)
skipping to change at page 35, line 20 skipping to change at page 35, line 20
PANA retransmission timers are based on the model used in DHCPv6 PANA retransmission timers are based on the model used in DHCPv6
[RFC3315]. Variables used here are also borrowed from this [RFC3315]. Variables used here are also borrowed from this
specification. PANA is a request/response-based protocol. The specification. PANA is a request/response-based protocol. The
message exchange terminates when the requester successfully receives message exchange terminates when the requester successfully receives
the answer or the message exchange is considered to have failed the answer or the message exchange is considered to have failed
according to the retransmission mechanism described below. according to the retransmission mechanism described below.
The retransmission behavior is controlled and described by the The retransmission behavior is controlled and described by the
following variables: following variables:
RT Retransmission timeout RT Retransmission timeout from the previous
(re)transmission
IRT Initial retransmission time IRT Base value for RT for the initial retransmission
MRC Maximum retransmission count MRC Maximum retransmission count
MRT Maximum retransmission time MRT Maximum retransmission time
MRD Maximum retransmission duration MRD Maximum retransmission duration
RAND Randomization factor RAND Randomization factor
With each message transmission or retransmission, the sender sets RT With each message transmission or retransmission, the sender sets RT
skipping to change at page 35, line 46 skipping to change at page 35, line 47
Each of the computations of a new RT include a randomization factor Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution (RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages. minimize synchronization of messages.
The algorithm for choosing a random number does not need to be The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation. sequence of random numbers from each invocation.
RT for the first message transmission is based on IRT: RT for the first message retransmission is based on IRT:
RT = IRT + RAND*IRT RT = IRT + RAND*IRT
RT for each subsequent message retransmission is based on the RT for each subsequent message retransmission is based on the
previous value of RT: previous value of RT:
RT = 2*RTprev + RAND*RTprev RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0, randomization added by the use of RAND). If MRT has a value of 0,
skipping to change at page 37, line 39 skipping to change at page 37, line 39
An IANA registry for PANA needs to be created by IANA. An IANA registry for PANA needs to be created by IANA.
10.1. PANA UDP Port Number 10.1. PANA UDP Port Number
PANA uses one well-known UDP port number Section 6.1), which needs to PANA uses one well-known UDP port number Section 6.1), which needs to
be assigned by the IANA. be assigned by the IANA.
10.2. PANA Message Header 10.2. PANA Message Header
As defined in Section 6.2, the PANA message header contains three As defined in Section 6.2, the PANA message header contains two
fields that requires IANA namespace management; the Version, Message fields that requires IANA namespace management; the Message Type and
Type and Flags fields. Flags fields.
10.2.1. Version
The Version namespace is used to identify PANA versions. The Version
values are assigned by Standards Action [IANA]. This document
defines the Version 1.
10.2.2. Message Type 10.2.1. Message Type
The Message Type namespace is used to identify PANA messages. The The Message Type namespace is used to identify PANA messages. The
range of values 0 - 65,519 are for permanent, standard message types, range of values 0 - 65,519 are for permanent, standard message types,
allocated by IETF Consensus [IANA]. This document defines the range allocated by IETF Consensus [IANA]. This document defines the range
of values 1 - 4. The same Message Type is used for both the request of values 1 - 4. The same Message Type is used for both the request
and the answer messages, except for type 1. The Request bit and the answer messages, except for type 1. The Request bit
distinguishes requests from answers. See Section 7 for the distinguishes requests from answers. See Section 7 for the
assignment of the namespace in this specification. assignment of the namespace in this specification.
The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 - The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 -
0xffff) are reserved for experimental messages. As these codes are 0xffff) are reserved for experimental messages. As these codes are
only for experimental and testing purposes, no guarantee is made for only for experimental and testing purposes, no guarantee is made for
interoperability between the communicating PaC and PAA using interoperability between the communicating PaC and PAA using
experimental commands, as outlined in [IANA-EXP]. experimental commands, as outlined in [IANA-EXP].
10.2.3. Flags 10.2.2. Flags
There are 16 bits in the Flags field of the PANA message header. There are 16 bits in the Flags field of the PANA message header.
This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A') and 4 This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4 ('P')
('P') in Section 6.2. The remaining bits MUST only be assigned via a and 5 ('I') in Section 6.2. The remaining bits MUST only be assigned
Standards Action [IANA]. via a Standards Action [IANA].
10.3. AVP Header 10.3. AVP Header
As defined in Section 6.3, the AVP header contains three fields that As defined in Section 6.3, the AVP header contains three fields that
requires IANA namespace management; the AVP Code, AVP Flags and requires IANA namespace management; the AVP Code, AVP Flags and
Vendor-Id fields where only the AVP Code and AVP Flags create new Vendor-Id fields where only the AVP Code and AVP Flags create new
namespaces. namespaces.
10.3.1. AVP Code 10.3.1. AVP Code
The 16-bit AVP Code namespace is used to identify attributes. There The 16-bit AVP Code namespace is used to identify attributes. There
are multiple namespaces. Vendors can have their own AVP Codes are multiple namespaces. Vendors can have their own AVP Codes
namespace which will be identified by their Vendor-ID (also known as namespace which will be identified by their Vendor-ID (also known as
Enterprise-Number) and they control the assignments of their Enterprise-Number) and they control the assignments of their
vendor-specific AVP codes within their own namespace. The absence of vendor-specific AVP codes within their own namespace. The absence of
a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace. a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace.
The AVP Codes and sometimes also possible values in an AVP are The AVP Codes and sometimes also possible values in an AVP are
controlled and maintained by IANA. controlled and maintained by IANA.
AVP Code 0 is not used. This document defines the AVP Codes 1-8. AVP Code 0 is not used. This document defines the AVP Codes 1-9.
See Section 8.1 through Section 8.8 for the assignment of the See Section 8.1 through Section 8.9 for the assignment of the
namespace in this specification. namespace in this specification.
AVPs may be allocated following Designated Expert Review with AVPs may be allocated following Designated Expert Review with
Specification Required [IANA] or Standards Action. AVPs with the 'M' Specification Required [IANA] or Standards Action.
(Mandatory) bit set MUST be allocated by Standards Action.
Note that PANA defines a mechanism for Vendor-Specific AVPs, where Note that PANA defines a mechanism for Vendor-Specific AVPs, where
the Vendor-Id field in the AVP header is set to a non-zero value. the Vendor-Id field in the AVP header is set to a non-zero value.
Vendor-Specific AVPs codes are for Private Use and should be Vendor-Specific AVPs codes are for Private Use and should be
encouraged instead of allocation of global attribute types, for encouraged instead of allocation of global attribute types, for
functions specific only to one vendor's implementation of PANA, where functions specific only to one vendor's implementation of PANA, where
no interoperability is deemed useful. Where a Vendor-Specific AVP is no interoperability is deemed useful. Where a Vendor-Specific AVP is
implemented by more than one vendor, allocation of global AVPs should implemented by more than one vendor, allocation of global AVPs should
be encouraged instead. be encouraged instead.
10.3.2. Flags 10.3.2. Flags
There are 16 bits in the AVP Flags field of the AVP header, defined There are 16 bits in the AVP Flags field of the AVP header, defined
in Section 6.3. This document assigns bit 0 ('V') and bit 1 ('M'). in Section 6.3. This document assigns bit 0 ('V'). The remaining
The remaining bits should only be assigned via a Standards Action . bits should only be assigned via a Standards Action .
10.4. AVP Values 10.4. AVP Values
Certain AVPs in PANA define a list of values with various meanings. Certain AVPs in PANA define a list of values with various meanings.
For attributes other than those specified in this section, adding For attributes other than those specified in this section, adding
additional values to the list can be done on a First Come, First additional values to the list can be done on a First Come, First
Served basis by IANA [IANA]. Served basis by IANA [IANA].
10.4.1. Result-Code AVP Values 10.4.1. Result-Code AVP Values
As defined in Section 8.6 the Result-Code AVP (AVP Code 6) defines As defined in Section 8.7 the Result-Code AVP (AVP Code 7) defines
the values 0-2. the values 0-2.
All remaining values are available for assignment via IETF Consensus All remaining values are available for assignment via IETF Consensus
[IANA]. [IANA].
10.4.2. Termination-Cause AVP Values 10.4.2. Termination-Cause AVP Values
As defined in Section 8.8, the Termination-Cause AVP (AVP Code 8) As defined in Section 8.9, the Termination-Cause AVP (AVP Code 9)
defines the values 1, 4 and 8. defines the values 1, 4 and 8.
All remaining values are available for assignment via IETF Consensus All remaining values are available for assignment via IETF Consensus
[IANA]. [IANA].
11. Security Considerations 11. Security Considerations
The PANA protocol defines a UDP-based EAP encapsulation that runs The PANA protocol defines a UDP-based EAP encapsulation that runs
between two IP-enabled nodes. Various security threats that are between two IP-enabled nodes. Various security threats that are
relevant to a protocol of this nature are outlined in [RFC4016]. relevant to a protocol of this nature are outlined in [RFC4016].
Security considerations stemming from the use of EAP and EAP methods Security considerations stemming from the use of EAP and EAP methods
are discussed in [RFC3748] [I-D.ietf-eap-keying]. This section are discussed in [RFC3748] [I-D.ietf-eap-keying]. This section
provides a discussion on the security-related issues that are related provides a discussion on the security-related issues that are related
to PANA framework and protocol design. to PANA framework and protocol design.
An important element in assessing security of PANA design and An important element in assessing security of PANA design and
deployment in a network is the presence of lower-layer (physical and deployment in a network is the presence of lower-layer security. In
link-layer) security. In the context of this document, lower-layers the context of this document, lower-layers are said to be secure if
are said to be secure if they can prevent eavesdropping and spoofing the environment provides adequate protection against spoofing and
of packets. Examples of such networks are physically-secured DSL confidentiality based on its operational needs. For example, DSL and
networks and 3GPP2 networks with cryptographically-secured cdma2000 cdma2000 networks' lower-layer security is enabled even before
link-layer. In these examples, the lower-layer security is enabled running the first PANA-based authentication. In the absence of such
even before running the first PANA-based authentication. In the a pre-established secure channel prior to running PANA, one can be
absence of such a pre-established secure channel prior to running created after the successful PANA authentication using a link-layer
PANA, one needs to be created after the successful PANA or network-layer cryptographic mechanism (e.g., IPsec).
authentication using a link-layer or network-layer cryptographic
mechanism (e.g., IPsec).
11.1. General Security Measures 11.1. General Security Measures
PANA provides multiple mechanisms to secure a PANA session. PANA provides multiple mechanisms to secure a PANA session.
PANA messages carry sequence numbers, which are monotonically PANA messages carry sequence numbers, which are monotonically
incremented by 1 with every new request message. These numbers are incremented by 1 with every new request message. These numbers are
randomly initialized at the beginning of the session, and verified randomly initialized at the beginning of the session, and verified
against expected numbers upon receipt. A message whose sequence against expected numbers upon receipt. A message whose sequence
number is different than the expected one is silently discarded. In number is different than the expected one is silently discarded. In
skipping to change at page 41, line 48 skipping to change at page 41, line 46
The initial PANA-Auth-Request and PANA-Auth-Answer exchange is The initial PANA-Auth-Request and PANA-Auth-Answer exchange is
vulnerable to spoofing attacks as these messages are not vulnerable to spoofing attacks as these messages are not
authenticated and integrity protected. In order to prevent very authenticated and integrity protected. In order to prevent very
basic DoS attacks an adversary should not be able to cause state basic DoS attacks an adversary should not be able to cause state
creation by sending PANA-Client-Initiation messages to the PAA. This creation by sending PANA-Client-Initiation messages to the PAA. This
protection is achieved by allowing the responder (PAA) to create as protection is achieved by allowing the responder (PAA) to create as
little amount of state as possible in the initial message exchange. little amount of state as possible in the initial message exchange.
However, it is difficult to prevent all spoofing attacks in the However, it is difficult to prevent all spoofing attacks in the
initial message exchange entirely. initial message exchange entirely.
In networks where lower-layers are not secured prior to running PANA,
the capability discovery enabled through inclusion of an Algorithm
AVP in the initial PANA-Auth-Request message is susceptible to
spoofing leading to DoS attacks. Therefore, usage of this AVP during
the initial message exchange in such insecure networks is NOT
RECOMMENDED. The same AVP is delivered with integrity protection via
the last PANA-Auth-Request message upon successful authentication.
11.3. EAP Methods 11.3. EAP Methods
Eavesdropping EAP messages might cause problems when the EAP method Eavesdropping EAP messages might cause problems when the EAP method
is weak and enables dictionary or replay attacks or even allows an is weak and enables dictionary or replay attacks or even allows an
adversary to learn the long-term password directly. Furthermore, if adversary to learn the long-term password directly. Furthermore, if
the optional EAP Response/Identity payload is used then it allows the the optional EAP Response/Identity payload is used then it allows the
adversary to learn the identity of the PaC. In such a case a privacy adversary to learn the identity of the PaC. In such a case a privacy
problem is prevalent. problem is prevalent.
To prevent these threats, [I-D.ietf-pana-framework] suggests using To prevent these threats, [I-D.ietf-pana-framework] suggests using
skipping to change at page 42, line 50 skipping to change at page 42, line 39
Networks that are not secured at the lower-layers prior to running Networks that are not secured at the lower-layers prior to running
PANA can rely on enabling per-packet data traffic ciphering upon PANA can rely on enabling per-packet data traffic ciphering upon
successful PANA SA establishment. The PANA framework allows successful PANA SA establishment. The PANA framework allows
generation of cryptographic keys from the PANA SA and use the keys generation of cryptographic keys from the PANA SA and use the keys
with a secure association protocol to enable per-packet cryptographic with a secure association protocol to enable per-packet cryptographic
protection such as link-layer or IPsec-based ciphering protection such as link-layer or IPsec-based ciphering
[I-D.ietf-pana-ipsec]. These mechanisms ultimately establish a [I-D.ietf-pana-ipsec]. These mechanisms ultimately establish a
cryptographic binding between the data traffic generated by and for a cryptographic binding between the data traffic generated by and for a
client and the authenticated identity of the client. Data traffic client and the authenticated identity of the client. Data traffic
must be minimally data origin authenticated, replay and integrity can be data origin authenticated, replay and integrity protected, and
protected, and optionally encrypted. How cryptographic keys are optionally encrypted using the cryptographic keys. How these keys
generated from the PANA SA and used with a secure association are generated from the PANA SA and used with a secure association
protocol is outside the scope of this document. protocol is outside the scope of this document.
11.6. PAA-to-EP Communication 11.6. PAA-to-EP Communication
The PANA framework allows separation of PAA from EP. SNMPv3 The PANA framework allows separation of PAA from EP. The protocol
[I-D.ietf-pana-snmp] MAY be used between the PAA and EP for exchange between the PAA and EP for provisioning authorized PaC
provisioning authorized PaC information on the EP. This exchange information on the EP must be protected for authentication, integrity
MUST be always physically or cryptographically protected for and replay protection.
authentication, integrity and replay protection.
11.7. Liveness Test 11.7. Liveness Test
A PANA session is associated with a session lifetime. The session is A PANA session is associated with a session lifetime. The session is
terminated unless it is refreshed by a new round of EAP terminated unless it is refreshed by a new round of EAP
authentication before it expires. Therefore, at the latest a authentication before it expires. Therefore, at the latest a
disconnected client can be detected when its session expires. A disconnected client can be detected when its session expires. A
disconnect may also be detected earlier by using PANA ping messages. disconnect may also be detected earlier by using PANA ping messages.
A request message can be generated by either PaC or PAA at any time A request message can be generated by either PaC or PAA at any time
in access phase, expecting the peer to respond with an answer in access phase, expecting the peer to respond with an answer
skipping to change at page 46, line 30 skipping to change at page 46, line 30
Parthasarathy, M., "PANA Enabling IPsec based Access Parthasarathy, M., "PANA Enabling IPsec based Access
Control", draft-ietf-pana-ipsec-07 (work in progress), Control", draft-ietf-pana-ipsec-07 (work in progress),
July 2005. July 2005.
[I-D.ietf-pana-framework] [I-D.ietf-pana-framework]
Jayaraman, P., "Protocol for Carrying Authentication for Jayaraman, P., "Protocol for Carrying Authentication for
Network Access (PANA) Framework", Network Access (PANA) Framework",
draft-ietf-pana-framework-09 (work in progress), draft-ietf-pana-framework-09 (work in progress),
June 2007. June 2007.
[I-D.ietf-pana-snmp]
Mghazli, Y., "SNMP usage for PAA-EP interface",
draft-ietf-pana-snmp-06 (work in progress), June 2006.
[ianaweb] IANA, "Number assignment", http://www.iana.org. [ianaweb] IANA, "Number assignment", http://www.iana.org.
[IANA-EXP] [IANA-EXP]
Narten, T., "Assigning Experimental and Testing Numbers Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
Authors' Addresses Authors' Addresses
Dan Forsberg Dan Forsberg
Nokia Research Center Nokia Research Center
 End of changes. 102 change blocks. 
261 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/