draft-ietf-pana-pana-16.txt   draft-ietf-pana-pana-17.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 14, 2007 Toshiba Expires: December 19, 2007 Toshiba
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
A. Yegin A. Yegin
Samsung Samsung
June 12, 2007 June 17, 2007
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-16 draft-ietf-pana-pana-17
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 14, 2007. This Internet-Draft will expire on December 19, 2007.
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 43 skipping to change at page 2, line 43
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) . . . . . . . . . . . . . . . . . 28
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) . . . . . . . . . . . . . . 29
7.6. PANA-Notification-Request (PNR) . . . . . . . . . . . . . 29 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. Algorithm AVP . . . . . . . . . . . . . . . . . . . . . . 31
8.2. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. AUTH AVP . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.3. EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 32 8.3. EAP-Payload 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. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 33
8.7. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 33 8.7. Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 33
8.8. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 33 8.8. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 33
skipping to change at page 6, line 20 skipping to change at page 6, line 20
by sharing cryptographic keying material and associated context. by sharing cryptographic keying material and associated context.
The formed duplex security association is used to protect the The formed duplex security association is used to protect the
bidirectional PANA signaling traffic between the PaC and PAA. bidirectional PANA signaling traffic between the PaC and PAA.
Enforcement Point (EP): Enforcement Point (EP):
A node on the access network where per-packet enforcement policies A node on the access network where per-packet enforcement policies
(i.e., filters) are applied on the inbound and outbound traffic of (i.e., filters) are applied on the inbound and outbound traffic of
access devices. The EP and the PAA may be co-located. EPs should access devices. The EP and the PAA may be co-located. EPs should
prevent data traffic from and to any unauthorized client unless prevent data traffic from and to any unauthorized client unless
it's either PANA or one of the other allowed traffic types (e.g., that data traffic is either PANA or one of the other allowed
ARP, IPv6 neighbor discovery, DHCP, etc.). traffic types (e.g., ARP, IPv6 neighbor discovery, DHCP, etc.).
Master Session Key (MSK): Master Session Key (MSK):
A key derived by the EAP peer and the EAP server and transported A key derived by the EAP peer and the EAP server and transported
to the EAP authenticator [RFC3748]. to the EAP authenticator [RFC3748].
For additional terminology definitions see the PANA framework For additional terminology definitions see the PANA framework
document [I-D.ietf-pana-framework]. document [I-D.ietf-pana-framework].
3. Protocol Overview 3. Protocol Overview
The PANA protocol is run between a client (PaC) and a server (PAA) in The PANA protocol is run between a client (PaC) and a server (PAA) in
order to perform authentication and authorization for the network order to perform authentication and authorization for the network
access service. access service.
The protocol messaging consists of a series of requests and answers, The protocol messaging consists of a series of requests and answers,
some of which may be initiated by either end. Each message can carry some of which may be initiated by either end. Each message can carry
zero or more AVPs within the payload. The main payload of PANA is zero or more AVPs (Attribute-Value Pairs) within the payload. The
EAP which performs authentication. PANA helps the PaC and PAA main payload of PANA is EAP which performs authentication. PANA
establish an EAP session. helps the PaC and PAA establish an EAP session.
PANA is a UDP-based protocol. It has its own retransmission PANA is a UDP-based protocol. It has its own retransmission
mechanism to reliably deliver messages. mechanism to reliably deliver messages.
PANA messages are sent between the PaC and PAA as part of a PANA PANA messages are sent between the PaC and PAA as part of a PANA
session. A PANA session consists of distinct phases: session. A PANA session consists of distinct phases:
o Authentication and authorization phase: This is the phase that o Authentication and authorization phase: This is the phase that
initiates a new PANA session and executes EAP between the PAA and initiates a new PANA session and executes EAP between the PAA and
PaC. The PANA session can be initiated by both the PaC and the PaC. The PANA session can be initiated by both the PaC and the
skipping to change at page 9, line 47 skipping to change at page 9, line 47
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.
The initial PANA-Auth-Request and PANA-Auth-Answer messages MUST have The initial PANA-Auth-Request and PANA-Auth-Answer messages MUST have
'S' (Start) bit set, regardless of whether the session is initiated the 'S' (Start) bit set, regardless of whether the session is
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
'S' bit set. the 'S' (Start) bit set.
The PAA SHOULD limit the rate it processes incoming PANA-Client- It is recommended that the PAA limit the rate it processes incoming
Initiation messages to provide robustness against denial-of service PANA-Client-Initiation messages to provide robustness against
(DoS) attacks. Details of rate limiting are outside the scope of denial-of service (DoS) attacks. Details of rate limiting are
this specification. outside the scope of this specification.
An Algorithm AVP MAY be included in the initial PANA-Auth-Request in An Algorithm AVP MAY be included in the initial PANA-Auth-Request in
order to indicate required and available capabilities for the network order to indicate required and available capabilities for the network
access. This AVP MAY be used by the PaC for assessing the capability access. This AVP MAY be used by the PaC for assessing the capability
match even before the authentication takes place. Since this AVP is match even before the authentication takes place. Since this AVP is
provided in the insecure initial request, there are certain security provided in the insecure initial request, there are certain security
risks involved in using the provided information. See Section 11 for risks involved in using the provided information. See Section 11 for
further discussion on this. further discussion on this.
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 SHOULD NOT include an EAP-Payload PANA-Client-Initiation message, it doesn't include an EAP-Payload AVP
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
session at the same time, i.e., the PAA unsolicitedly sends the session at the same time, i.e., the PAA unsolicitedly sends the
initial PANA-Auth-Request message while the PaC sends a initial PANA-Auth-Request message while the PaC sends a
PANA-Client-Initiation message. To resolve the race condition, the PANA-Client-Initiation message. To resolve the race condition, the
PAA SHOULD silently discard the PANA-Client-Initiation message PAA MUST silently discard the PANA-Client-Initiation message received
received from the PaC after it has sent the initial PANA-Auth-Request from the PaC after it has sent the initial PANA-Auth-Request message.
message. The PAA uses the source IP address and the source port The PAA uses the source IP address and the source port number of the
number of the PANA-Client-Initiation message to identify the PaC PANA-Client-Initiation message to identify the PaC among multiple
among multiple PANA-Client-Initiation messages sent from different PANA-Client-Initiation messages sent from different PaCs.
PaCs.
EAP messages are carried in PANA-Auth-Request messages. EAP messages are carried in PANA-Auth-Request messages.
PANA-Auth-Answer messages are simply used to acknowledge receipt of PANA-Auth-Answer messages are simply used to acknowledge receipt of
the requests. As an optimization, a PANA-Auth-Answer message sent the requests. As an optimization, a PANA-Auth-Answer message sent
from the PaC MAY include the EAP message. This optimization SHOULD from the PaC MAY include the EAP message. This optimization SHOULD
NOT be used when it takes time to generate the EAP message (due to, NOT be used when it takes time to generate the EAP message (due to,
e.g., intervention of human input), in which case returning an e.g., intervention of human input), in which case returning an
PANA-Auth-Answer message without piggybacking an EAP message can PANA-Auth-Answer message without piggybacking an EAP message can
avoid unnecessary retransmission of the PANA-Auth-Request message. avoid unnecessary retransmission of the PANA-Auth-Request message.
A Nonce AVP MUST be included in the first PANA-Auth-Request and A Nonce AVP MUST be included in the first PANA-Auth-Request and
PANA-Auth-Answer messages following the initial PANA-Auth-Request and PANA-Auth-Answer messages following the initial PANA-Auth-Request and
PANA-Auth-Answer messages (i.e. with 'S' (Start) bit set), and MUST PANA-Auth-Answer messages (i.e. with the 'S' (Start) bit set), and
NOT be included in any other message, except during re-authentication MUST NOT be included in any other message, except during re-
procedures (see Section 4.3). authentication procedures (see Section 4.3).
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 'C' PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'C'
(Complete) bit set, and any other message MUST NOT have 'C' bit set. (Complete) bit set, and any other message MUST NOT have the 'C'
Figure 1 shows an example sequence in the authentication and (Complete) bit set. Figure 1 shows an example sequence in the
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) // 'S' bit set <----- PANA-Auth-Request(x) // The 'S' (Start) bit set
-----> PANA-Auth-Answer(x) // 'S' bit set -----> PANA-Auth-Answer(x) // The 'S' (Start) bit set
<----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload]
-----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP -----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP
-----> PANA-Auth-Request(y)[EAP-Payload] -----> PANA-Auth-Request(y)[EAP-Payload]
<----- PANA-Auth-Answer(y) <----- PANA-Auth-Answer(y)
<----- PANA-Auth-Request(x+2)[EAP-Payload] <----- PANA-Auth-Request(x+2)[EAP-Payload]
-----> PANA-Auth-Answer(x+2)[EAP-Payload] -----> PANA-Auth-Answer(x+2)[EAP-Payload]
// Piggybacking EAP // Piggybacking EAP
<----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload,
Key-Id, Algorithm, Key-Id, Algorithm,
Session-Lifetime, AUTH] Session-Lifetime, AUTH]
// 'C' bit set // The 'C' (Complete) bit set
-----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH]
// 'C' bit set // 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 When an EAP method that is capable of deriving keys is used during
the authentication and authorization phase and the keys are the authentication and authorization phase and the keys are
successfully derived, the last PANA-Auth-Request message with 'C' successfully derived, the last PANA-Auth-Request message with the 'C'
(Complete) bit set MUST contain a Key-Id AVP and an AUTH AVP, and an (Complete) bit set MUST contain a Key-Id AVP and an AUTH AVP, and an
Algorithm AVP for the first derivation of keys in the session, and Algorithm AVP for the first derivation of keys in the session, and
any subsequent message MUST contain an AUTH AVP. An Algorithm AVP any subsequent message MUST contain an AUTH AVP. An Algorithm AVP
MUST NOT be contained in any PANA-Auth-Request message after the MUST NOT be contained in any PANA-Auth-Request message after the
first derivation of keys in the session. 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 'C' (Complete) bit set MUST be protected with an AUTH messages with the 'C' (Complete) bit set MUST be protected with an
AVP and carry a Key-Id AVP. The last PANA-Auth-Request message MUST AUTH AVP and carry a Key-Id AVP. The last PANA-Auth-Request message
also carry an Algorithm AVP if it is for the first derivation of keys MUST also carry an Algorithm AVP if it is for the first derivation of
in the session. The PANA session MUST be terminated immediately keys in the session. The PANA session MUST be terminated immediately
after the last PANA-Auth message exchange. after the last PANA-Auth message exchange.
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 '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
PaC and the PAA are allowed to send a ping request to the PaC and the PAA are allowed to send a ping request to the
communicating peer whenever they need to make sure the availability communicating peer whenever they need to ensure the availability of
of the session on the peer and expect the peer to return a ping the session on the peer and expect the peer to return a ping answer
answer message. The ping request and answer messages MUST be message. The ping request and answer messages MUST be protected with
protected with an AUTH AVP when a PANA SA is available. A ping an AUTH AVP when a PANA SA is available. A ping request MUST NOT be
request MUST NOT be sent in the authentication and authorization sent in the authentication and authorization phase, re-authentication
phase, re-authentication phase and termination phase. phase and termination phase.
Implementations MUST limit the rate of performing this test. The PaC Implementations MUST limit the rate of performing this test. The PaC
and the PAA can handle rate limitation on their own, they do not have and the PAA can handle rate limitation on their own, they do not have
to perform any coordination with each other. There is no negotiation to perform any coordination with each other. There is no negotiation
of timers for this purpose. Additionally, an implementation MAY of timers for this purpose. Additionally, an implementation MAY
rate-limit processing the incoming ping requests. It should be noted rate-limit processing the incoming ping requests. It should be noted
that if a PAA or PaC which considers its connectivity lost after a that if a PAA or PaC which considers its connectivity lost after a
relatively small number of unresponsive pings coupled with a peer relatively small number of unresponsive pings coupled with a peer
that is aggressively rate-limiting the ping request and answer that is aggressively rate-limiting the ping request and answer
messages, false-positives could result. Therefore, a PAA or PaC messages, false-positives could result. Therefore, a PAA or PaC
skipping to change at page 12, line 50 skipping to change at page 12, line 49
of connectivity. of connectivity.
4.3. Re-authentication Phase 4.3. Re-authentication Phase
The PANA session in the access phase can enter the re-authentication The PANA session in the access phase can enter the re-authentication
phase to extend the current session lifetime by re-executing EAP. phase to extend the current session lifetime by re-executing EAP.
Once the re-authentication phase successfully completes, the session Once the re-authentication phase successfully completes, the session
re-enters the access phase. Otherwise, the session is terminated. re-enters the access phase. Otherwise, the session is terminated.
When the PaC initiates re-authentication, it sends a When the PaC initiates re-authentication, it sends a
PANA-Notification-Request message with 'A' bit set (a PANA-Notification-Request message with the 'A' (re-Authentication)
re-authentication request message) to the PAA. This message MUST bit set (a re-authentication request message) to the PAA. This
contain the session identifier assigned to the session being message MUST contain the session identifier assigned to the session
re-authenticated. If the PAA already has an established PANA session being re-authenticated. If the PAA already has an established PANA
for the PaC with the matching session identifier, it MUST first session for the PaC with the matching session identifier, it MUST
respond with a PANA-Notification-Answer message with 'A' bit set (a first respond with a PANA-Notification-Answer message with the 'A'
re-authentication answer message), followed by a PANA-Auth-Request (re-Authentication) bit set (a re-authentication answer message),
message that starts a new EAP authentication. If the PAA cannot followed by a PANA-Auth-Request message that starts a new EAP
identify the session, it MUST silently discard the message. The authentication. If the PAA cannot identify the session, it MUST
first PANA-Auth-Request and PANA-Auth-Answer messages in the silently discard the message. The first PANA-Auth-Request and
re-authentication phase MUST have 'S' bit cleared and carry a Nonce PANA-Auth-Answer messages in the re-authentication phase MUST have
AVP. the 'S' (Start) bit cleared and carry a Nonce AVP.
The PaC may receive a PANA-Auth-Request before receiving the answer The PaC may receive a PANA-Auth-Request before receiving the answer
to its outstanding re-authentication request message. This condition to its outstanding re-authentication request message. This condition
can arise due to packet re-ordering or a race condition between the can arise due to packet re-ordering or a race condition between the
PaC and PAA when they both attempt to engage in re-authentication. PaC and PAA when they both attempt to engage in re-authentication.
The PaC MUST keep discarding the received PANA-Auth-Requests until it The PaC MUST keep discarding the received PANA-Auth-Requests until it
receives the answer to its request. receives the answer to its request.
When the PAA initiates re-authentication, it sends a When the PAA initiates re-authentication, it sends a
PANA-Auth-Request message containing the session identifier for the PANA-Auth-Request message containing the session identifier for the
skipping to change at page 14, line 7 skipping to change at page 14, line 7
For any re-authentication, if there is an established PANA SA, re- For any re-authentication, if there is an established PANA SA, re-
authentication request and answer messages and subsequent authentication request and answer messages and subsequent
PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected
with an AUTH AVP. The final PANA-Auth-Request and PANA-Auth-Answer with an AUTH AVP. The final PANA-Auth-Request and PANA-Auth-Answer
messages and any subsequent PANA message MUST be protected by using messages and any subsequent PANA message MUST be protected by using
the key generated from the latest EAP authentication. the key generated from the latest EAP authentication.
PaC PAA Message(sequence number)[AVPs] PaC PAA Message(sequence number)[AVPs]
------------------------------------------------------ ------------------------------------------------------
-----> PANA-Notification-Request(q)[AUTH] // 'A' bit set -----> PANA-Notification-Request(q)[AUTH]
<----- PANA-Notification-Answer(q)[AUTH] // 'A' bit set // The 'A' (re-Authentication) bit set
<----- PANA-Notification-Answer(q)[AUTH]
// 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, Algorithm,
Session-Lifetime, AUTH] Session-Lifetime, AUTH]
// 'C' bit set // The 'C' (Complete) bit set
-----> PANA-Auth-Answer(p+2)[Key-Id, AUTH]// 'C' bit set -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH]
// 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
initiated either from the PaC (i.e., disconnect indication) or from initiated either from the PaC (i.e., disconnect indication) or from
the PAA (i.e., session revocation). The PANA-Termination-Request and the PAA (i.e., session revocation). The PANA-Termination-Request and
PANA-Termination-Answer message exchanges are used for disconnect PANA-Termination-Answer message exchanges are used for disconnect
skipping to change at page 16, line 21 skipping to change at page 16, line 21
5.3. PANA Security Association 5.3. PANA Security Association
A PANA SA is created as an attribute of a PANA session when EAP A PANA SA is created as an attribute of a PANA session when EAP
authentication succeeds with a creation of an MSK. A PANA SA is not authentication succeeds with a creation of an MSK. A PANA SA is not
created when the PANA authentication fails or no MSK is produced by created when the PANA authentication fails or no MSK is produced by
the EAP authentication method. When a new MSK is derived in the PANA the EAP authentication method. When a new MSK is derived in the PANA
re-authentication phase, any key derived from the old MSK MUST be re-authentication phase, any key derived from the old MSK MUST be
updated to a new one that is derived from the new MSK. In order to updated to a new one that is derived from the new MSK. In order to
distinguish the new MSK from old ones, one Key-Id AVP MUST be carried distinguish the new MSK from old ones, one Key-Id AVP MUST be carried
in the last PANA-Auth-Request and PANA-Auth-Answer messages with 'C' in the last PANA-Auth-Request and PANA-Auth-Answer messages with the
(Complete) bit set at the end of the EAP authentication which 'C' (Complete) bit set at the end of the EAP authentication which
resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32 resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32
and MUST contain a value that uniquely identifies the MSK within the and MUST contain a value that uniquely identifies the MSK within the
PANA session. The last PANA-Auth-Answer message with 'C' (Complete) PANA session. The last PANA-Auth-Answer message with the 'C'
bit set in response to the last PANA-Auth-Request message with 'C' (Complete) bit set in response to the last PANA-Auth-Request message
(Complete) bit set MUST contain a Key-Id AVP with the same MSK with the 'C' (Complete) bit set MUST contain a Key-Id AVP with the
identifier carried in the request. The last PANA-Auth-Request and same MSK identifier carried in the request. The last
PANA-Auth-Answer messages with a Key-Id AVP MUST also carry an AUTH PANA-Auth-Request and PANA-Auth-Answer messages with a Key-Id AVP
AVP whose value is computed by using the new PANA_AUTH_KEY derived MUST also carry an AUTH AVP whose value is computed by using the new
from the new MSK. Although the specification does not mandate a PANA_AUTH_KEY derived from the new MSK. Although the specification
particular method for calculation of the Key-Id AVP value, a simple does not mandate a particular method for calculation of the Key-Id
method is to use monotonically increasing numbers. AVP value, a simple method is to use monotonically increasing
numbers.
The PANA session lifetime is bounded by the authorization lifetime The PANA session lifetime is bounded by the authorization lifetime
granted by the authentication server (same as the MSK lifetime). The granted by the authentication server (same as the MSK lifetime). The
lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the
lifetime of the PANA session. The created PANA SA is deleted when lifetime of the PANA session. The created PANA SA is deleted when
the corresponding PANA session is terminated. the corresponding PANA session is terminated.
PANA SA attributes as well as PANA session attributes are listed PANA SA attributes as well as PANA session attributes are listed
below: below:
skipping to change at page 20, line 11 skipping to change at page 20, line 11
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.
5.7. Session Lifetime 5.7. Session Lifetime
The authentication and authorization phase determines the PANA The authentication and authorization phase determines the PANA
session lifetime and the lifetime is indicated to the PaC When the session lifetime and the lifetime is indicated to the PaC When the
network access authorization succeeds. For this purpose, when the network access authorization succeeds. For this purpose, when the
last PANA-Auth-Request message (i.e., with 'C' (Complete) bit set) in last PANA-Auth-Request message (i.e., with the 'C' (Complete) bit
authentication and authorization phase or re-authentication phase set) in authentication and authorization phase or re-authentication
carries a Result-Code AVP with a value of PANA_SUCCESS, a Session- phase carries a Result-Code AVP with a value of PANA_SUCCESS, a
Lifetime AVP MUST also be carried in the message. A Session-Lifetime Session-Lifetime AVP MUST also be carried in the message. A Session-
AVP MUST be ignored when included in other PANA messages. Lifetime AVP MUST be ignored when included in other PANA messages.
The lifetime is a non-negotiable parameter that can be used by the The lifetime is a non-negotiable parameter that can be used by the
PaC to manage PANA-related state. The PaC MUST initiate the re- PaC to manage PANA-related state. The PaC MUST initiate the re-
authentication phase before the current session lifetime expires if authentication phase before the current session lifetime expires if
it wants to extend the session. it wants to extend the session.
The PaC and the PAA MAY use information obtained outside PANA (e.g., The PaC and the PAA MAY use information obtained outside PANA (e.g.,
lower-layer indications) to expedite the detection of a disconnected lower-layer indications) to expedite the detection of a disconnected
peer. Availability and reliability of such indications MAY depend on peer. Availability and reliability of such indications MAY depend on
a specific link-layer or network topology and are therefore only a specific link-layer or network topology and are therefore only
skipping to change at page 23, line 8 skipping to change at page 23, line 8
bit MUST be cleared. 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. The 16-bit address communicate the message type with the message. Message Type
space is managed by IANA [ianaweb]. allocation is managed by IANA [ianaweb].
Session Identifier Session Identifier
This field contains a 32 bit session identifier. This field contains a 32 bit session identifier.
Sequence Number Sequence Number
This field contains contains a 32 bit sequence number. This field contains contains a 32 bit sequence number.
AVPs AVPs
skipping to change at page 24, line 37 skipping to change at page 24, line 37
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 M r r r r r r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V (Vendor) V (Vendor)
The 'V' bit, known as the Vendor-Specific bit, indicates The 'V' (Vendor) bit indicates whether the optional Vendor-Id
whether the optional Vendor-Id field is present in the AVP field is present in the AVP header. When set the AVP Code
header. When set the AVP Code belongs to the specific vendor belongs to the specific vendor code address space.
code address space.
M (Mandatory) M (Mandatory)
The 'M' Bit, known as the Mandatory bit, indicates whether The 'M' (Mandatory) bit indicates whether support of the AVP is
support of the AVP is required. If an AVP with the 'M' bit set required. If an AVP with the 'M' (Mandatory) bit set is
is received by the PaC or PAA and either the AVP or its value received by the PaC or PAA and either the AVP or its value is
is unrecognized, the message MUST be considered as invalid. unrecognized, the message MUST be considered as invalid. AVPs
AVPs with the 'M' bit cleared are informational only and a with the 'M' (Mandatory) bit cleared are informational only and
receiver that receives a message with such an AVP that is not a receiver that receives a message with such an AVP that is not
recognized, or whose value is not recognized, MAY simply ignore recognized, or whose value is not recognized, MAY simply ignore
the AVP. 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
skipping to change at page 25, line 24 skipping to change at page 25, line 24
Length, AVP Flags, Reserved and Vendor-Id fields are not counted Length, AVP Flags, Reserved and Vendor-Id fields are not counted
in the AVP Length value. in the AVP Length value.
Reserved Reserved
This two-octet field is reserved for future use, and MUST be set This two-octet field is reserved for future use, and MUST be set
to zero, and ignored by the receiver. to zero, and ignored by the receiver.
Vendor-Id Vendor-Id
The Vendor-Id field is present if the 'V' bit is set in the AVP The Vendor-Id field is present if the 'V' (Vendor) bit is set in
Flags field. The optional four-octet Vendor-Id field contains the the AVP Flags field. The optional four-octet Vendor-Id field
IANA assigned "SMI Network Management Private Enterprise Codes" contains the IANA assigned "SMI Network Management Private
[ianaweb] value, encoded in network byte order. Any vendor Enterprise Codes" [ianaweb] value, encoded in network byte order.
wishing to implement a vendor-specific PANA AVP MUST use their own Any vendor wishing to implement a vendor-specific PANA AVP MUST
Vendor-Id along with their privately managed AVP address space, use their own Vendor-Id along with their privately managed AVP
guaranteeing that they will not collide with any other vendor's address space, guaranteeing that they will not collide with any
vendor-specific AVP(s), nor with future IETF applications. other vendor's vendor-specific AVP(s), nor with future IETF
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 Unless otherwise noted, AVPs defined in this document will have the
following default AVP Flags field settings: The 'M' bit MUST be set. following default AVP Flags field settings: The 'M' (Mandatory) bit
The 'V' bit MUST NOT be set. 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
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
Every PANA message defined MUST include a corresponding ABNF PANA message definitions include a corresponding ABNF [RFC4234]
[RFC2234] specification, which is used to define the AVPs that MUST specification, which is used to define the AVPs for that PANA message
or MAY be present. The following format is used in the definition: type, and whether or not each AVP is Mandatory. The following format
is used in the definition:
message-def = Message-Name "::=" PANA-message message-def = Message-Name "::=" 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 [ *fixed] [ *required] [ *optional]
[ *fixed] [ *fixed]
header = "< PANA-Header: " Message-Type header = "< PANA-Header: " Message-Type
[r-bit] [s-bit] [c-bit] [a-bit] [p-bit] ">" [r-bit] [s-bit] [c-bit] [a-bit] [p-bit] ">"
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' 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' 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' bit in the Message ; If present, the 'A' (re-Authentication) bit
; Flags is set, indicating that the message ; in the Message Flags is set, indicating that
; is a re-authentication request or answer. ; the message is a re-authentication request or
; answer.
p-bit = ", PIN" p-bit = ", PIN"
; If present, the 'P' 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 ">" fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP. ; Defines the fixed position of an AVP.
required = [qual] "{" avp-spec "}" required = [qual] "{" avp-spec "}"
; 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] "[" avp-name "]"
; 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 2234 Section 6.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
; be present. The default value is zero. ; be present. The default value is zero.
max = 1*DIGIT max = 1*DIGIT
skipping to change at page 28, line 45 skipping to change at page 28, line 48
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 'S' and 'C' bits set. The message MUST NOT have both the 'S' (Start) and 'C' (Complete)
bits set.
PANA-Auth-Request ::= < PANA-Header: 2, REQ[,STA][,COM] > PANA-Auth-Request ::= < PANA-Header: 2, REQ[,STA][,COM] >
[ EAP-Payload ] [ EAP-Payload ]
[ Algorithm ] [ Algorithm ]
[ Nonce ] [ Nonce ]
[ 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 'S' and 'C' bits set. The message MUST NOT have both the 'S' (Start) and 'C' (Complete)
bits set.
PANA-Auth-Answer ::= < PANA-Header: 2 [,STA][,COM] > PANA-Auth-Answer ::= < PANA-Header: 2 [,STA][,COM] >
[ Nonce ] [ Nonce ]
[ 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)
skipping to change at page 30, line 5 skipping to change at page 30, line 11
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 sent either by the PaC
or the PAA for signaling re-authentication and performing liveness or the PAA for signaling re-authentication and performing liveness
test. test.
The message MUST have one of 'A' and 'P' bits exclusively set. The message MUST have one of the 'A' (re-Authentication) and 'P'
(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 'A' and 'P' bits exclusively set. The message MUST have one of the 'A' (re-Authentication) and 'P'
(Ping) bits exclusively set.
PANA-Notification-Answer ::= < PANA-Header: 4, REQ[,REA][,PIN] > PANA-Notification-Answer ::= < PANA-Header: 4, REQ[,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.
skipping to change at page 32, line 43 skipping to change at page 32, line 43
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
[RFC4086] apply with regard to generation of random values. The AVP [RFC4086] apply with regard to generation of random values. The AVP
data is of type OctetString and it contains a randomly generated data is of type OctetString and it contains a randomly generated
value in opaque format. The data length MUST be between 8 and 256 value in opaque format. The data length MUST be between 8 and 256
octets inclusive. octets inclusive.
The length of the nonces are determined based on the available The length of the nonces are determined based on the available
pseudo-random functions (PRFs) and the degree of trust placed into pseudo-random functions (PRFs) and the degree of trust placed into
the two PaC and the PAA to compute random values. The length of the the PaC and the PAA to compute random values. The length of the
random value for the nonce is determined whether random value for the nonce is determined in one of the two ways,
depending on whether
1. The PaC and the PAA each are likely to be able to compute a 1. The PaC and the PAA each are likely to be able to compute a
random nonce (according to [RFC4086]). The length of the nonce random nonce (according to [RFC4086]). The length of the nonce
has to be 1/2 the length of the PRF key (e.g., 10 octets in the has to be 1/2 the length of the PRF key (e.g., 10 octets in the
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).
skipping to change at page 33, line 25 skipping to change at page 33, line 28
The Result-Code AVP (AVP Code 6) is of type Unsigned32 and indicates The Result-Code AVP (AVP Code 6) 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, it is Authentication has failed. When this error is returned, When
assumed that authorization is automatically failed. authentication fails, authorization is also considered to have
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.7. Session-Lifetime AVP
The Session-Lifetime AVP (AVP Code 7) contains the number of seconds The Session-Lifetime AVP (AVP Code 7) contains the number of seconds
skipping to change at page 35, line 50 skipping to change at page 35, line 50
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 transmission is based on IRT:
RT = IRT + RAND*IRT RT = IRT + RAND*IRT
RT for each subsequent message transmission is based on the previous RT for each subsequent message retransmission is based on the
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,
there is no upper limit on the value of RT. Otherwise: there is no upper limit on the value of RT. Otherwise:
if (RT > MRT) if (RT > MRT)
RT = MRT + RAND*MRT RT = MRT + RAND*MRT
skipping to change at page 37, line 51 skipping to change at page 37, line 51
Type and Flags fields. Type and Flags fields.
10.2.1. Version 10.2.1. Version
The Version namespace is used to identify PANA versions. The Version The Version namespace is used to identify PANA versions. The Version
values are assigned by Standards Action [IANA]. This document values are assigned by Standards Action [IANA]. This document
defines the Version 1. defines the Version 1.
10.2.2. Message Type 10.2.2. Message Type
The Message Type namespace is used to identify PANA messages. Values The Message Type namespace is used to identify PANA messages. The
0-65,519 are for permanent, standard message types, allocated by IETF range of values 0 - 65,519 are for permanent, standard message types,
Consensus [IANA]. This document defines the Message Types 1-4. The allocated by IETF Consensus [IANA]. This document defines the range
same Message Type is used for both the request and the answer of values 1 - 4. The same Message Type is used for both the request
messages, except for type 1. The Request bit distinguishes requests and the answer messages, except for type 1. The Request bit
from answers. See Section 7 for the assignment of the namespace in distinguishes requests from answers. See Section 7 for the
this specification. assignment of the namespace in this specification.
The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 -
reserved for experimental messages. As these codes are only for 0xffff) are reserved for experimental messages. As these codes are
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.3. 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') and 4
('P') in Section 6.2. The remaining bits MUST only be assigned via a ('P') in Section 6.2. The remaining bits MUST only be assigned via a
Standards Action [IANA]. Standards Action [IANA].
skipping to change at page 38, line 45 skipping to change at page 38, line 45
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-8.
See Section 8.1 through Section 8.8 for the assignment of the See Section 8.1 through Section 8.8 for the assignment of the
namespace in this specification. namespace in this specification.
AVPs may be allocated following Designated Expert with Specification AVPs may be allocated following Designated Expert Review with
Required [IANA] or Standards Action. AVPs with 'M' bit set MUST be Specification Required [IANA] or Standards Action. AVPs with the 'M'
allocated by 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.
skipping to change at page 40, line 23 skipping to change at page 40, line 23
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 (physical and
link-layer) security. In the context of this document, lower-layers link-layer) security. In the context of this document, lower-layers
are said to be secure if they can prevent eavesdropping and spoofing are said to be secure if they can prevent eavesdropping and spoofing
of packets. Examples of such networks are physically-secured DSL of packets. Examples of such networks are physically-secured DSL
networks and 3GPP2 networks with cryptographically-secured cdma2000 networks and 3GPP2 networks with cryptographically-secured cdma2000
link-layer. In these examples, the lower-layer security is enabled link-layer. In these examples, the lower-layer security is enabled
even before running the first PANA-based authentication. In the even before running the first PANA-based authentication. In the
absence of such a pre-established secure channel, one needs to be absence of such a pre-established secure channel prior to running
created in conjunction with PANA using a link-layer or network-layer PANA, one needs to be created after the successful PANA
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 45, line 16 skipping to change at page 45, line 16
13.1. Normative References 13.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Security Association Management Protocol", RFC 4595, Specifications: ABNF", RFC 4234, October 2005.
July 2006.
[I-D.ietf-dhc-paa-option] [I-D.ietf-dhc-paa-option]
Morand, L., "DHCP options for PANA Authentication Agents", Morand, L., "DHCP options for PANA Authentication Agents",
draft-ietf-dhc-paa-option-05 (work in progress), draft-ietf-dhc-paa-option-05 (work in progress),
December 2006. December 2006.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
skipping to change at page 46, line 14 skipping to change at page 46, line 10
"Protocol for Carrying Authentication for Network Access "Protocol for Carrying Authentication for Network Access
(PANA) Requirements", RFC 4058, May 2005. (PANA) Requirements", RFC 4058, May 2005.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol "State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137, August 2005. (EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
Security Association Management Protocol", RFC 4595,
July 2006.
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007. progress), February 2007.
[I-D.ietf-pana-ipsec] [I-D.ietf-pana-ipsec]
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-08 (work in progress), May 2007. draft-ietf-pana-framework-09 (work in progress),
June 2007.
[I-D.ietf-pana-snmp] [I-D.ietf-pana-snmp]
Mghazli, Y., "SNMP usage for PAA-EP interface", Mghazli, Y., "SNMP usage for PAA-EP interface",
draft-ietf-pana-snmp-06 (work in progress), June 2006. 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.
 End of changes. 55 change blocks. 
146 lines changed or deleted 159 lines changed or added

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