diff options
Diffstat (limited to 'doc/rfc/rfc5191.txt')
| -rw-r--r-- | doc/rfc/rfc5191.txt | 2579 |
1 files changed, 2579 insertions, 0 deletions
diff --git a/doc/rfc/rfc5191.txt b/doc/rfc/rfc5191.txt new file mode 100644 index 0000000..25bd448 --- /dev/null +++ b/doc/rfc/rfc5191.txt @@ -0,0 +1,2579 @@ + + + + + + +Network Working Group D. Forsberg +Request for Comments: 5191 Nokia +Category: Standards Track Y. Ohba, Ed. + Toshiba + B. Patil + H. Tschofenig + Nokia Siemens Networks + A. Yegin + Samsung + May 2008 + + + Protocol for Carrying Authentication for Network Access (PANA) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document defines the Protocol for Carrying Authentication for + Network Access (PANA), a network-layer transport for Extensible + Authentication Protocol (EAP) to enable network access authentication + between clients and access networks. In EAP terms, PANA is a + UDP-based EAP lower layer that runs between the EAP peer and the EAP + authenticator. + + + + + + + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 1] + +RFC 5191 PANA May 2008 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Specification of Requirements ..............................4 + 2. Terminology .....................................................4 + 3. Protocol Overview ...............................................6 + 4. Protocol Details ................................................7 + 4.1. Authentication and Authorization Phase .....................7 + 4.2. Access Phase ..............................................11 + 4.3. Re-Authentication Phase ...................................11 + 4.4. Termination Phase .........................................13 + 5. Processing Rules ...............................................13 + 5.1. Fragmentation .............................................13 + 5.2. Sequence Number and Retransmission ........................14 + 5.3. PANA Security Association .................................15 + 5.4. Message Authentication ....................................17 + 5.5. Message Validity Check ....................................17 + 5.6. PaC Updating Its IP Address ...............................19 + 5.7. Session Lifetime ..........................................19 + 6. Message Format .................................................20 + 6.1. IP and UDP Headers ........................................20 + 6.2. PANA Message Header .......................................20 + 6.3. AVP Format ................................................22 + 7. PANA Messages ..................................................24 + 7.1. PANA-Client-Initiation (PCI) ..............................27 + 7.2. PANA-Auth-Request (PAR) ...................................28 + 7.3. PANA-Auth-Answer (PAN) ....................................28 + 7.4. PANA-Termination-Request (PTR) ............................28 + 7.5. PANA-Termination-Answer (PTA) .............................29 + 7.6. PANA-Notification-Request (PNR) ...........................29 + 7.7. PANA-Notification-Answer (PNA) ............................29 + 8. AVPs in PANA ...................................................29 + 8.1. AUTH AVP ..................................................30 + 8.2. EAP-Payload AVP ...........................................30 + 8.3. Integrity-Algorithm AVP ...................................31 + 8.4. Key-Id AVP ................................................31 + 8.5. Nonce AVP .................................................31 + 8.6. PRF-Algorithm AVP .........................................32 + 8.7. Result-Code AVP ...........................................32 + 8.8. Session-Lifetime AVP ......................................32 + 8.9. Termination-Cause AVP .....................................33 + 9. Retransmission Timers ..........................................33 + 9.1. Transmission and Retransmission Parameters ................35 + 10. IANA Considerations ...........................................35 + 10.1. PANA UDP Port Number .....................................36 + 10.2. PANA Message Header ......................................36 + 10.2.1. Message Type ......................................36 + 10.2.2. Flags .............................................36 + + + +Forsberg, et al. Standards Track [Page 2] + +RFC 5191 PANA May 2008 + + + 10.3. AVP Header ...............................................36 + 10.3.1. AVP Code ..........................................37 + 10.3.2. Flags .............................................37 + 10.4. AVP Values ...............................................37 + 10.4.1. Result-Code AVP Values ............................37 + 10.4.2. Termination-Cause AVP Values ......................38 + 11. Security Considerations .......................................38 + 11.1. General Security Measures ................................38 + 11.2. Initial Exchange .........................................40 + 11.3. EAP Methods ..............................................40 + 11.4. Cryptographic Keys .......................................40 + 11.5. Per-Packet Ciphering .....................................41 + 11.6. PAA-to-EP Communication ..................................41 + 11.7. Liveness Test ............................................41 + 11.8. Early Termination of a Session ...........................42 + 12. Acknowledgments ...............................................42 + 13. References ....................................................42 + 13.1. Normative References .....................................42 + 13.2. Informative References ...................................43 + +1. Introduction + + Providing secure network access service requires access control based + on the authentication and authorization of the clients and the access + networks. Client-to-network authentication provides parameters that + are needed to police the traffic flow through the enforcement points. + A protocol is needed to carry authentication methods between the + client and the access network. + + The scope of this work is identified as designing a network-layer + transport for network access authentication methods. The Extensible + Authentication Protocol (EAP) [RFC3748] provides such authentication + methods. In other words, PANA carries EAP, which can carry various + authentication methods. By the virtue of enabling the transport of + EAP above IP, any authentication method that can be carried as an EAP + method is made available to PANA and hence to any link-layer + technology. There is a clear division of labor between PANA (an EAP + lower layer), EAP, and EAP methods as described in [RFC3748]. + + Various environments and usage models for PANA are identified in + Appendix A of [RFC4058]. Potential security threats for + network-layer access authentication protocol are discussed in + [RFC4016]. These have been essential in defining the requirements + [RFC4058] of the PANA protocol. Note that some of these requirements + are imposed by the chosen payload, EAP [RFC3748]. + + + + + + +Forsberg, et al. Standards Track [Page 3] + +RFC 5191 PANA May 2008 + + + There are components that are part of a complete secure network + access solution but are outside of the PANA protocol specification, + including PANA Authentication Agent (PAA) discovery, authentication + method choice, PANA Authentication Agent-Enforcement Point (PAA-EP) + protocol, access control filter creation, and data traffic + protection. These components are described in separate documents + (see [RFC5193] and [RFC5192]). + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in [RFC2119]. + +2. Terminology + + PANA Client (PaC): + + The client side of the protocol that resides in the access device + (e.g., laptop, PDA, etc.). It is responsible for providing the + credentials in order to prove its identity (authentication) for + network access authorization. The PaC and the EAP peer are + colocated in the same access device. + + PANA Authentication Agent (PAA): + + The protocol entity in the access network whose responsibility it + is to verify the credentials provided by a PANA client (PaC) and + authorize network access to the access device. The PAA and the + EAP authenticator (and optionally the EAP server) are colocated in + the same node. Note the authentication and authorization + procedure can, according to the EAP model, also be offloaded to + the back end Authentication, Authorization, and Accounting (AAA) + infrastructure. + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 4] + +RFC 5191 PANA May 2008 + + + PANA Session: + + A PANA session is established between the PANA Client (PaC) and + the PANA Authentication Agent (PAA), and it terminates as a result + of an authentication and authorization or liveness test failure, a + message delivery failure after retransmissions reach maximum + values, session lifetime expiration, an explicit termination + message or any event that causes discontinuation of the access + service. A fixed session identifier is maintained throughout a + session. A session cannot be shared across multiple network + interfaces. + + Session Lifetime: + + A duration that is associated with a PANA session. For an + established PANA session, the session lifetime is bound to the + lifetime of the current authorization given to the PaC. The + session lifetime can be extended by a new round of EAP + authentication before it expires. Until a PANA session is + established, the lifetime SHOULD be set to a value that allows the + PaC to detect a failed session in a reasonable amount of time. + + Session Identifier: + + This identifier is used to uniquely identify a PANA session on the + PaC and the PAA. It is included in PANA messages to bind the + message to a specific PANA session. This bidirectional identifier + is allocated by the PAA in the initial request message and freed + when the session terminates. The session identifier is assigned + by the PAA and is unique within the PAA. + + PANA Security Association (PANA SA): + + A PANA security association is formed between the PaC and the PAA + by sharing cryptographic keying material and associated context. + The formed duplex security association is used to protect the + bidirectional PANA signaling traffic between the PaC and PAA. + + Enforcement Point (EP): + + A node on the access network where per-packet enforcement policies + (i.e., filters) are applied on the inbound and outbound traffic of + access devices. The EP and the PAA may be colocated. EPs should + prevent data traffic from and to any unauthorized client, unless + that data traffic is either PANA or one of the other allowed + traffic types (e.g., Address Resolution Protocol (ARP), IPv6 + neighbor discovery, DHCP, etc.). + + + + +Forsberg, et al. Standards Track [Page 5] + +RFC 5191 PANA May 2008 + + + Master Session Key (MSK): + + A key derived by the EAP peer and the EAP server and transported + to the EAP authenticator [RFC3748]. + + For additional terminology definitions, see the PANA framework + document [RFC5193]. + +3. Protocol Overview + + The PANA protocol is run between a client (PaC) and a server (PAA) in + order to perform authentication and authorization for the network + access service. + + The protocol messaging consists of a series of requests and answers, + some of which may be initiated by either end. Each message can carry + zero or more AVPs (Attribute-Value Pairs) within the payload. The + main payload of PANA is EAP, which performs authentication. PANA + helps the PaC and PAA establish an EAP session. + + PANA is a UDP-based protocol. It has its own retransmission + mechanism to reliably deliver messages. + + PANA messages are sent between the PaC and PAA as part of a PANA + session. A PANA session consists of distinct phases: + + o Authentication and authorization phase: This is the phase that + 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 + PAA. The EAP payload (which carries an EAP method inside) is what + is used for authentication. The PAA conveys the result of + authentication and authorization to the PaC at the end of this + phase. + + o Access phase: After successful authentication and authorization, + the access device gains access to the network and can send and + receive IP traffic through the EP(s). At any time during this + phase, the PaC and PAA may optionally send PANA notification + messages to test liveness of the PANA session on the peer. + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 6] + +RFC 5191 PANA May 2008 + + + o Re-authentication phase: During the access phase, the PAA may, and + the PaC should, initiate re-authentication if they want to update + the PANA session lifetime before the PANA session lifetime + expires. EAP is carried by PANA to perform re-authentication. + This phase may be optionally triggered by both the PaC and the PAA + without any respect to the session lifetime. The + re-authentication phase is a sub-phase of the access phase. The + session moves to this sub-phase from the access phase when + re-authentication starts, and returns back there upon successful + re-authentication. + + o Termination phase: The PaC or PAA may choose to discontinue the + access service at any time. An explicit disconnect message can be + sent by either end. If either the PaC or the PAA disconnects + without engaging in termination messaging, it is expected that + either the expiration of a finite session lifetime or failed + liveness tests would clean up the session at the other end. + + Cryptographic protection of messages between the PaC and PAA is + possible as soon as EAP in conjunction with the EAP method exports a + shared key. That shared key is used to create a PANA SA. The PANA + SA helps generate per-message authentication codes that provide + integrity protection and authentication. + +4. Protocol Details + + The following sections explain in detail the various phases of a PANA + session. + +4.1. Authentication and Authorization Phase + + The main task of the authentication and authorization phase is to + establish a PANA session and carry EAP messages between the PaC and + the PAA. The PANA session can be initiated by either the PaC or the + PAA. + + PaC-initiated Session: + + When the PaC initiates a PANA session, it sends a + PANA-Client-Initiation message to the PAA. When the PaC is not + configured with an IP address of the PAA before initiating the + PANA session, DHCP [RFC5192] is used as the default method for + dynamically configuring the IP address of the PAA. Alternative + methods for dynamically discovering the IP address of the PAA may + be used for PaC-initiated sessions, but they are outside the scope + of this specification. The PAA that receives the + PANA-Client-Initiation message MUST respond to the PaC with a + PANA-Auth-Request message. + + + +Forsberg, et al. Standards Track [Page 7] + +RFC 5191 PANA May 2008 + + + PAA-initiated Session: + + When the PAA knows the IP address of the PaC, it MAY send an + unsolicited PANA-Auth-Request to the PaC. The details of how PAA + can learn the IP address of the PaC are outside the scope of this + specification. + + A session identifier for the session is assigned by the PAA and + carried in the initial PANA-Auth-Request message. The same session + identifier MUST be carried in the subsequent messages exchanged + between the PAA and PaC throughout the session. + + 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 + 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 'S' (Start) bit set, regardless of whether the session is + 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 + the 'S' (Start) bit set. + + It is recommended that the PAA limit the rate at which it processes + incoming PANA-Client-Initiation messages to provide robustness + against denial of service (DoS) attacks. The details of rate + limiting are outside the scope of this specification. + + If a PANA SA needs to be established with use of a key-generating EAP + method, the Pseudo-Random Function (PRF) and integrity algorithms to + be used for PANA_AUTH_KEY derivation (see Section 5.3) and AUTH AVP + calculation (see Section 5.4) are negotiated as follows: the PAA + sends the initial PANA-Auth-Request carrying one or more + PRF-Algorithm AVPs and one or more Integrity-Algorithm AVPs for the + PRF and integrity algorithms 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 it 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 + PANA-Client-Initiation message, it doesn't include an EAP-Payload AVP + in the initial PANA-Auth-Request message, and it should not + retransmit the message on a timer. For this reason, the PaC MUST + retransmit the PANA-Client-Initiation message until it receives the + second PANA-Auth-Request message (not a retransmission of the initial + one) from the PAA. + + + +Forsberg, et al. Standards Track [Page 8] + +RFC 5191 PANA May 2008 + + + It is possible that both the PAA and the PaC initiate the PANA + session at the same time, i.e., the PAA sends the initial PANA-Auth- + Request message without solicitation while the PaC sends a + PANA-Client-Initiation message. To resolve the race condition, the + PAA MUST silently discard the PANA-Client-Initiation message received + from the PaC after it has sent the initial PANA-Auth-Request message. + The PAA uses the source IP address and the source port number of the + PANA-Client-Initiation message to identify the PaC among multiple + PANA-Client-Initiation messages sent from different PaCs. + + EAP messages are carried in PANA-Auth-Request messages. + PANA-Auth-Answer messages are simply used to acknowledge receipt of + the requests. As an optimization, a PANA-Auth-Answer message sent + 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, + e.g., intervention of human input), in which case returning an + PANA-Auth-Answer message without piggybacking an EAP message can + avoid unnecessary retransmission of the PANA-Auth-Request message. + + 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 (i.e., with the 'S' (Start) bit set), and + MUST NOT be included in any other message, except during + re-authentication procedures (see Section 4.3). + + The result of PANA authentication is carried in the last + PANA-Auth-Request message sent from the PAA to the PaC. This message + carries the EAP authentication result and the result of PANA + authentication. The last PANA-Auth-Request message MUST be + acknowledged with a PANA-Auth-Answer message. The last + 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. Figure 1 shows an example sequence in the + authentication and authorization phase for a PaC-initiated session. + + + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 9] + +RFC 5191 PANA May 2008 + + + PaC PAA Message(sequence number)[AVPs] + --------------------------------------------------------------------- + -----> PANA-Client-Initiation(0) + <----- PANA-Auth-Request(x)[PRF-Algorithm,Integrity-Algorithm] + // The 'S' (Start) bit set + -----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm] + // The 'S' (Start) bit set + <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] + -----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP + -----> PANA-Auth-Request(y)[EAP-Payload] + <----- PANA-Auth-Answer(y) + <----- PANA-Auth-Request(x+2)[EAP-Payload] + -----> PANA-Auth-Answer(x+2)[EAP-Payload] + // Piggybacking EAP + <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, + Key-Id, Session-Lifetime, AUTH] + // 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 + phase for a PaC-initiated session ("Piggybacking EAP" is + the case in which an EAP-Payload AVP is carried in PAN) + + If a PANA SA needs to be established with use of a key-generating EAP + method and an MSK is successfully generated, the last + PANA-Auth-Request message with the 'C' (Complete) bit set MUST + contain a Key-Id AVP and an AUTH AVP for the first derivation of keys + in the session, and any subsequent message MUST contain an AUTH AVP. + + EAP authentication can fail at a pass-through authenticator without + sending an EAP Failure message [RFC4137]. When this occurs, the PAA + SHOULD silently terminate the session, expecting that a session + timeout on the PaC will clean up the state on the PaC. + + There is a case where EAP authentication succeeds with producing an + EAP Success message, but network access authorization fails due to, + e.g., authorization rejected by a AAA server or authorization locally + rejected by the PAA. When this occurs, the PAA MUST send the last + PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED. If + 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 + AUTH AVP and carry a Key-Id AVP. The PANA session MUST be terminated + immediately after the last PANA-Auth message exchange. + + For reasons described in Section 3 of [RFC5193], the PaC may need to + reconfigure the IP address after a successful authentication and + authorization phase to obtain an IP address that is usable for + + + +Forsberg, et al. Standards Track [Page 10] + +RFC 5191 PANA May 2008 + + + 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 to 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 + + Once the authentication and authorization phase successfully + 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 the access phase. In this phase, PANA-Notification-Request + and PANA-Notification-Answer messages with the 'P' (Ping) bit set + (ping request and ping answer messages, respectively) can be used for + 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 + communicating peer whenever they need to ensure the availability of + the session on the peer, and they expect the peer to return a ping + answer message. The ping request and answer messages MUST be + protected with an AUTH AVP when a PANA SA is available. A ping + request MUST NOT be sent in the authentication and authorization + phase, re-authentication phase, and termination phase. + + 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 + to perform any coordination with each other. There is no negotiation + of timers for this purpose. Additionally, an implementation MAY rate + limit processing the incoming ping requests. It should be noted that + if a PAA or PaC that considers its connectivity lost after a + relatively small number of unresponsive pings is coupled with a peer + that is aggressively rate limiting the ping request and answer + messages, then false-positives could result. Therefore, a PAA or PaC + should not rely on frequent ping operation to quickly determine loss + of connectivity. + +4.3. Re-Authentication Phase + + The PANA session in the access phase can enter the re-authentication + phase to extend the current session lifetime by re-executing EAP. + Once the re-authentication phase successfully completes, the session + re-enters the access phase. Otherwise, the session is terminated. + + When the PaC initiates re-authentication, it sends a + PANA-Notification-Request message with the 'A' (re-Authentication) + bit set (a re-authentication request message) to the PAA. This + message MUST contain the session identifier assigned to the session + being re-authenticated. If the PAA already has an established PANA + session for the PaC with the matching session identifier, it MUST + + + +Forsberg, et al. Standards Track [Page 11] + +RFC 5191 PANA May 2008 + + + first respond with a PANA-Notification-Answer message with the 'A' + (re-Authentication) bit set (a re-authentication answer message), + followed by a PANA-Auth-Request message that starts a new EAP + authentication. If the PAA cannot identify the session, it MUST + silently discard the message. The first PANA-Auth-Request and + PANA-Auth-Answer messages in the re-authentication phase MUST have + the 'S' (Start) bit cleared and carry a Nonce AVP. + + The PaC may receive a PANA-Auth-Request before receiving the answer + to its outstanding re-authentication request message. This condition + 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. + The PaC MUST keep discarding the received PANA-Auth-Requests until it + receives the answer to its request. + + When the PAA initiates re-authentication, it sends a + PANA-Auth-Request message containing the session identifier for the + PaC. The PAA MUST initiate EAP re-authentication before the current + session lifetime expires. + + Re-authentication of an ongoing PANA session MUST NOT reset the + sequence numbers. + + For any re-authentication, if there is an established PANA SA, + re-authentication request and answer messages and subsequent + PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected + with an AUTH AVP. The final PANA-Auth-Request and PANA-Auth-Answer + messages and any subsequent PANA message MUST be protected by using + the key generated from the latest EAP authentication. + + + + + + + + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 12] + +RFC 5191 PANA May 2008 + + + PaC PAA Message(sequence number)[AVPs] + --------------------------------------------------------------------- + -----> PANA-Notification-Request(q)[AUTH] + // 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-Answer(p)[AUTH, Nonce] + -----> PANA-Auth-Request(q+1)[EAP-Payload, AUTH] + <----- PANA-Auth-Answer(q+1)[AUTH] + <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] + -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] + <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, + Key-Id, Session-Lifetime, AUTH] + // The 'C' (Complete) 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 + by PaC + +4.4. Termination Phase + + A procedure for explicitly terminating a PANA session can be + initiated either from the PaC (i.e., disconnect indication) or from + the PAA (i.e., session revocation). The PANA-Termination-Request and + PANA-Termination-Answer message exchanges are used for + disconnect-indication and session-revocation procedures. + + The reason for termination is indicated in the Termination-Cause AVP. + When there is an established PANA SA between the PaC and the PAA, all + messages exchanged during the termination phase MUST be protected + with an AUTH AVP. When the sender of the PANA-Termination-Request + message receives a valid acknowledgment, all states maintained for + the PANA session MUST be terminated immediately. + +5. Processing Rules + +5.1. Fragmentation + + PANA does not provide fragmentation of PANA messages. Instead, it + relies on fragmentation provided by EAP methods and IP layer when + needed. + + + + + + + + +Forsberg, et al. Standards Track [Page 13] + +RFC 5191 PANA May 2008 + + +5.2. Sequence Number and Retransmission + + PANA uses sequence numbers to provide ordered and reliable delivery + of messages. + + The PaC and PAA maintain two sequence numbers: one is for setting the + sequence number of the next outgoing request; the other is for + matching the sequence number of the next incoming request. These + sequence numbers are 32-bit unsigned numbers. They are monotonically + incremented by 1 as new requests are generated and received, and + wrapped to zero on the next message after 2^32-1. Answers always + contain the same sequence number as the corresponding request. + Retransmissions reuse the sequence number contained in the original + packet. + + The initial sequence numbers (ISN) are randomly picked by the PaC and + PAA as they send their very first request messages. + PANA-Client-Initiation message carries sequence number 0. + + When a request message is received, it is considered valid in terms + of sequence numbers if and only if its sequence number matches the + expected value. This check does not apply to the + PANA-Client-Initiation message and the initial PANA-Auth-Request + message. + + When an answer message is received, it is considered valid in terms + of sequence numbers if and only if its sequence number matches that + of the currently outstanding request. A peer can only have one + outstanding request at a time. + + PANA request messages are retransmitted based on a timer until an + answer is received (in which case the retransmission timer is + stopped) or the number of retransmission reaches the maximum value + (in which case the PANA session MUST be terminated immediately). + + The retransmission timers SHOULD be calculated as described in + Section 9, unless a given deployment chooses to use its own + retransmission timers optimized for the underlying link-layer + characteristics. + + Unless dropped due to rate limiting, the PaC and PAA MUST respond to + all duplicate request messages received. The last transmitted answer + MAY be cached in case it is not received by the peer, which generates + a retransmission of the last request. When available, the cached + answer can be used instead of fully processing the retransmitted + request and forming a new answer from scratch. + + + + + +Forsberg, et al. Standards Track [Page 14] + +RFC 5191 PANA May 2008 + + +5.3. PANA Security Association + + 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 + 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 + 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 + 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 the + '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 + and MUST contain a value that uniquely identifies the MSK within the + PANA session. The last PANA-Auth-Answer message with the 'C' + (Complete) bit set in response to the last PANA-Auth-Request message + with the 'C' (Complete) bit set MUST contain a Key-Id AVP with the + same MSK identifier carried in the request. The last + PANA-Auth-Request and PANA-Auth-Answer messages with a Key-Id AVP + MUST also carry an AUTH AVP whose value is computed by using the new + PANA_AUTH_KEY derived from the new MSK. Although the specification + does not mandate a particular method for calculation of the Key-Id + AVP value, a simple method is to use monotonically increasing + numbers. + + The PANA session lifetime is bounded by the authorization lifetime + 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 session. The created PANA SA is deleted when + the corresponding PANA session is terminated. + + PANA SA attributes as well as PANA session attributes are listed + below: + + PANA Session attributes: + + * Session Identifier + + * IP address and UDP port number of the PaC + + * IP address and UDP port number of the PAA + + * Sequence number for the next outgoing request + + * Sequence number for the next incoming request + + * Last transmitted message payload + + * Retransmission interval + + + +Forsberg, et al. Standards Track [Page 15] + +RFC 5191 PANA May 2008 + + + * Session lifetime + + * PANA SA attributes + + PANA SA attributes: + + * Nonce generated by PaC (PaC_nonce) + + * Nonce generated by PAA (PAA_nonce) + + * MSK + + * MSK Identifier + + * PANA_AUTH_KEY + + * Pseudo-random function + + * Integrity algorithm + + 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 + the following way: + + PANA_AUTH_KEY = prf+(MSK, "IETF PANA"|I_PAR|I_PAN| + PaC_nonce|PAA_nonce|Key_ID) + + where: + + - The prf+ function is defined in IKEv2 [RFC4306]. The pseudo-random + function to be used for the prf+ function is negotiated using + PRF-Algorithm AVP in the initial PANA-Auth-Request and + PANA-Auth-Answer exchange with 'S' (Start) bit set. + + - MSK is the master session key generated by the EAP method. + + - "IETF PANA" is the ASCII code representation of the non-NULL + terminated string (excluding the double quotes around it). + + - I_PAR and I_PAN are the initial PANA-Auth-Request and + PANA-Auth-Answer messages (the PANA header and the following PANA + AVPs) with 'S' (Start) bit set, respectively. + + - PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the + first non-initial PANA-Auth-Answer and PANA-Auth-Request messages + in the authentication and authorization phase or the first + PANA-Auth-Answer and PANA-Auth-Request messages in the + re-authentication phase, respectively. + + + +Forsberg, et al. Standards Track [Page 16] + +RFC 5191 PANA May 2008 + + + - Key_ID is the value of the Key-Id AVP. + + The length of PANA_AUTH_KEY depends on the integrity algorithm in + use. See Section 5.4 for the detailed usage of the PANA_AUTH_KEY. + +5.4. Message Authentication + + A PANA message can contain an AUTH AVP for cryptographically + protecting the message. + + 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 + following way: + + AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) + + where PANA_PDU is the PANA message including the PANA header, with + the AUTH AVP Value field first initialized to 0. PANA_AUTH_HASH + represents the integrity algorithm negotiated using + Integrity-Algorithm AVP in the initial PANA-Auth-Request and + PANA-Auth-Answer exchange with 'S' (Start) bit set. The PaC and PAA + MUST use the same integrity algorithm to calculate an AUTH AVP they + originate and receive. + +5.5. Message Validity Check + + When a PANA message is received, the message is considered to be + invalid, at least when one of the following conditions are not met: + + o Each field in the message header contains a valid value including + sequence number, message length, message type, flags, session + identifier, etc. + + o The message type is one of the expected types in the current + state. Specifically, the following messages are unexpected and + invalid: + + * In the authentication and authorization phase: + + + PANA-Client-Initiation after completion of the initial + PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' + (Start) bit set. + + + Re-authentication request. + + + Ping request. + + + + + +Forsberg, et al. Standards Track [Page 17] + +RFC 5191 PANA May 2008 + + + + The last PANA-Auth-Request with 'C' (Complete) bit set + 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. + + * In the re-authentication phase: + + + PANA-Client-Initiation. + + + The initial PANA-Auth-Request. + + * In the access phase: + + + PANA-Auth-Request. + + + PANA-Client-Initiation. + + * In the termination phase: + + + PANA-Client-Initiation. + + + All requests but PANA-Termination-Request and ping request. + + o The message payload contains a valid set of AVPs allowed for the + message type. There is no missing AVP that needs to be included + in the payload, and no AVP, which needs to be at a fixed position, + is included in a position different from this fixed position. + + o Each AVP is recognized and decoded correctly. + + o Once the PANA authentication succeeds in using a key-generating + EAP method, the PANA-Auth-Request message that carries the EAP + Success and any subsequent message in that session contains 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 + against DoS attacks. + + + + + + + + +Forsberg, et al. Standards Track [Page 18] + +RFC 5191 PANA May 2008 + + +5.6. PaC Updating Its IP Address + + A PaC's IP address used for PANA can change in certain situations, + e.g., when IP address reconfiguration is needed for the PaC to obtain + an IP address after successful PANA authentication (see Section 3 of + [RFC5193]) 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 be notified about the change of PaC address. + + 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 + 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 + is an established PANA SA, the message MUST be protected with an AUTH + AVP. + +5.7. Session Lifetime + + The authentication and authorization phase determines the PANA + session lifetime, and the lifetime is indicated to the PaC when the + network access authorization succeeds. For this purpose, when the + last PANA-Auth-Request message (i.e., with the 'C' (Complete) bit + set) in authentication and authorization phase or re-authentication + phase carries a Result-Code AVP with a value of PANA_SUCCESS, a + Session-Lifetime AVP MUST also be carried in the message. A + Session-Lifetime AVP MUST be ignored when included in other PANA + messages. + + 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-authentication phase before the current session lifetime expires, + if it wants to extend the session. + + The PaC and the PAA MAY use information obtained outside PANA (e.g., + lower-layer indications) to expedite the detection of a disconnected + peer. Availability and reliability of such indications MAY depend on + a specific link-layer or network topology and are therefore only + hints. A PANA peer SHOULD use the ping request and answer exchange + to verify that a peer is, in fact, no longer alive, unless + information obtained outside PANA is being used to expedite the + detection of a disconnected peer. + + The session lifetime parameter is not related to the transmission of + ping request messages. These messages can be used for asynchronously + verifying the liveness of the peer. The decision to send a ping + request message is made locally and does not require coordination + between the peers. + + + + +Forsberg, et al. Standards Track [Page 19] + +RFC 5191 PANA May 2008 + + +6. Message Format + + This section defines message formats for PANA protocol. + +6.1. IP and UDP Headers + + Any PANA message is unicast between the PaC and the PAA. + + For any PANA message sent from the peer that has initiated the PANA + session, the UDP source port is set to any number on which the peer + can receive incoming PANA messages, and the destination port is set + to the assigned PANA port number (716). For any PANA message sent + from the other peer, the source port is set to the assigned PANA port + number (716), and the destination port is copied from the source port + of the last received message. In case both the PaC and PAA initiate + the session (i.e., PANA-Client-Initiation and unsolicited PANA-Auth- + Request messages cross each other), then the PaC is identified as the + initiator. All PANA peers MUST listen on the assigned PANA port + number (716). + +6.2. PANA Message Header + + A summary of the PANA message header format is shown below. The + fields are transmitted in network byte order. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Message Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Session Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AVPs ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Reserved + + This 16-bit field is reserved for future use. It MUST be set to + zero and ignored by the receiver. + + + + + + + + +Forsberg, et al. Standards Track [Page 20] + +RFC 5191 PANA May 2008 + + + Message Length + + The Message Length field is two octets and indicates the length of + the PANA message including the header fields. + + Flags + + The Flags field is two octets. The following bits are assigned: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R S C A P I r r r r r r r r r r| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + R (Request) + + If set, the message is a request. If cleared, the message is an + answer. + + S (Start) + + If set, the message is the first PANA-Auth-Request or + PANA-Auth-Answer in authentication and authorization phase. For + other messages, this bit MUST be cleared. + + C (Complete) + + If set, the message is the last PANA-Auth-Request or + PANA-Auth-Answer in authentication and authorization phase. For + other messages, this bit MUST be cleared. + + A (re-Authentication) + + If set, the message is a PANA-Notification-Request or + PANA-Notification-Answer to initiate re-authentication. For other + messages, this bit MUST be cleared. + + P (Ping) + + If set, the message is a PANA-Notification-Request or + PANA-Notification-Answer for liveness test. For other messages, + this bit MUST be cleared. + + + + + + + + +Forsberg, et al. Standards Track [Page 21] + +RFC 5191 PANA May 2008 + + + 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 + only for PANA-Auth-Request messages in the authentication and + authorization phase. For other messages, this bit MUST be + cleared. + + r (reserved) + + These flag bits are reserved for future use. They MUST be set to + zero and ignored by the receiver. + + Message Type + + The Message Type field is two octets, and it is used in order to + communicate the message type with the message. Message Type + allocation is managed by IANA [IANAWEB]. + + Session Identifier + + This field contains a 32-bit session identifier. + + Sequence Number + + This field contains a 32-bit sequence number. + + AVPs + + AVPs are a method of encapsulating information relevant to the + PANA message. See Section 6.3 for more information on AVPs. + +6.3. AVP Format + + Each AVP of type OctetString MUST be padded to align on a 32-bit + boundary, while other AVP types align naturally. A number of + zero-valued bytes are added to the end of the AVP Value field until a + word boundary is reached. The length of the padding is not reflected + in the AVP Length field [RFC3588]. + + + + + + + + + + +Forsberg, et al. Standards Track [Page 22] + +RFC 5191 PANA May 2008 + + + The fields in the AVP are sent in network byte order. The AVP format + is: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AVP Code | AVP Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AVP Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Id (opt) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... + +-+-+-+-+-+-+-+-+ + + AVP Code + + The AVP Code, together with the optional Vendor-Id field, + identifies an attribute that follows. If the V-bit is not set, + then the Vendor-Id is not present and the AVP Code refers to an + IETF attribute. + + AVP Flags + + The AVP Flags field is two octets. The following bits are + assigned: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V r r r r r r r r r r r r r r r| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + V (Vendor) + + The 'V' (Vendor) bit indicates whether the optional Vendor-Id + field is present in the AVP header. When set, the AVP Code + belongs to the specific vendor code address space. All AVPs + defined in this document MUST have the 'V' (Vendor) bit cleared. + + r (reserved) + + These flag bits are reserved for future use. They MUST be set to + zero and ignored by the receiver. + + + + + + + +Forsberg, et al. Standards Track [Page 23] + +RFC 5191 PANA May 2008 + + + AVP Length + + The AVP Length field is two octets, and indicates the number of + octets in the Value field. The length of the AVP Code, AVP + Length, AVP Flags, Reserved and Vendor-Id fields are not counted + in the AVP Length value. + + Reserved + + This two-octet field is reserved for future use. It MUST be set + to zero and ignored by the receiver. + + Vendor-Id + + The Vendor-Id field is present if the 'V' (Vendor) bit is set in + the AVP Flags field. The optional four-octet Vendor-Id field + contains the IANA assigned "SMI Network Management Private + Enterprise Codes" [IANAWEB] value, encoded in network byte order. + Any vendor wishing to implement a vendor-specific PANA AVP MUST + use their own Vendor-Id along with their privately managed AVP + address space, guaranteeing that they will not collide with any + other vendor's vendor-specific AVP(s) nor with future IETF + applications. + + Value + + The Value field is zero or more octets and contains information + specific to the Attribute. The format of the Value field is + determined by the AVP Code and Vendor-Id fields. The length of + the Value field is determined by the AVP Length field. + +7. PANA Messages + + Each Request/Answer message pair is assigned a sequence number, and + 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. + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 24] + +RFC 5191 PANA May 2008 + + + 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 + be taken for a particular message. Figure 3 lists all PANA messages + defined in this document: + + Message Name Abbrev. Message PaC<->PAA Ref. + Type + --------------------------------------------------------------------- + PANA-Client-Initiation PCI 1 --------> 7.1 + PANA-Auth-Request PAR 2 <-------> 7.2 + PANA-Auth-Answer PAN 2 <-------> 7.3 + PANA-Termination-Request PTR 3 <-------> 7.4 + PANA-Termination-Answer PTA 3 <-------> 7.5 + PANA-Notification-Request PNR 4 <-------> 7.6 + PANA-Notification-Answer PNA 4 <-------> 7.7 + --------------------------------------------------------------------- + + Figure 3: Table of PANA Messages + + The language used for PANA message definitions (i.e., AVPs valid for + that PANA message type), in Section 7.1 through Section 7.7, is + defined using ABNF [RFC5234] as follows: + + message-def = Message-Name LWSP "::=" LWSP PANA-message + + Message-Name = PANA-name + + PANA-name = ALPHA *(ALPHA / DIGIT / "-") + + PANA-message = header LWSP *fixed LWSP *required + LWSP *optional LWSP *fixed + + header = "<" LWSP "PANA-Header:" LWSP Message-Type + [r-bit] [s-bit] [c-bit] [a-bit] [p-bit] [i-bit] + LWSP ">" + + Message-Type = 1*DIGIT + ; The Message Type assigned to the message + + r-bit = ",REQ" + ; If present, the 'R' (Request) bit in the Message + ; Flags is set, indicating that the message + ; is a request, as opposed to an answer. + + + + + + + + +Forsberg, et al. Standards Track [Page 25] + +RFC 5191 PANA May 2008 + + + s-bit = ",STA" + ; If present, the 'S' (Start) bit in the Message + ; Flags is set, indicating that the message + ; is the initial PAR or PAN in authentication + ; and authorization phase. + + c-bit = ",COM" + ; If present, the 'C' bit in the Message + ; Flags is set, indicating that the message + ; is the final PAR and PAN in authentication + ; and authorization phase or re-authentication + ; phase. + + a-bit = ",REA" + ; If present, the 'A' (re-Authentication) bit + ; in the Message Flags is set, indicating that + ; the message is a re-authentication request or + ; answer. + + p-bit = ",PIN" + ; If present, the 'P' (Ping) bit in the Message + ; Flags is set, indicating that the message + ; is a ping request or answer. + + 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. + + required = [qual] "{" LWSP avp-spec LWSP "}" + ; The AVP MUST be present and can appear + ; anywhere in the message. + + optional = [qual] "[" LWSP avp-name LWSP "]" + ; The avp-name in the 'optional' rule cannot + ; evaluate any AVP Name that is included + ; in a fixed or required rule. The AVP can + ; appear anywhere in the message. + + + + + + + + +Forsberg, et al. Standards Track [Page 26] + +RFC 5191 PANA May 2008 + + + qual = [min] "*" [max] + ; See ABNF conventions, RFC 5234 Section 3.6. + ; The absence of any qualifiers depends on whether + ; it precedes a fixed, required, or optional + ; rule. If a fixed or required rule has no + ; qualifier, then exactly one such AVP MUST + ; be present. If an optional rule has no + ; qualifier, then 0 or 1 such AVP may be + ; present. + ; + ; NOTE: "[" and "]" have a different meaning + ; than in ABNF (see the optional rule, above). + ; These braces cannot be used to express + ; optional fixed rules (such as an optional + ; AUTH at the end). To do this, the convention + ; is '0*1fixed'. + + min = 1*DIGIT + ; The minimum number of times the element may + ; be present. The default value is zero. + + max = 1*DIGIT + ; The maximum number of times the element may + ; be present. The default value is infinity. A + ; value of zero implies the AVP MUST NOT be + ; present. + + avp-spec = PANA-name + ; The avp-spec has to be an AVP Name, defined + ; in the base or extended PANA protocol + ; specifications. + + avp-name = avp-spec / "AVP" + ; The string "AVP" stands for *any* arbitrary + ; AVP Name, which does not conflict with the + ; required or fixed position AVPs defined in + ; the message definition. + +7.1. PANA-Client-Initiation (PCI) + + The PANA-Client-Initiation (PCI) message is used for PaC-initiated + session. The Sequence Number and Session Identifier fields in this + message MUST be set to zero (0). + + PANA-Client-Initiation ::= < PANA-Header: 1 > + *[ AVP ] + + + + + +Forsberg, et al. Standards Track [Page 27] + +RFC 5191 PANA May 2008 + + +7.2. PANA-Auth-Request (PAR) + + The PANA-Auth-Request (PAR) message is either sent by the PAA or the + PaC. + + The message MUST NOT have both the 'S' (Start) and 'C' (Complete) + bits set. + + PANA-Auth-Request ::= < PANA-Header: 2,REQ[,STA][,COM][,IPR] > + [ EAP-Payload ] + [ Nonce ] + *[ PRF-Algorithm ] + *[ Integrity-Algorithm ] + [ Result-Code ] + [ Session-Lifetime ] + [ Key-Id ] + *[ AVP ] + 0*1< AUTH > + +7.3. PANA-Auth-Answer (PAN) + + The PANA-Auth-Answer (PAN) message is sent by either the PaC or the + PAA in response to a PANA-Auth-Request message. + + The message MUST NOT have both the 'S' (Start) and 'C' (Complete) + bits set. + + PANA-Auth-Answer ::= < PANA-Header: 2[,STA][,COM] > + [ Nonce ] + [ PRF-Algorithm ] + [ Integrity-Algorithm ] + [ EAP-Payload ] + [ Key-Id ] + *[ AVP ] + 0*1< AUTH > + +7.4. PANA-Termination-Request (PTR) + + The PANA-Termination-Request (PTR) message is sent either by the PaC + or the PAA to terminate a PANA session. + + PANA-Termination-Request ::= < PANA-Header: 3,REQ > + < Termination-Cause > + *[ AVP ] + 0*1< AUTH > + + + + + + +Forsberg, et al. Standards Track [Page 28] + +RFC 5191 PANA May 2008 + + +7.5. PANA-Termination-Answer (PTA) + + The PANA-Termination-Answer (PTA) message is sent either by the PaC + or the PAA in response to PANA-Termination-Request. + + PANA-Termination-Answer ::= < PANA-Header: 3 > + *[ AVP ] + 0*1< AUTH > + +7.6. PANA-Notification-Request (PNR) + + The PANA-Notification-Request (PNR) message is used for signaling + re-authentication and performing liveness test. See Section 4.3 and + Section 4.2 for details on re-authentication and liveness test, + respectively. + + 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] > + *[ AVP ] + 0*1< AUTH > + +7.7. PANA-Notification-Answer (PNA) + + 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 + PaC (PAA). + + The message MUST have one of the 'A' (re-Authentication) and 'P' + (Ping) bits exclusively set. + + PANA-Notification-Answer ::= < PANA-Header: 4[,REA][,PIN] > + *[ AVP ] + 0*1< AUTH > + +8. AVPs in PANA + + This document uses AVP Value Format such as 'OctetString' and + 'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions + of these data formats are not repeated in this document. + + The following table lists the AVPs used in this document, and + specifies in which PANA messages they MAY or MAY NOT be present. + + + + + + + +Forsberg, et al. Standards Track [Page 29] + +RFC 5191 PANA May 2008 + + + The table uses the following symbols: + + 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. + It is considered an error if there is more than one instance of + the AVP. + + 1 One instance of the AVP MUST be present in the message. + + 0+ Zero or more instances of the AVP MAY be present in the + message. + + +---------------------------+ + | Message Type | + +---+---+---+---+---+---+---+ + Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA| + ----------------------+---+---+---+---+---+---+---+ + 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 | + Integrity-Algorithm | 0 |0+ |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 | + PRF-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 | + Result-Code | 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 | + ----------------------+---+---+---+---+---+---+---+ + + Figure 4: AVP Occurrence Table + +8.1. AUTH AVP + + The AUTH AVP (AVP Code 1) is used to integrity protect PANA messages. + The AVP data payload contains the Message Authentication Code encoded + in network byte order. The AVP length varies depending on the + integrity algorithm used. The AVP data is of type OctetString. + +8.2. EAP-Payload AVP + + 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 + authenticator. The AVP data is of type OctetString. + + + + + + + + +Forsberg, et al. Standards Track [Page 30] + +RFC 5191 PANA May 2008 + + +8.3. Integrity-Algorithm AVP + + The Integrity-Algorithm AVP (AVP Code 3) is used for conveying the + integrity algorithm to compute an AUTH AVP. The AVP data is of type + Unsigned32. The AVP data contains an Internet Key Exchange Protocol + version 2 (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 + + 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 + within the PANA session. + +8.5. Nonce AVP + + The Nonce AVP (AVP Code 5) carries a randomly chosen value that is + used in cryptographic key computations. The recommendations in + [RFC4086] apply with regard to generation of random values. The AVP + data is of type OctetString, and it contains a randomly generated + value in opaque format. The data length MUST be between 8 and 256 + octets, inclusive. + + The length of the nonces are determined based on the available + pseudo-random functions (PRFs) and the degree of trust placed into + the PaC and the PAA to compute random values. The length of the + random value for the nonce is determined in one of two ways, + depending on whether: + + 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 + has to be 1/2 the length of the PRF key (e.g., 10 octets in the + case of HMAC-SHA1). + + 2. The PaC and the PAA each are not trusted with regard to the + computation of a random nonce (according to [RFC4086]). The + length of the nonce has to have the full length of the PRF key + (e.g., 20 octets in the case of HMAC-SHA1). + + Furthermore, the strongest available PRF for PANA has to be + considered in this computation. Currently, only a single PRF (namely + HMAC-SHA1) is available and therefore the maximum output length is 20 + octets. Therefore, the maximum length of the nonce value SHOULD be + 20 octets. + + + + + + +Forsberg, et al. Standards Track [Page 31] + +RFC 5191 PANA May 2008 + + +8.6. PRF-Algorithm AVP + + 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-Code AVP values are described below. + + PANA_SUCCESS 0 + + Both authentication and authorization processes are successful. + + PANA_AUTHENTICATION_REJECTED 1 + + Authentication has failed. When authentication fails, + authorization is also considered to have failed. + + PANA_AUTHORIZATION_REJECTED 2 + + The authorization process has failed. This error could occur when + authorization is rejected by a AAA server or rejected locally by a + PAA, even if the authentication procedure has succeeded. + +8.8. Session-Lifetime AVP + + The Session-Lifetime AVP (AVP Code 8) contains the number of seconds + remaining before the current session is considered expired. The AVP + data is of type Unsigned32. + + + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 32] + +RFC 5191 PANA May 2008 + + +8.9. Termination-Cause AVP + + 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 + of type Enumerated. The following Termination-Cause data values are + used with PANA. + + LOGOUT 1 (PaC -> PAA) + + The client initiated a disconnect. + + ADMINISTRATIVE 4 (PAA -> PaC) + + The client was not granted access or was disconnected due to + administrative reasons. + + SESSION_TIMEOUT 8 (PAA -> PaC) + + The session has timed out, and service has been terminated. + +9. Retransmission Timers + + The PANA protocol provides retransmissions for the + PANA-Client-Initiation message and all request messages. + + PANA retransmission timers are based on the model used in DHCPv6 + [RFC3315]. Variables used here are also borrowed from this + specification. PANA is a request/response-based protocol. The + message exchange terminates when the requester successfully receives + the answer, or the message exchange is considered to have failed + according to the retransmission mechanism described below. + + The retransmission behavior is controlled and described by the + following variables: + + RT Retransmission timeout from the previous (re)transmission + + IRT Base value for RT for the initial retransmission + + MRC Maximum retransmission count + + MRT Maximum retransmission time + + MRD Maximum retransmission duration + + RAND Randomization factor + + + + + +Forsberg, et al. Standards Track [Page 33] + +RFC 5191 PANA May 2008 + + + With each message transmission or retransmission, the sender sets RT + according to the rules given below. If RT expires before the message + exchange terminates, the sender recomputes RT and retransmits the + message. + + Each of the computations of a new RT include a randomization factor + (RAND), which is a random number chosen with a uniform distribution + between -0.1 and +0.1. The randomization factor is included to + minimize the synchronization of messages. + + The algorithm for choosing a random number does not need to be + cryptographically sound. The algorithm SHOULD produce a different + sequence of random numbers from each invocation. + + RT for the first message retransmission is based on IRT: + + RT = IRT + RAND*IRT + + RT for each subsequent message retransmission is based on the + previous value of RT: + + RT = 2*RTprev + RAND*RTprev + + 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, + there is no upper limit on the value of RT. Otherwise: + + if (RT > MRT) + RT = MRT + RAND*MRT + + MRC specifies an upper bound on the number of times a sender may + retransmit a message. Unless MRC is zero, the message exchange fails + once the sender has transmitted the message MRC times. + + MRD specifies an upper bound on the length of time a sender may + retransmit a message. Unless MRD is zero, the message exchange fails + once MRD seconds have elapsed since the client first transmitted the + message. + + If both MRC and MRD are non-zero, the message exchange fails whenever + either of the conditions specified in the previous two paragraphs are + met. + + If both MRC and MRD are zero, the client continues to transmit the + message until it receives a response. + + + + + + +Forsberg, et al. Standards Track [Page 34] + +RFC 5191 PANA May 2008 + + +9.1. Transmission and Retransmission Parameters + + This section presents a table of values used to describe the message + retransmission behavior of PANA requests (REQ_*) and PANA-Client- + Initiation message (PCI_*). The table shows default values. + + Parameter Default Description + --------------------------------------------------------------------- + PCI_IRT 1 sec Initial PCI timeout. + PCI_MRT 120 secs Max PCI timeout value. + PCI_MRC 0 Max PCI retransmission attempts. + PCI_MRD 0 Max PCI retransmission duration. + + REQ_IRT 1 sec Initial Request timeout. + REQ_MRT 30 secs Max Request timeout value. + REQ_MRC 10 Max Request retransmission attempts. + REQ_MRD 0 Max Request retransmission duration. + + So, for example, the first RT for the PANA-Auth-Request (PAR) message + is calculated using REQ_IRT as the IRT: + + RT = REQ_IRT + RAND*REQ_IRT + +10. IANA Considerations + + This section provides guidance to the Internet Assigned Numbers + Authority (IANA) regarding the registration of values related to the + PANA protocol, in accordance with BCP 26 [IANA]. The following + policies are used here with the meanings defined in BCP 26: "Private + Use", "First Come First Served", "Expert Review", "Specification + Required", "IETF Consensus", and "Standards Action". + + This section explains the criteria to be used by the IANA for + assignment of numbers within namespaces defined within this document. + + For registration requests where a Designated Expert should be + consulted, the responsible IESG Area Director should appoint the + Designated Expert. For Designated Expert with Specification + Required, the request is posted to the PANA WG mailing list (or, if + it has been disbanded, a successor designated by the Area Director) + for comment and review, and MUST include a pointer to a public + specification. Before a period of 30 days has passed, the Designated + Expert will either approve or deny the registration request and + + + + + + + + +Forsberg, et al. Standards Track [Page 35] + +RFC 5191 PANA May 2008 + + + publish a notice of the decision to the PANA WG mailing list or its + successor. A denial notice must be justified by an explanation and, + in the cases where it is possible, concrete suggestions on how the + request can be modified so as to become acceptable. + + IANA has created a registry for PANA. + +10.1. PANA UDP Port Number + + PANA uses one well-known UDP port number (see Section 6.1), which has + been assigned by the IANA (716). + +10.2. PANA Message Header + + As defined in Section 6.2, the PANA message header contains two + fields that require IANA namespace management; the Message Type and + Flags fields. + +10.2.1. Message Type + + The Message Type namespace is used to identify PANA messages. + Message Type 0 is not used and is not assigned by IANA. The range of + values 1 - 65,519 are for permanent, standard message types, + allocated by IETF Consensus [IANA]. This document defines the range + 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 + distinguishes requests from answers. See Section 7 for the + assignment of the namespace in this specification. + + The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 - + 0xffff) are reserved for experimental messages. As these codes are + only for experimental and testing purposes, no guarantee is made for + interoperability between the communicating PaC and PAA using + experimental commands, as outlined in [IANA-EXP]. + +10.2.2. Flags + + 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'), 4 + ('P'), and 5 ('I') in Section 6.2. The remaining bits MUST only be + assigned via a Standards Action [IANA]. + +10.3. AVP Header + + As defined in Section 6.3, the AVP header contains three fields that + require IANA namespace management; the AVP Code, AVP Flags, and + Vendor-Id fields, where only the AVP Code and AVP Flags created new + namespaces. + + + +Forsberg, et al. Standards Track [Page 36] + +RFC 5191 PANA May 2008 + + +10.3.1. AVP Code + + The 16-bit AVP code namespace is used to identify attributes. There + are multiple namespaces. Vendors can have their own AVP codes + namespace, which will be identified by their Vendor-Id (also known as + Enterprise-Number), and they control the assignments of their + vendor-specific AVP codes within their own namespace. The absence of + a Vendor-Id identifies the IETF IANA controlled AVP codes namespace. + The AVP codes, and sometimes also possible values in an AVP, are + controlled and maintained by IANA. + + AVP Code 0 is not used and is not assigned by IANA. This document + defines the AVP Codes 1-9. See Section 8.1 through Section 8.9 for + the assignment of the namespace in this specification. + + AVPs may be allocated following Designated Expert Review with + Specification Required [IANA] or Standards Action. + + 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. + Vendor-Specific AVP codes are for Private Use and should be + encouraged instead of allocation of global attribute types, for + functions specific only to one vendor's implementation of PANA, where + no interoperability is deemed useful. Where a Vendor-Specific AVP is + implemented by more than one vendor, allocation of global AVPs should + be encouraged instead. + +10.3.2. Flags + + There are 16 bits in the AVP Flags field of the AVP header, defined + in Section 6.3. This document assigns bit 0 ('V'). The remaining + bits should only be assigned via a Standards Action . + +10.4. AVP Values + + Certain AVPs in PANA define a list of values with various meanings. + For attributes other than those specified in this section, adding + additional values to the list can be done on a First Come, First + Served basis by IANA [IANA]. + +10.4.1. Result-Code AVP Values + + As defined in Section 8.7, the Result-Code AVP (AVP Code 7) defines + the values 0-2. + + All remaining values are available for assignment via IETF Consensus + [IANA]. + + + + +Forsberg, et al. Standards Track [Page 37] + +RFC 5191 PANA May 2008 + + +10.4.2. Termination-Cause AVP Values + + As defined in Section 8.9, the Termination-Cause AVP (AVP Code 9) + defines the values 1, 4, and 8. + + All remaining values are available for assignment via IETF Consensus + [IANA]. + +11. Security Considerations + + The PANA protocol defines a UDP-based EAP encapsulation that runs + between two IP-enabled nodes. Various security threats that are + relevant to a protocol of this nature are outlined in [RFC4016]. + Security considerations stemming from the use of EAP and EAP methods + are discussed in [RFC3748] [EAP-KEYING]. This section provides a + discussion on the security-related issues that are related to PANA + framework and protocol design. + + An important element in assessing the security of PANA design and + deployment in a network is the presence of lower-layer security. In + the context of this document, lower layers are said to be secure if + the environment provides adequate protection against spoofing and + confidentiality based on its operational needs. For example, DSL and + cdma2000 networks' lower-layer security is enabled even before + running the first PANA-based authentication. In the absence of such + a preestablished secure channel prior to running PANA, one can be + created after the successful PANA authentication using a link-layer + or network-layer cryptographic mechanism (e.g., IPsec). + +11.1. General Security Measures + + PANA provides multiple mechanisms to secure a PANA session. + + PANA messages carry sequence numbers, which are monotonically + incremented by 1 with every new request message. These numbers are + randomly initialized at the beginning of the session, and they are + verified against expected numbers upon receipt. A message whose + sequence number is different than the expected one is silently + discarded. In addition to accomplishing orderly delivery of EAP + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 38] + +RFC 5191 PANA May 2008 + + + messages and duplicate elimination, this scheme also helps prevent an + adversary from spoofing messages to disturb ongoing PANA and EAP + sessions unless it can also eavesdrop to synchronize with the + expected sequence number. Furthermore, impact of replay attacks is + reduced as any stale message (i.e., a request or answer with an + unexpected sequence number and/or a session identifier for a + non-existing session) and any duplicate answer are immediately + discarded, and a duplicate request can trigger transmission of the + cached answer (i.e., no need to process the request and generate a + new answer). + + The PANA framework defines EP, which is ideally located on a network + device that can filter traffic from the PaCs before the traffic + enters the Internet/intranet. A set of filters can be used to + discard unauthorized packets, such as the initial PANA-Auth-Request + message that is received from the segment of the access network, + where only the PaCs are supposed to be connected (i.e., preventing + PAA impersonation). + + The protocol also provides authentication and integrity protection to + PANA messages when the used EAP method can generate cryptographic + session keys. A PANA SA is generated based on the MSK exported by + the EAP method. This SA is used for generating an AUTH AVP to + protect the PANA message header and payload (including the complete + EAP message). + + The cryptographic protection prevents an adversary from acting as a + man-in-the-middle, injecting messages, replaying messages and + modifying the content of the exchanged messages. Any packet that + fails to pass the AUTH verification is silently discarded. The + earliest this protection can be enabled is when the PANA-Auth-Request + message that signals a successful authentication (EAP Success) is + generated. Starting with these messages, any subsequent PANA message + can be cryptographically protected until the session gets torn down. + + The lifetime of the PANA SA is set to the PANA session lifetime, + which is bounded by the authorization lifetime granted by the + authentication server. An implementation MAY add a grace period to + that value. Unless the PANA session is extended by executing another + EAP authentication, the PANA SA is removed when the current session + expires. + + + + + + + + + + +Forsberg, et al. Standards Track [Page 39] + +RFC 5191 PANA May 2008 + + + The ability to use cryptographic protection within PANA is determined + by the used EAP method, which is generally dictated by the deployment + environment. Insecure lower layers necessitate the use of + key-generating EAP methods. In networks where lower layers are + already secured, cryptographic protection of PANA messages is not + necessary. + +11.2. Initial Exchange + + The initial PANA-Auth-Request and PANA-Auth-Answer exchange is + vulnerable to spoofing attacks as these messages are not + authenticated and integrity protected. In order to prevent very + basic DoS attacks, an adversary should not be able to cause state + creation by sending PANA-Client-Initiation messages to the PAA. This + protection is achieved by allowing the responder (PAA) to create as + little state as possible in the initial message exchange. However, + it is difficult to prevent all spoofing attacks in the initial + message exchange entirely. + +11.3. EAP Methods + + Eavesdropping EAP messages might cause problems when the EAP method + is weak and enables dictionary or replay attacks or even allows an + adversary to learn the long-term password directly. Furthermore, if + 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 problem is prevalent. + + To prevent these threats, [RFC5193] suggests using proper EAP methods + for particular environments. Depending on the deployment + environment, an EAP authentication method that supports user-identity + confidentiality, protection against dictionary attacks, and + session-key establishment must be used. It is therefore the + responsibility of the network operators and users to choose a proper + EAP method. + +11.4. Cryptographic Keys + + When the EAP method exports an MSK, this key is used to produce a + PANA SA with PANA_AUTH_KEY with a distinct key ID. The PANA_AUTH_KEY + is unique to the PANA session, and it takes PANA-based nonce values + into computation to cryptographically separate itself from the MSK. + + The PANA_AUTH_KEY is solely used for the authentication and integrity + protection of the PANA messages within the designated session. + + + + + + +Forsberg, et al. Standards Track [Page 40] + +RFC 5191 PANA May 2008 + + + The PANA SA lifetime is bounded by the MSK lifetime. Another + execution of the EAP method yields a new MSK, and it updates the PANA + SA, PANA_AUTH_KEY, and key ID. + +11.5. Per-Packet Ciphering + + Networks that are not secured at the lower layers prior to running + PANA can rely on enabling per-packet data-traffic ciphering upon + successful PANA SA establishment. The PANA framework allows + generation of cryptographic keys from the PANA SA and uses the keys + with a secure association protocol to enable per-packet cryptographic + protection, such as link-layer or IPsec-based ciphering [PANA-IPSEC]. + These mechanisms ultimately establish a cryptographic binding between + the data traffic generated by and for a client and the authenticated + identity of the client. Data traffic can be data origin + authenticated, replay and integrity protected, and optionally + encrypted using the cryptographic keys. How these keys are generated + from the PANA SA and used with a secure association protocol is + outside the scope of this document. + +11.6. PAA-to-EP Communication + + The PANA framework allows separation of PAA from EP. The protocol + exchange between the PAA and EP for provisioning authorized PaC + information on the EP must be protected for authentication, + integrity, and replay protection. + +11.7. Liveness Test + + A PANA session is associated with a session lifetime. The session is + terminated unless it is refreshed by a new round of EAP + authentication before it expires. Therefore, the latest a + disconnected client can be detected is when its session expires. A + disconnect may also be detected earlier by using PANA ping messages. + + + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 41] + +RFC 5191 PANA May 2008 + + + A request message can be generated by either PaC or PAA at any time + in access phase with the expectation that the peer responds with an + answer message. A successful round-trip of this exchange is a simple + verification that the peer is alive. + + This test can be engaged when there is a possibility that the peer + might have disconnected (e.g., after the discontinuation of data + traffic for an extended period of time). Periodic use of this + exchange as a keep-alive requires additional care, as it might result + in congestion and hence false alarms. + + This exchange is cryptographically protected when a PANA SA is + available in order to prevent threats associated with the abuse of + this functionality. + + Any valid PANA answer message received in response to a recently sent + request message can be taken as an indication of a peer's liveness. + The PaC or PAA MAY forgo sending an explicit ping request message if + a recent exchange has already confirmed that the peer is alive. + +11.8. Early Termination of a Session + + The PANA protocol supports the ability for both the PaC and the PAA + to transmit a tear-down message before the session lifetime expires. + This message causes state removal, a stop of the accounting procedure + and removes the installed per-PaC state on the EP(s). This message + is cryptographically protected when PANA SA is present. + +12. Acknowledgments + + We would like to thank Mark Townsley, Jari Arkko, Mohan + Parthasarathy, Julien Bournelle, Rafael Marin Lopez, Pasi Eronen, + Randy Turner, Erik Nordmark, Lionel Morand, Avi Lior, Susan Thomson, + Giaretta Gerardo, Joseph Salowey, Sasikanth Bharadwaj, Spencer + Dawkins, Tom Yu, Bernard Aboba, Subir Das, John Vollbrecht, Prakash + Jayaraman, and all members of the PANA working group for their + valuable comments on this document. + +13. References + +13.1. Normative References + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + +Forsberg, et al. Standards Track [Page 42] + +RFC 5191 PANA May 2008 + + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and + J. Arkko, "Diameter Base Protocol", RFC 3588, September + 2003. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and + H. Levkowetz, Ed., "Extensible Authentication Protocol + (EAP)", RFC 3748, June 2004. + + [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC + 4086, June 2005. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, January + 2008. + + [RFC5192] Morand, L., Yegin A., Kumar S., and S. Madanapalli, + "DHCP Options for Protocol for Carrying Authentication + for Network Access (PANA) Authentication Agents", RFC + 5192, May 2008. + + [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + +13.2. Informative References + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., + Perkins, C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC4016] Parthasarathy, M., "Protocol for Carrying + Authentication and Network Access (PANA) Threat + Analysis and Security Requirements", RFC 4016, March + 2005. + + [RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and + C. Wang, "Protocol for Carrying Authentication for + Network Access (PANA) Requirements", RFC 4058, May + 2005. + + [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, + "State Machines for Extensible Authentication Protocol + (EAP) Peer and Authenticator", RFC 4137, August 2005. + + [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) + Protocol", RFC 4306, December 2005. + + + + +Forsberg, et al. Standards Track [Page 43] + +RFC 5191 PANA May 2008 + + + [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre + Channel Security Association Management Protocol", RFC + 4595, July 2006. + + [RFC5193] Jayaraman, P., Lopez R., Ohba Y., Ed., Parthasarathy, + M., and A. Yegin, "Protocol for Carrying Authentication + for Network Access (PANA) Framework", RFC 5193, May + 2008. + + [EAP-KEYING] Aboba, B., Simon D., and P. Eronen, "Extensible + Authentication Protocol (EAP) Key Management + Framework", Work in Progress, November 2007. + + [PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access + Control", Work in progress, July 2005. + + [IANAWEB] IANA, "Number assignment", http://www.iana.org. + + [IANA-EXP] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, January 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 44] + +RFC 5191 PANA May 2008 + + +Authors' Addresses + + Dan Forsberg + Nokia Research Center + P.O. Box 407 + FIN-00045 NOKIA GROUP + Finland + + Phone: +358 50 4839470 + EMail: dan.forsberg@nokia.com + + + Yoshihiro Ohba + Toshiba America Research, Inc. + 1 Telcordia Drive + Piscataway, NJ 08854 + USA + + Phone: +1 732 699 5305 + EMail: yohba@tari.toshiba.com + + + Basavaraj Patil + Nokia Siemens Networks + 6000 Connection Drive + Irving, TX 75039 + USA + + EMail: basavaraj.patil@nsn.com + + + Hannes Tschofenig + Nokia Siemens Networks + Linnoitustie 6 Espoo 02600 + Finland + + Phone: +358 (50) 4871445 + EMail: Hannes.Tschofenig@nsn.com + URI: http://www.tschofenig.priv.at + + Alper E. Yegin + Samsung + Istanbul, Turkey + + EMail: a.yegin@partner.samsung.com + + + + + + +Forsberg, et al. Standards Track [Page 45] + +RFC 5191 PANA May 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Forsberg, et al. Standards Track [Page 46] + |