draft-ietf-pana-pana-07.txt   draft-ietf-pana-pana-08.txt 
PANA Working Group D. Forsberg PANA Working Group D. Forsberg
Internet-Draft Nokia Internet-Draft Nokia
Expires: June 29, 2005 Y. Ohba (Ed.) Expires: November 11, 2005 Y. Ohba (Ed.)
Toshiba Toshiba
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
A. Yegin A. Yegin
Samsung Samsung
December 29, 2004 May 10, 2005
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-07 draft-ietf-pana-pana-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 29, 2005. This Internet-Draft will expire on November 11, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines the Protocol for Carrying Authentication for This document defines the Protocol for Carrying Authentication for
Network Access (PANA), a link-layer agnostic transport for Extensible Network Access (PANA), a link-layer agnostic transport for Extensible
Authentication Protocol (EAP) to enable network access authentication Authentication Protocol (EAP) to enable network access authentication
between clients and access networks. PANA can carry any between clients and access networks. PANA can carry any
authentication method that can be specified as an EAP method, and it authentication method that can be specified as an EAP method, and it
can be used on any link that can carry IP. PANA protocol can be used on any link that can carry IP. PANA protocol
specification covers the client-to-network access authentication part specification covers the client-to-network access authentication part
of an overall secure network access framework, which additionally of an overall secure network access framework, which additionally
includes other protocols and mechanisms for service provisioning, includes other protocols and mechanisms for service provisioning,
access control as a result of initial authentication, and accounting. access control as a result of initial authentication, and accounting.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Specification of Requirements . . . . . . . . . . . . . . 5 1.1 Specification of Requirements . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 11 4.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 11
4.2 Discovery and Handshake Phase . . . . . . . . . . . . . . 12 4.2 Discovery and Handshake Phase . . . . . . . . . . . . . . 12
4.3 Authentication and Authorization Phase . . . . . . . . . . 15 4.3 Authentication and Authorization Phase . . . . . . . . . . 16
4.4 Access Phase . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 Access Phase . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Re-authentication Phase . . . . . . . . . . . . . . . . . 19 4.5 Re-authentication Phase . . . . . . . . . . . . . . . . . 19
4.6 Termination Phase . . . . . . . . . . . . . . . . . . . . 20 4.6 Termination Phase . . . . . . . . . . . . . . . . . . . . 21
4.7 Separate NAP and ISP Authentication . . . . . . . . . . . 21 4.7 Separate NAP and ISP Authentication . . . . . . . . . . . 22
4.7.1 Negotiating Separate NAP and ISP Authentication . . . 21 4.7.1 Negotiating Separate NAP and ISP Authentication . . . 22
4.7.2 Execution of Separate NAP and ISP Authentication . . . 22 4.7.2 Execution of Separate NAP and ISP Authentication . . . 23
4.7.3 AAA-Key Calculation . . . . . . . . . . . . . . . . . 23 4.7.3 AAA-Key Calculation . . . . . . . . . . . . . . . . . 24
5. Protocol Design Details and Processing Rules . . . . . . . . 24 5. Protocol Design Details and Processing Rules . . . . . . . . 25
5.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 24 5.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 24 5.1.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 25
5.2 Sequence Number and Retransmission . . . . . . . . . . . . 24 5.2 Sequence Number and Retransmission . . . . . . . . . . . . 25
5.3 PANA Security Association . . . . . . . . . . . . . . . . 25 5.3 PANA Security Association . . . . . . . . . . . . . . . . 26
5.4 Message Authentication Code . . . . . . . . . . . . . . . 27 5.4 Message Authentication Code . . . . . . . . . . . . . . . 29
5.5 Message Validity Check . . . . . . . . . . . . . . . . . . 28 5.5 Message Validity Check . . . . . . . . . . . . . . . . . . 29
5.6 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 29 5.6 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 31
5.7 PaC Updating its IP Address . . . . . . . . . . . . . . . 30 5.7 PaC Updating its IP Address . . . . . . . . . . . . . . . 32
5.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 30 5.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 32
5.9 Network Selection . . . . . . . . . . . . . . . . . . . . 31 5.9 Network Selection . . . . . . . . . . . . . . . . . . . . 33
5.10 Error Handling . . . . . . . . . . . . . . . . . . . . . 32 5.10 Error Handling . . . . . . . . . . . . . . . . . . . . . 34
6. PANA Headers and Formats . . . . . . . . . . . . . . . . . . 33 6. PANA Headers and Formats . . . . . . . . . . . . . . . . . . 35
6.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 33 6.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 35
6.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 33 6.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 38
7. PANA Messages, Message Specifications and AVPs . . . . . . . 38 7. PANA Messages, Message Specifications and AVPs . . . . . . . 42
7.1 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 38 7.1 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 42
7.2 PANA Message ABNF Specification . . . . . . . . . . . . . 38 7.2 PANA Message ABNF Specification . . . . . . . . . . . . . 42
7.2.1 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . 40 7.2.1 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . 44
7.2.2 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . 41 7.2.2 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . 45
7.2.3 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . 41 7.2.3 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . 45
7.2.4 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . 41 7.2.4 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . 45
7.2.5 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . 42 7.2.5 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . 46
7.2.6 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . 42 7.2.6 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . 46
7.2.7 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . 42 7.2.7 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . 46
7.2.8 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . 42 7.2.8 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . 46
7.2.9 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . 43 7.2.9 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . 47
7.2.10 PANA-Ping-Request (PPR) . . . . . . . . . . . . . . 43 7.2.10 PANA-Ping-Request (PPR) . . . . . . . . . . . . . . 47
7.2.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . 43 7.2.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . 47
7.2.12 PANA-Termination-Request (PTR) . . . . . . . . . . . 44 7.2.12 PANA-Termination-Request (PTR) . . . . . . . . . . . 48
7.2.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . 44 7.2.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . 48
7.2.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . 44 7.2.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . 48
7.2.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . 44 7.2.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . 49
7.2.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 45 7.2.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 49
7.2.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 45 7.2.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 49
7.2.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . 45 7.2.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . 49
7.2.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 46 7.2.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 50
7.3 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 46 7.3 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 50
7.3.1 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 48 7.3.1 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 52
7.3.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 48 7.3.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 52
7.3.3 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 49 7.3.3 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 53
7.3.4 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . 49 7.3.4 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . 53
7.3.5 IP-Address AVP . . . . . . . . . . . . . . . . . . . . 49 7.3.5 ISP-Information AVP . . . . . . . . . . . . . . . . . 53
7.3.6 ISP-Information AVP . . . . . . . . . . . . . . . . . 49 7.3.6 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . 53
7.3.7 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . 49 7.3.7 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 53
7.3.8 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 50 7.3.8 NAP-Information AVP . . . . . . . . . . . . . . . . . 54
7.3.9 NAP-Information AVP . . . . . . . . . . . . . . . . . 50 7.3.9 Nonce AVP . . . . . . . . . . . . . . . . . . . . . . 54
7.3.10 Nonce AVP . . . . . . . . . . . . . . . . . . . . . 50 7.3.10 Notification AVP . . . . . . . . . . . . . . . . . . 54
7.3.11 Notification AVP . . . . . . . . . . . . . . . . . . 50 7.3.11 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 55
7.3.12 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 51 7.3.12 Protection-Capability AVP . . . . . . . . . . . . . 56
7.3.13 Protection-Capability AVP . . . . . . . . . . . . . 52 7.3.13 Provider-Identifier AVP . . . . . . . . . . . . . . 56
7.3.14 Provider-Identifier AVP . . . . . . . . . . . . . . 52 7.3.14 Provider-Name AVP . . . . . . . . . . . . . . . . . 56
7.3.15 Provider-Name AVP . . . . . . . . . . . . . . . . . 52 7.3.15 Result-Code AVP . . . . . . . . . . . . . . . . . . 56
7.3.16 Result-Code AVP . . . . . . . . . . . . . . . . . . 52 7.3.16 Session-Id AVP . . . . . . . . . . . . . . . . . . . 61
7.3.17 Session-Id AVP . . . . . . . . . . . . . . . . . . . 56 7.3.17 Session-Lifetime AVP . . . . . . . . . . . . . . . . 61
7.3.18 Session-Lifetime AVP . . . . . . . . . . . . . . . . 56 7.3.18 Termination-Cause AVP . . . . . . . . . . . . . . . 61
7.3.19 Termination-Cause AVP . . . . . . . . . . . . . . . 56 8. Retransmission Timers . . . . . . . . . . . . . . . . . . . 62
8. Retransmission Timers . . . . . . . . . . . . . . . . . . . 58 8.1 Transmission and Retransmission Parameters . . . . . . . . 63
8.1 Transmission and Retransmission Parameters . . . . . . . . 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 65
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 61 9.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 65
9.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 61 9.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 65
9.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 61 9.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 65
9.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 61 9.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . 65
9.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . 61 9.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 66
9.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 62 9.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 66
9.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 62 9.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . 66
9.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . 62 9.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 67
9.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 63 9.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 67
9.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 63 9.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . . 67
9.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . . 63 9.5.2 Post-PANA-Address-Configuration AVP Values . . . . . . 67
9.5.2 Post-PANA-Address-Configuration AVP Values . . . . . . 63 9.5.3 Protection-Capability AVP Values . . . . . . . . . . . 67
9.5.3 Protection-Capability AVP Values . . . . . . . . . . . 63 9.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . 67
9.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . 63 9.5.5 Termination-Cause AVP Values . . . . . . . . . . . . . 68
9.5.5 Termination-Cause AVP Values . . . . . . . . . . . . . 64 10. Security Considerations . . . . . . . . . . . . . . . . . . 69
10. Security Considerations . . . . . . . . . . . . . . . . . . 65 10.1 General Security Measures . . . . . . . . . . . . . . . 69
10.1 General Security Measures . . . . . . . . . . . . . . . 65 10.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 70
10.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 66 10.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 71
10.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 67 10.4 Separate NAP and ISP Authentication . . . . . . . . . . 71
10.4 Separate NAP and ISP Authentication . . . . . . . . . . 67 10.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 71
10.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 67 10.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 72
10.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 68 10.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 72
10.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 68 10.8 Liveness Test . . . . . . . . . . . . . . . . . . . . . 73
10.8 Liveness Test . . . . . . . . . . . . . . . . . . . . . 69 10.9 Updating PaC's IP Address . . . . . . . . . . . . . . . 73
10.9 Updating PaC's IP Address . . . . . . . . . . . . . . . 69 10.10 Early Termination of a Session . . . . . . . . . . . . . 73
10.10 Early Termination of a Session . . . . . . . . . . . . . 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 74
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 12.1 Normative References . . . . . . . . . . . . . . . . . . 75
12.1 Normative References . . . . . . . . . . . . . . . . . . . 71 12.2 Informative References . . . . . . . . . . . . . . . . . 76
12.2 Informative References . . . . . . . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 73 A. Example Sequence of Separate NAP and ISP Authentication . . 79
A. Example Sequence of Separate NAP and ISP Authentication . . 75 Intellectual Property and Copyright Statements . . . . . . . 82
Intellectual Property and Copyright Statements . . . . . . . 77
1. Introduction 1. Introduction
Providing secure network access service requires access control based Providing secure network access service requires access control based
on the authentication and authorization of the clients and the access on the authentication and authorization of the clients and the access
networks. Client-to-network authentication provides parameters that networks. Client-to-network authentication provides parameters that
are needed to police the traffic flow through the enforcement points. are needed to police the traffic flow through the enforcement points.
A protocol is needed to carry authentication methods between the A protocol is needed to carry authentication methods between the
client and the access network. client and the access network.
Currently there is no standard network-layer solution for Currently there is no standard network-layer solution for
authenticating clients for network access. Appendix A of authenticating clients for network access. Appendix A of [I-D.ietf-
[I-D.ietf-pana-requirements] describes the problem statement that led pana-requirements] describes the problem statement that led to the
to the development of PANA. development of PANA.
Scope of this work is identified as designing a link-layer agnostic Scope of this work is identified as designing a link-layer agnostic
transport for network access authentication methods. The Extensible transport for network access authentication methods. The Extensible
Authentication Protocol (EAP) [RFC3748] provides such authentication Authentication Protocol (EAP) [RFC3748] provides such authentication
methods. In other words, PANA will carry EAP which can carry various methods. In other words, PANA will carry EAP which can carry various
authentication methods. By the virtue of enabling transport of EAP authentication methods. By the virtue of enabling transport of EAP
above IP, any authentication method that can be carried as an 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 method is made available to PANA and hence to any link-layer
technology. There is a clear division of labor between PANA (an EAP technology. There is a clear division of labor between PANA (an EAP
lower layer), EAP and EAP methods as described in [RFC3748]. lower layer), EAP and EAP methods as described in [RFC3748].
Various environments and usage models for PANA are identified in Various environments and usage models for PANA are identified in
Appendix A of [I-D.ietf-pana-requirements]. Potential security Appendix A of [I-D.ietf-pana-requirements]. Potential security
threats for network-layer access authentication protocol are threats for network-layer access authentication protocol are
discussed in [I-D.ietf-pana-threats-eval]. These have been essential discussed in [RFC4016]. These have been essential in defining the
in defining the requirements [I-D.ietf-pana-requirements] on the PANA requirements [I-D.ietf-pana-requirements] on the PANA protocol. Note
protocol. Note that some of these requirements are imposed by the that some of these requirements are imposed by the chosen payload,
chosen payload, EAP [RFC3748]. EAP [RFC3748].
There are components that are part of a complete secure network There are components that are part of a complete secure network
solution but are outside of the PANA protocol specification, solution but are outside of the PANA protocol specification,
including IP address configuration, authentication method choice, including IP address configuration, authentication method choice,
filter rule installation, data traffic protection and PAA-EP filter rule installation, data traffic protection and PAA-EP
protocol. These components are described in separate documents (see protocol. These components are described in separate documents (see
[I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp]). The readers are [I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp]). The readers are
recommended to go through the PANA Framework document recommended to go through the PANA Framework document [I-D.ietf-pana-
[I-D.ietf-pana-framework] prior to reading this protocol framework] prior to reading this protocol specification document.
specification document.
1.1 Specification of Requirements 1.1 Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
PANA Client (PaC): PANA Client (PaC):
The client side of the protocol that resides in the access device The client side of the protocol that resides in the access device
(e.g., laptop, PDA, etc.). It is responsible for providing the (e.g., laptop, PDA, etc.). It is responsible for providing the
credentials in order to prove its identity (authentication) for credentials in order to prove its identity (authentication) for
network access authorization. The PaC and the EAP peer are network access authorization. The PaC and the EAP peer are co-
co-located in the same access device. located in the same access device.
PANA Authentication Agent (PAA): PANA Authentication Agent (PAA):
The protocol entity in the access network whose responsibility is The protocol entity in the access network whose responsibility is
to verify the credentials provided by a PANA client (PaC) and to verify the credentials provided by a PANA client (PaC) and
authorize network access to the device associated with the client authorize network access to the device associated with the client
and identified by a Device Identifier (DI). The PAA and the EAP and identified by a Device Identifier (DI). The PAA and the EAP
authenticator (and optionally the EAP server) are co-located in authenticator (and optionally the EAP server) are co-located in
the same node. Note the authentication and authorization the same node. Note the authentication and authorization
procedure can, according to the EAP model, be also offloaded to procedure can, according to the EAP model, be also offloaded to
skipping to change at page 9, line 34 skipping to change at page 9, line 34
new PANA session. The PaC discovers the PAA(s) by either new PANA session. The PaC discovers the PAA(s) by either
explicitly soliciting advertisements for them or receiving explicitly soliciting advertisements for them or receiving
unsolicited advertisements. The PaC's answer sent in response to unsolicited advertisements. The PaC's answer sent in response to
an advertisement starts a new session. an advertisement starts a new session.
o Authentication and authorization phase: Immediately following the o Authentication and authorization phase: Immediately following the
discovery and handshake phase is the EAP execution between the PAA discovery and handshake phase is the EAP execution between the PAA
and PaC. The EAP payload (which carry an EAP method inside) is and PaC. The EAP payload (which carry an EAP method inside) is
what is used for authentication. The PAA conveys the result of what is used for authentication. The PAA conveys the result of
authentication and authorization to the PaC at the end of this authentication and authorization to the PaC at the end of this
phase. This phase may involve execution of two EAP sessions phase. This phase may involve execution of two EAP sessions back-
back-to-back, one for the NAP and one for the ISP. to-back, one for the NAP and one for the ISP.
o Access phase: After a successful authentication and authorization o Access phase: After a successful authentication and authorization
the host gains access to the network and can send and receive IP the host gains access to the network and can send and receive IP
data traffic through the EP(s). At any time during this phase, data traffic through the EP(s). At any time during this phase,
the PaC and PAA may optionally ping each other to test liveness of the PaC and PAA may optionally ping each other to test liveness of
the PANA session on each end. the PANA session on each end.
o Re-authentication phase: Following the access phase, the PAA must o Re-authentication phase: Following the access phase, the PAA must
initiate re-authentication before the PANA session lifetime initiate re-authentication before the PANA session lifetime
expires. Again EAP is carried by PANA to perform authentication. expires. Again EAP is carried by PANA to perform authentication.
skipping to change at page 12, line 14 skipping to change at page 12, line 24
o Key-Id AVP: contains a AAA-Key identifier. o Key-Id AVP: contains a AAA-Key identifier.
o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate
the available/chosen IP address configuration methods that can be the available/chosen IP address configuration methods that can be
used by the PaC after successful PANA authentication. used by the PaC after successful PANA authentication.
o Nonce AVP: contains a randomly chosen value that is used in o Nonce AVP: contains a randomly chosen value that is used in
cryptographic key computations. cryptographic key computations.
o IP-Address AVP: contains an IP Address of the PaC.
o Notification AVP: contains a displayable message. o Notification AVP: contains a displayable message.
4.2 Discovery and Handshake Phase 4.2 Discovery and Handshake Phase
When a PaC attaches to a network, and knows that it has to discover a When a PaC attaches to a network, and it does not already know the IP
PAA, it SHOULD send a PANA-PAA-Discover message to a well-known link address of the PAA, it MUST rely on dynamic discovery methods, such
local multicast address (TBD) and UDP port (TBD). The PAA discovery as a multicast-based and a traffic-driven discovery.
assumes that the PaC and the PAA are one IP hop away from each other.
If the PaC knows the IP address of the PAA (based on
pre-configuration), it MAY unicast the PANA-PAA-Discover message to
that address.
When the PAA receives a PANA-PAA-Discover message from a PaC, the PAA The PaCs and PAAs MUST implement multicast-based discovery where the
SHOULD unicast a PANA-Start-Request message to the PaC. PaC sends a PANA-PAA-Discover message to a well-known
administratively scoped multicast address (TBD) and UDP port (TBD).
The PaC MAY also choose to start sending data packets before getting The network administrator MUST configure the multicast scope such
authenticated. The EP in an access network that implements PANA that the discovery messages can reach only the designated PAA(s). In
SHOULD drop unauthorized packets upon receipt. Additionally, the EP case the PAA(s) is on the same link as the PaC, the administratively
MAY also take this traffic as an indication of unauthorized PaC and scoped multicast messages MUST not be forwarded by the routers.
notify the PAA. The EP-to-PAA notification SHOULD be sent via Details of scope configuration are discussed in [RFC2365].
[I-D.ietf-pana-snmp]. In response, the PAA SHOULD send an
unsolicited PANA-Start-Request message to the PaC. This is called The PAA(s) that receive the discovery message MUST respond with a
"traffic-driven PAA discovery" (an alternative to the PaC explicitly unicast PANA-Start-Request message sent to the soliciting PaC.
soliciting for a PAA). Note that this optional feature MAY NOT be
present in all deployments, therefore the PaC MUST NOT assume its Alternatively, the PaC MAY also choose to start sending data packets
availability. The EP-to-PAA notification MAY also be generated in before getting authenticated. The EP in an access network that
response to receiving a link-up event notification on the EP implements PANA SHOULD drop such unauthorized packets upon receipt.
[I-D.ietf-dna-link-information]. Additionally, the EP MAY also take this traffic as an indication of
unauthorized PaC and notify the PAA. The EP-to-PAA notification
SHOULD be sent via [I-D.ietf-pana-snmp]. In response, the PAA SHOULD
send an unsolicited PANA-Start-Request message to the PaC. This is
called traffic-driven PAA discovery (an alternative to the PaC
explicitly soliciting for a PAA). Deployment of this alternate
scheme is optional.
The EP-to-PAA notification MAY also be generated in response to
receiving a link-up event notification on the EP [I-D.ietf-dna-link-
information].
Alternative PAA discovery schemes may be designed (e.g., DHCP-based)
but they are outside the scope of this specification.
If the PaC knows the IP address of the PAA, it can send a unicast
PANA-PAA-Discover message and initiate the PANA exchange.
When the PaC receives a PANA-Start-Request message from a PAA, it When the PaC receives a PANA-Start-Request message from a PAA, it
responds with a PANA-Start-Answer message if it wishes to enter the responds with a PANA-Start-Answer message if it wishes to enter the
authentication and authorization phase. authentication and authorization phase.
There can be multiple PAAs on the link and the PaC may receive There can be multiple PAAs on the link and the PaC may receive
multiple PANA-Start-Request messages from those PAAs. The multiple PANA-Start-Request messages from those PAAs. The
authentication and authorization result does not depend on which PAA authentication and authorization result does not depend on which PAA
is chosen by the PaC. By default the PaC MAY choose the PAA that is chosen by the PaC. By default the PaC MAY choose the PAA that
sent the first response. sent the first response.
skipping to change at page 13, line 23 skipping to change at page 14, line 4
the cookie MUST be computed in such a way that it does not require the cookie MUST be computed in such a way that it does not require
any per-session state maintenance on the PAA in order to verify the any per-session state maintenance on the PAA in order to verify the
cookie returned in the PANA-Start-Answer message. The PAA discovery cookie returned in the PANA-Start-Answer message. The PAA discovery
that takes advantage of cookies is called "stateless PAA discovery". that takes advantage of cookies is called "stateless PAA discovery".
The exact algorithms and syntax used by the PAA to generate cookies The exact algorithms and syntax used by the PAA to generate cookies
does not affect interoperability and hence is not specified here. An does not affect interoperability and hence is not specified here. An
example algorithm is described below. example algorithm is described below.
Cookie = Cookie =
<secret-version> | HMAC_SHA1( <Device-Id of PaC> , <secret> ) <secret-version> | HMAC_SHA1( <Device-Id of PaC> , <secret> )
where <secret> is a randomly generated secret known only to the PAA, where <secret> is a randomly generated secret known only to the PAA,
<secret-version> is an index used for choosing the secret for <secret-version> is an index used for choosing the secret for
generating the cookie and '|' indicates concatenation. The generating the cookie and '|' indicates concatenation. The secret-
secret-version should be changed frequently enough to prevent replay version should be changed frequently enough to prevent replay
attacks. The secret key is valid for a certain time frame. The attacks. The secret key is valid for a certain time frame. The
device identifier of the PaC can be extracted from a link-layer or IP device identifier of the PaC can be extracted from a link-layer or IP
header of PANA messages. header of PANA messages.
When the PaC sends a PANA-Start-Answer message in response to a When the PaC sends a PANA-Start-Answer message in response to a PANA-
PANA-Start-Request containing a Cookie AVP, the answer MUST contain a Start-Request containing a Cookie AVP, the answer MUST contain a
Cookie AVP with the cookie value copied from the request. Cookie AVP with the cookie value copied from the request.
When the PAA receives the PANA-Start-Answer message from the PaC, it When the PAA receives the PANA-Start-Answer message from the PaC, it
verifies the cookie. The cookie is considered as valid if the verifies the cookie. The cookie is considered as valid if the
received cookie has the expected value. If the computed cookie is received cookie has the expected value. If the computed cookie is
valid, the protocol enters the authentication and authorization valid, the protocol enters the authentication and authorization
phase. Otherwise, it MUST silently discard the received message. phase. Otherwise, it MUST silently discard the received message.
The initial EAP Request message MAY be optionally carried by the The initial EAP Request message MAY be optionally carried by the
PANA-Start-Request (as opposed to by a later PANA-Auth-Request) PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
skipping to change at page 14, line 12 skipping to change at page 14, line 40
A Protection-Capability AVP and a Post-PANA-Address-Configuration A Protection-Capability AVP and a Post-PANA-Address-Configuration
(PPAC) AVP MAY be included in the PANA-Start-Request in order to (PPAC) AVP MAY be included in the PANA-Start-Request in order to
indicate required and available capabilities for the network access. indicate required and available capabilities for the network access.
These AVPs MAY be used by the PaC for assessing the capability match These AVPs MAY be used by the PaC for assessing the capability match
even before the authentication takes place. Since these AVPs are even before the authentication takes place. Since these AVPs are
provided during the insecure discovery and handshake phase, there are provided during the insecure discovery and handshake phase, there are
certain security risks involved in using the provided information. certain security risks involved in using the provided information.
See Section 10 for further discussion on this. See Section 10 for further discussion on this.
If the initial EAP Request message is carried in the If the initial EAP Request message is carried in the PANA-Start-
PANA-Start-Request message, an EAP Response message MUST be carried Request message, an EAP Response message MUST be carried in the PANA-
in the PANA-Start-Answer message returned to the PAA. Start-Answer message returned to the PAA.
The PANA-Start-Request/Answer exchange is needed before entering the The PANA-Start-Request/Answer exchange is needed before entering the
authentication and authorization phase even when the PaC is authentication and authorization phase even when the PaC is pre-
pre-configured with the IP address of the PAA and the configured with the IP address of the PAA and the PANA-PAA-Discover
PANA-PAA-Discover message is unicast. message is unicast.
A Nonce AVP MUST be included in the PANA-Start-Request and A Nonce AVP MUST be included in the PANA-Start-Request and PANA-
PANA-Start-Answer messages. The nonces are used to establish a fresh Start-Answer messages. The nonces are used to establish a fresh
PANA_MAC_KEY (see Section 5.3) which is a transient session key in PANA_MAC_KEY (see Section 5.3) which is a transient session key in
the EAP key hierarchy [I-D.ietf-eap-keying] and is used only in the the EAP key hierarchy [I-D.ietf-eap-keying] and is used only in the
PANA protocol. A Nonce AVP MUST be included in the PANA protocol. A Nonce AVP MUST be included in the PANA-Start-
PANA-Start-Request and PANA-Start-Answer messages. The nonces are Request and PANA-Start-Answer messages. The nonces are used to
used to establish a PANA SA. establish a PANA SA.
A PANA-Start-Request message in stateless PAA discovery MUST NOT be A PANA-Start-Request message in stateless PAA discovery MUST NOT be
retransmitted as this voids the statelessness on the PAA. Instead, retransmitted as this voids the statelessness on the PAA. Instead,
the PaC MUST retransmit the PANA-PAA-Discover message until it the PaC MUST retransmit the PANA-PAA-Discover message until it
receives a PANA-Start-Request message, and retransmit the receives a PANA-Start-Request message, and retransmit the PANA-Start-
PANA-Start-Answer message until it receives a PANA-Auth-Request Answer message until it receives a PANA-Auth-Request message. The
message. The PaC can determine whether the PAA is using stateless PaC can determine whether the PAA is using stateless PAA discovery by
PAA discovery by the presence of Cookie AVP. The PANA-Start-Request the presence of Cookie AVP. The PANA-Start-Request message MUST be
message MUST be retransmitted instead of the PANA-Start-Answer retransmitted instead of the PANA-Start-Answer message when stateless
message when stateless PAA discovery is not used. PAA discovery is not used.
It is possible that both the PAA and the PaC initiate the discovery It is possible that both the PAA and the PaC initiate the discovery
and handshake procedure at the same time, i.e., the PAA sends a and handshake procedure at the same time, i.e., the PAA sends a PANA-
PANA-Start-Request message while the PaC sends a PANA-PAA-Discover Start-Request message while the PaC sends a PANA-PAA-Discover
message. To resolve the race condition, the PAA SHOULD silently message. To resolve the race condition, the PAA SHOULD silently
discard the PANA-PAA-Discover message received from the PaC after it discard the PANA-PAA-Discover message received from the PaC after it
has sent a PANA-Start-Request message with creating a state (i.e., no has sent a PANA-Start-Request message with creating a state (i.e., no
Cookie AVP is included in the message) for the PaC. In this case the Cookie AVP is included in the message) for the PaC. In this case the
PAA will retransmit the PANA-Start-Request message based on a timer, PAA will retransmit the PANA-Start-Request message based on a timer,
if the PaC doesn't respond in time (the message was lost for if the PaC doesn't respond in time (the message was lost for
example). If the PAA had sent a PANA-Start-Request message without example). If the PAA had sent a PANA-Start-Request message without
creating a state for the PaC (i.e., a Cookie AVP was included in the creating a state for the PaC (i.e., a Cookie AVP was included in the
message), then it SHOULD answer to the PANA-PAA-Discover message. message), then it SHOULD answer to the PANA-PAA-Discover message.
skipping to change at page 15, line 37 skipping to change at page 16, line 20
(continued to the authentication and (continued to the authentication and
authorization phase) authorization phase)
Figure 3: Example sequence for the discovery and handshake phase with Figure 3: Example sequence for the discovery and handshake phase with
traffic-driven PAA discovery traffic-driven PAA discovery
4.3 Authentication and Authorization Phase 4.3 Authentication and Authorization Phase
The main task of the authentication and authorization phase is to The main task of the authentication and authorization phase is to
carry EAP messages between the PaC and the PAA. EAP Request and carry EAP messages between the PaC and the PAA. EAP Request and
Response messages are carried in PANA-Auth-Request messages. Response messages are carried in PANA-Auth-Request messages. PANA-
PANA-Auth-Answer messages are simply used to acknowledge receipt of Auth-Answer messages are simply used to acknowledge receipt of the
the requests. As an optimization, a PANA-Auth-Answer message MAY requests. As an optimization, a PANA-Auth-Answer message MAY include
include the EAP Response message. This optimization MAY not be used the EAP Response message. This optimization MAY not be used when it
when it takes time to generate the EAP Response message (due to, takes time to generate the EAP Response message (due to, e.g.,
e.g., intervention of human input), in which case returning an intervention of human input), in which case returning an EAP-Auth-
EAP-Auth-Answer message without piggybacking an EAP Response message Answer message without piggybacking an EAP Response message can avoid
can avoid unnecessary retransmission of the PANA-Auth-Request unnecessary retransmission of the PANA-Auth-Request message. Another
message. Another optimization allows optionally carrying the first optimization allows optionally carrying the first EAP Request/
EAP Request/Response message in PANA-Start-Request/Answer message as Response message in PANA-Start-Request/Answer message as described in
described in Section 4.2. Section 4.2.
PANA allows execution of two separate authentication methods, one PANA allows execution of two separate authentication methods, one
with NAP and one with ISP under the same PANA session. This optional with NAP and one with ISP under the same PANA session. This optional
feature may be offered by the PAA and accepted by the PaC. When feature may be offered by the PAA and accepted by the PaC. When
performed separately, the result of the first EAP authentication is performed separately, the result of the first EAP authentication is
signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer
message exchange which delineates the first method execution from the message exchange which delineates the first method execution from the
next. See Section 4.7 for a detailed discussion on separate NAP and next. See Section 4.7 for a detailed discussion on separate NAP and
ISP authentication. ISP authentication.
skipping to change at page 16, line 38 skipping to change at page 17, line 22
-----> PANA-Auth-Request(y) -----> PANA-Auth-Request(y)
[Session-Id, EAP{Response}] [Session-Id, EAP{Response}]
<----- PANA-Auth-Answer(y) <----- PANA-Auth-Answer(y)
[Session-Id] [Session-Id]
<----- PANA-Auth-Request(x+2) <----- PANA-Auth-Request(x+2)
[Session-Id, EAP{Request}] [Session-Id, EAP{Request}]
-----> PANA-Auth-Answer(x+2) // Piggybacking EAP Response -----> PANA-Auth-Answer(x+2) // Piggybacking EAP Response
[Session-Id, EAP{Response}] [Session-Id, EAP{Response}]
<----- PANA-Bind-Request(x+3) <----- PANA-Bind-Request(x+3)
[Session-Id, Result-Code, EAP{Success}, Device-Id, [Session-Id, Result-Code, EAP{Success}, Device-Id,
Key-Id, IP-Address, Lifetime, Protection-Cap., PPAC, MAC] Key-Id, Lifetime, Protection-Cap., PPAC, MAC]
-----> PANA-Bind-Answer(x+3) -----> PANA-Bind-Answer(x+3)
[Session-Id, Device-Id, Key-Id, PPAC, MAC] [Session-Id, Device-Id, Key-Id, PPAC, MAC]
Figure 4: Example sequence for the authentication and authorization Figure 4: Example sequence for the authentication and authorization
phase phase
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 PANA message that carries the EAP Success successfully derived, the PANA message that carries the EAP Success
message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request
message) and any subsequent message MUST contain a MAC AVP. message) and any subsequent message MUST contain a MAC AVP.
The PANA-Bind-Request and the PANA-Bind-Answer message exchange is The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
also used for binding device identifiers of the PaC and EP(s), and also used for binding device identifiers of the PaC and EP(s)to the
the IP address of the PAA to the PANA SA. To achieve this, the PANA SA. To achieve this, the PANA-Bind-Request message MUST contain
PANA-Bind-Request message MUST contain the device identifier in a the device identifier in a Device-Id AVP for each EP if a Protection-
Device-Id AVP for each EP if a Protection-Capability AVP is included Capability AVP is included in the message. Otherwise, the message
in the message. Otherwise, the message SHOULD contain the device SHOULD contain the device identifier in a Device-Id AVP for each EP
identifier in a Device-Id AVP for each EP when a link-layer or IP when a link-layer or IP address is used as the device identifier of
address is used as the device identifier of the PaC. The the PaC. The PANA-Bind-Answer message MUST contain the PaC's device
PANA-Bind-Request message MUST also contain the IP address of the PAA identifier in a Device-Id AVP when it is already presented with that
in an IP-Address AVP. The PANA-Bind-Answer message MUST contain the of EP(s) in the request with using the same type of device identifier
PaC's device identifier in a Device-Id AVP when it is already as contained in the request. If the PANA-Bind-Answer message sent
presented with that of EP(s) in the request with using the same type from the PaC does not contain a Device-Id AVP with the same device
of device identifier as contained in the request. If the identifier type contained in the request, the PAA sends a PANA-Error-
PANA-Bind-Answer message sent from the PaC does not contain a Request message with a PANA_MISSING_AVP result code, and wait for a
Device-Id AVP with the same device identifier type contained in the PANA-Error-Answer message to terminate the session. The PANA-Bind-
request, the PAA sends a PANA-Error-Request message with a Request message with a PANA_SUCCESS result code MUST also contain a
PANA_MISSING_AVP result code, and wait for a PANA-Error-Answer Protection-Capability AVP if link-layer or network-layer ciphering is
message to terminate the session. The PANA-Bind-Request message with enabled after the authentication and authorization phase. The PANA-
a PANA_SUCCESS result code MUST also contain a Protection-Capability Bind-Request message MAY also contain a Protection-Capability AVP to
AVP if link-layer or network-layer ciphering is enabled after the indicate if link-layer or network-layer ciphering should be enabled
authentication and authorization phase. The PANA-Bind-Request after the authentication and authorization phase. No link-layer or
message MAY also contain a Protection-Capability AVP to indicate if network-layer specific information is included in the Protection-
link-layer or network-layer ciphering should be enabled after the Capability AVP. It is assumed that the PAA is aware of the security
authentication and authorization phase. No link-layer or capabilities of the access network. The PANA protocol does not
network-layer specific information is included in the specify how the PANA SA and the Protection-Capability AVP will be
Protection-Capability AVP. It is assumed that the PAA is aware of used to provide per-packet protection for data traffic.
the security capabilities of the access network. The PANA protocol
does not specify how the PANA SA and the Protection-Capability AVP
will be used to provide per-packet protection for data traffic.
Additionally, the PANA-Bind-Request message with a PANA_SUCCESS Additionally, the PANA-Bind-Request message with a PANA_SUCCESS
result code MUST include a Post-PANA-Address-Configuration (PPAC) result code MUST include a Post-PANA-Address-Configuration (PPAC)
AVP, which helps the PAA to inform the PaC about whether a new IP AVP, which helps the PAA to inform the PaC about whether a new IP
address MUST be configured and the available methods to do so. In address MUST be configured and the available methods to do so. In
this case, the PaC MUST include a PPAC AVP in the PANA-Bind-Answer this case, the PaC MUST include a PPAC AVP in the PANA-Bind-Answer
message in order to indicate its choice of method when there is a message in order to indicate its choice of method when there is a
match between the methods offered by the PAA and the methods match between the methods offered by the PAA and the methods
available on the PaC. When there is no match, the PaC MUST send a available on the PaC. When there is no match, the PaC MUST send a
PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED
skipping to change at page 18, line 10 skipping to change at page 18, line 38
sending an EAP Failure message [I-D.ietf-eap-statemachine]. When sending an EAP Failure message [I-D.ietf-eap-statemachine]. When
this occurs, the PAA SHOULD send a PANA-Error-Request message to the this occurs, the PAA SHOULD send a PANA-Error-Request message to the
PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD not PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD not
change its state unless the error message is secured by PANA or change its state unless the error message is secured by PANA or
lower-layer. In any case, a more appropriate way is to rely on a lower-layer. In any case, a more appropriate way is to rely on a
timeout on the PaC. timeout 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 a rejected by the PAA. When this occurs, the PAA MUST send a PANA-
PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If a
a AAA-Key is established between the PaC and the PAA by the time when AAA-Key is established between the PaC and the PAA by the time when
the EAP Success message is generated by the EAP server (this is the the EAP Success message is generated by the EAP server (this is the
case when the EAP method provides protected success indication), the case when the EAP method provides protected success indication), the
PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected
with a MAC AVP and carry a Key-Id AVP. The AAA-Key and the PANA with a MAC AVP and carry a Key-Id AVP. The AAA-Key and the PANA
session MUST be deleted immediately after the PANA-Bind message session MUST be deleted immediately after the PANA-Bind message
exchange. exchange.
4.4 Access Phase 4.4 Access Phase
Once the authentication and authorization phase or the Once the authentication and authorization phase or the re-
re-authentication phase successfully completes, the PaC gains access authentication phase successfully completes, the PaC gains access to
to the network and can send and receive IP data traffic through the 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, EP(s) and the PANA session enters the access phase. In this phase,
PANA-Ping-Request and PANA-Ping-Answer messages can be used for PANA-Ping-Request and PANA-Ping-Answer messages 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 PANA-Ping-Request message to PaC and the PAA are allowed to send a PANA-Ping-Request message to
the communicating peer whenever they need to make sure the the communicating peer whenever they need to make sure the
availability of the session on the peer and expect the peer to return availability of the session on the peer and expect the peer to return
a PANA-Ping-Answer message. Both PANA-Ping-Request and a PANA-Ping-Answer message. Both PANA-Ping-Request and PANA-Ping-
PANA-Ping-Answer messages MUST be protected with a MAC AVP when a Answer messages MUST be protected with a MAC AVP when a PANA SA is
PANA SA is available. available.
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. of timers for this purpose.
Figure 5 and Figure 6 show liveness tests as they are initiated by Figure 5 and Figure 6 show liveness tests as they are initiated by
the PaC and the PAA respectively. the PaC and the PAA respectively.
PaC PAA Message(sequence number)[AVPs] PaC PAA Message(sequence number)[AVPs]
skipping to change at page 19, line 26 skipping to change at page 19, line 44
Figure 6: Example sequence for PAA-initiated liveness test Figure 6: Example sequence for PAA-initiated liveness test
4.5 Re-authentication Phase 4.5 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 deleted. re-enters the access phase. Otherwise, the session is deleted.
When the PaC wants to initiate re-authentication, it sends a When the PaC wants to initiate re-authentication, it sends a PANA-
PANA-Reauth-Request message to the PAA. This message MUST contain a Reauth-Request message to the PAA. This message MUST contain a
Session-Id AVP which is used for identifying the PANA session on the Session-Id AVP which is used for identifying the PANA session on the
PAA. If the PAA already has an established PANA session for the PaC PAA. If the PAA already has an established PANA session for the PaC
with the matching session identifier, it MUST first respond with a with the matching session identifier, it MUST first respond with a
PANA-Reauth-Answer message, followed by a PANA-Auth-Request that PANA-Reauth-Answer message, followed by a PANA-Auth-Request that
starts a new EAP authentication. If the PAA cannot identify the starts a new EAP authentication. If the PAA cannot identify the
session, it MAY respond with a PANA-Error-Request message with a session, it MAY respond with a PANA-Error-Request message with a
result code PANA_UNKNOWN_SESSION_ID. Transmission of this error result code PANA_UNKNOWN_SESSION_ID. Transmission of this error
request is made optional in case this behavior is leveraged for a DoS request is made optional in case this behavior is leveraged for a DoS
attack on the PAA. attack on the PAA.
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 PANA-Reauth-Request. This condition can arise due to its outstanding PANA-Reauth-Request. This condition can arise due
to packet re-ordering or a race condition between the PaC and PAA 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 when they both attempt to engage in re-authentication. The PaC MUST
keep discarding the received PANA-Auth-Requests until it receives the keep discarding the received PANA-Auth-Requests until it receives the
answer to its request. answer to its request.
When the PAA initiates re-authentication, it sends a When the PAA initiates re-authentication, it sends a PANA-Auth-
PANA-Auth-Request message containing the session identifier for the Request message containing the session identifier for the PaC to
PaC to enter the re-authentication phase. The PAA SHOULD initiate enter the re-authentication phase. The PAA SHOULD initiate EAP re-
EAP re-authentication before the current session lifetime expires. authentication before the current session lifetime expires.
Re-authentication of an on-going PANA session MUST maintain the Re-authentication of an on-going PANA session MUST maintain the
existing sequence numbers. existing sequence numbers.
For any re-authentication, if there is an established PANA SA, For any re-authentication, if there is an established PANA SA, PANA-
PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by Auth-Request and PANA-Auth-Answer messages MUST be protected by
adding a MAC AVP to each message. Any subsequent EAP authentication adding a MAC AVP to each message. Any subsequent EAP authentication
MUST be performed with the same ISP and NAP that was selected during MUST be performed with the same ISP and NAP that was selected during
the discovery and handshake phase. An example sequence for the discovery and handshake phase. An example sequence for re-
re-authentication phase initiated by the PaC is shown in Figure 7. authentication phase initiated by the PaC is shown in Figure 7.
PaC PAA Message(sequence number)[AVPs] PaC PAA Message(sequence number)[AVPs]
------------------------------------------------------ ------------------------------------------------------
-----> PANA-Reauth-Request(q) -----> PANA-Reauth-Request(q)
[Session-Id, MAC] [Session-Id, MAC]
<----- PANA-Reauth-Answer(q) <----- PANA-Reauth-Answer(q)
[Session-Id, MAC] [Session-Id, MAC]
<----- PANA-Auth-Request(p) <----- PANA-Auth-Request(p)
[Session-Id, EAP{Request}, MAC] [Session-Id, EAP{Request}, MAC]
-----> PANA-Auth-Answer(p) // No piggybacking EAP Response -----> PANA-Auth-Answer(p) // No piggybacking EAP Response
skipping to change at page 20, line 35 skipping to change at page 21, line 25
-----> PANA-Auth-Request(q+1) -----> PANA-Auth-Request(q+1)
[Session-Id, EAP{Response}, MAC] [Session-Id, EAP{Response}, MAC]
<----- PANA-Auth-Answer(q+1) // No piggybacking EAP Response <----- PANA-Auth-Answer(q+1) // No piggybacking EAP Response
[Session-Id, MAC] [Session-Id, MAC]
<----- PANA-Auth-Request(p+1) <----- PANA-Auth-Request(p+1)
[Session-Id, EAP{Request}, MAC] [Session-Id, EAP{Request}, MAC]
-----> PANA-Auth-Answer(p+1) // Piggybacking EAP Response -----> PANA-Auth-Answer(p+1) // Piggybacking EAP Response
[Session-Id, EAP{Response}, MAC] [Session-Id, EAP{Response}, MAC]
<----- PANA-Bind-Request(p+2) <----- PANA-Bind-Request(p+2)
[Session-Id, Result-Code, EAP{Success}, Device-Id, Key-Id, [Session-Id, Result-Code, EAP{Success}, Device-Id, Key-Id,
IP-Address, Lifetime, Protection-Cap., PPAC, MAC] Lifetime, Protection-Cap., PPAC, MAC]
-----> PANA-Bind-Answer(p+2) -----> PANA-Bind-Answer(p+2)
[Session-Id, Device-Id, Key-Id, PPAC, MAC] [Session-Id, Device-Id, Key-Id, PPAC, MAC]
Figure 7: Example sequence for the re-authentication phase initiated Figure 7: Example sequence for the re-authentication phase initiated
by PaC by PaC
4.6 Termination Phase 4.6 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
skipping to change at page 21, line 47 skipping to change at page 22, line 43
of each authentication is a network policy issue. of each authentication is a network policy issue.
4.7.1 Negotiating Separate NAP and ISP Authentication 4.7.1 Negotiating Separate NAP and ISP Authentication
When the PaC and PAA negotiates in the discovery and handshake phase When the PaC and PAA negotiates in the discovery and handshake phase
to perform separate NAP and ISP authentication, the PaC and the PAA to perform separate NAP and ISP authentication, the PaC and the PAA
operate in the following way in addition to the behavior defined in operate in the following way in addition to the behavior defined in
Section 4.2 Section 4.2
In the discovery and handshake phase, the PAA MAY advertise In the discovery and handshake phase, the PAA MAY advertise
availability of separate NAP and ISP authentication availability of separate NAP and ISP authentication ([I-D.ietf-pana-
([I-D.ietf-pana-framework]) by setting the S-flag on the PANA header framework]) by setting the S-flag on the PANA header of the PANA-
of the PANA-Start-Request message. Start-Request message.
If the S-flag of the received PANA-Start-Request message is set, the If the S-flag of the received PANA-Start-Request message is set, the
PaC can indicate its desire to perform separate NAP and ISP PaC can indicate its desire to perform separate NAP and ISP
authentication by setting the S-flag in the PANA-Start-Answer authentication by setting the S-flag in the PANA-Start-Answer
message. If the S-flag of the received PANA-Start-Request message is message. If the S-flag of the received PANA-Start-Request message is
not set, the PaC MUST NOT set the S-flag in the PANA-Start-Answer not set, the PaC MUST NOT set the S-flag in the PANA-Start-Answer
message sent back to the PAA. message sent back to the PAA.
If the S-flag in the PANA-Start-Answer message is not set, only one If the S-flag in the PANA-Start-Answer message is not set, only one
authentication is performed (ISP-only) and the processing occurs as authentication is performed (ISP-only) and the processing occurs as
skipping to change at page 22, line 33 skipping to change at page 23, line 28
4.7.2 Execution of Separate NAP and ISP Authentication 4.7.2 Execution of Separate NAP and ISP Authentication
When the PaC and PAA have negotiated in the discovery and handshake When the PaC and PAA have negotiated in the discovery and handshake
phase to perform separate NAP and ISP authentication, the PaC and the phase to perform separate NAP and ISP authentication, the PaC and the
PAA operate in the following way in addition to the behavior defined PAA operate in the following way in addition to the behavior defined
in Section 4.3 in Section 4.3
o The S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST o The S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST
be set. be set.
o An EAP Success/Failure message is carried in a o An EAP Success/Failure message is carried in a PANA-FirstAuth-End-
PANA-FirstAuth-End-Request (PFER) message as well as a Request (PFER) message as well as a PANA-Bind-Request (PBR)
PANA-Bind-Request (PBR) message. The PANA-FirstAuth-End-Request message. The PANA-FirstAuth-End-Request message MUST be used at
message MUST be used at the end of the first EAP authentication the end of the first EAP authentication and the PANA-Bind-Request
and the PANA-Bind-Request MUST be used for the second EAP MUST be used for the second EAP authentication. The PANA-
authentication. The PANA-FirstAuth-End-Request messages MUST be FirstAuth-End-Request messages MUST be acknowledged with a PANA-
acknowledged with a PANA-FirstAuth-End-Answer (PFEA) message. FirstAuth-End-Answer (PFEA) message.
o If the first EAP authentication has failed, the PAA can choose not o If the first EAP authentication has failed, the PAA can choose not
to perform the second EAP authentication by clearing the S-flag of to perform the second EAP authentication by clearing the S-flag of
the PANA-FirstAuth-End-Request message. In this case, the S-flag the PANA-FirstAuth-End-Request message. In this case, the S-flag
of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be
cleared. If the S-flag of the PANA-FirstAuth-End-Request message cleared. If the S-flag of the PANA-FirstAuth-End-Request message
is set when the first EAP authentication has failed, the PaC can is set when the first EAP authentication has failed, the PaC can
choose not to perform the second EAP authentication by clearing choose not to perform the second EAP authentication by clearing
the S-flag of the PANA-FirstAuth-End-Answer message. If the first the S-flag of the PANA-FirstAuth-End-Answer message. If the first
EAP authentication failed and the S-flag is not set in the EAP authentication failed and the S-flag is not set in the PANA-
PANA-FirstAuth-End-Answer message as a result of those operations, FirstAuth-End-Answer message as a result of those operations, the
the PANA session MUST be immediately deleted. Otherwise, the PANA session MUST be immediately deleted. Otherwise, the second
second EAP authentication MUST be performed. EAP authentication MUST be performed.
o The PAA determines the execution order of NAP authentication and o The PAA determines the execution order of NAP authentication and
ISP authentication. In this case, the PAA can indicate which ISP authentication. In this case, the PAA can indicate which
authentication (NAP authentication or ISP authentication) is authentication (NAP authentication or ISP authentication) is
currently occurring by using N-flag in the PANA message header. currently occurring by using N-flag in the PANA message header.
When NAP authentication is being performed, the N-flag MUST be When NAP authentication is being performed, the N-flag MUST be
set. When ISP authentication is being performed, the N-flag MUST set. When ISP authentication is being performed, the N-flag MUST
NOT be set. The N-flag MUST NOT be set when S-flag is not set. NOT be set. The N-flag MUST NOT be set when S-flag is not set.
When the PaC and PAA have negotiated in the discovery and handshake When the PaC and PAA have negotiated in the discovery and handshake
phase to perform separate NAP and ISP authentication, and the phase to perform separate NAP and ISP authentication, and the lower-
lower-layer is insecure, the two EAP authentication methods used in layer is insecure, the two EAP authentication methods used in the
the separate authentication MUST be capable of deriving keys separate authentication MUST be capable of deriving keys (AAA-Key).
(AAA-Key).
4.7.3 AAA-Key Calculation 4.7.3 AAA-Key Calculation
When the PaC and PAA have negotiated in the discovery and handshake When the PaC and PAA have negotiated in the discovery and handshake
phase to perform separate NAP and ISP authentication, if the phase to perform separate NAP and ISP authentication, if the lower-
lower-layer is insecure, the two EAP authentication methods used in layer is insecure, the two EAP authentication methods used in the
the separate authentication MUST be capable of deriving keys. In separate authentication MUST be capable of deriving keys. In this
this case, if the first EAP authentication is successful, the case, if the first EAP authentication is successful, the PANA-
PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well
well as PANA-Auth-Request and PANA-Auth-Answer messages in the second as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP
EAP authentication MUST be protected with the key derived from the authentication MUST be protected with the key derived from the AAA-
AAA-Key for the first EAP authentication. The PANA-Bind-Request and Key for the first EAP authentication. The PANA-Bind-Request and
PANA-Bind-Answer messages and all subsequent PANA messages exchanged PANA-Bind-Answer messages and all subsequent PANA messages exchanged
in the access phase, re-authentication phase and termination phase in the access phase, re-authentication phase and termination phase
MUST be protected either with the AAA-Key for the first EAP MUST be protected either with the AAA-Key for the first EAP
authentication if the first EAP authentication succeeds and the authentication if the first EAP authentication succeeds and the
second EAP authentication fails, or with the AAA-Key for the second second EAP authentication fails, or with the AAA-Key for the second
EAP authentication if the first EAP authentication fails and the EAP authentication if the first EAP authentication fails and the
second EAP authentication succeeds, or with the compound AAA-Key second EAP authentication succeeds, or with the compound AAA-Key
derived from the two AAA-Keys, one for the first EAP authentication derived from the two AAA-Keys, one for the first EAP authentication
and the other from the second EAP authentication, if both the first and the other from the second EAP authentication, if both the first
and second EAP authentication succeed. See Section 5.3 for how to and second EAP authentication succeed. See Section 5.3 for how to
skipping to change at page 24, line 35 skipping to change at page 25, line 35
The PaC and PAA maintain two sequence numbers: the next one to be The PaC and PAA maintain two sequence numbers: the next one to be
used for a request it initiates and the next one it expects to see in used for a request it initiates and the next one it expects to see in
a request from the other end. These sequence numbers are 32-bit a request from the other end. These sequence numbers are 32-bit
unsigned numbers. They are monotonically incremented by 1 as new unsigned numbers. They are monotonically incremented by 1 as new
requests are generated and received, and wrapped to zero on the next requests are generated and received, and wrapped to zero on the next
message after 2^32-1. Answers always contain the same sequence message after 2^32-1. Answers always contain the same sequence
number as the corresponding request. Retransmissions reuse the number as the corresponding request. Retransmissions reuse the
sequence number contained in the original packet. sequence number contained in the original packet.
The initial sequence numbers (ISN) are randomly picked by the PaC and The initial sequence numbers (ISN) are randomly picked by the PaC and
PAA as they send their very first request messages. PAA as they send their very first request messages. PANA-PAA-
PANA-PAA-Discover message carries sequence number 0. Discover message carries sequence number 0.
When a request message is received, it is considered valid in terms When a request message is received, it is considered valid in terms
of sequence numbers if and only if its sequence number matches the of sequence numbers if and only if its sequence number matches the
expected value. This check does not apply to the PANA-PAA-Discover, expected value. This check does not apply to the PANA-PAA-Discover,
PANA-Start-Request messages. PANA-Start-Request messages.
When an answer message is received, it is considered valid in terms 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 sequence numbers if and only if its sequence number matches that
of the currently outstanding request. A peer can only have one of the currently outstanding request. A peer can only have one
outstanding request at a time. outstanding request at a time.
skipping to change at page 25, line 10 skipping to change at page 26, line 10
PANA messages are retransmitted based on a timer until a response is PANA messages are retransmitted based on a timer until a response is
received (in which case the retransmission timer is stopped) or the received (in which case the retransmission timer is stopped) or the
number of retransmission reaches the maximum value (in which case the number of retransmission reaches the maximum value (in which case the
PANA session MUST be deleted immediately). PANA session MUST be deleted immediately).
The initial discovery and handshake phase requires special handling. The initial discovery and handshake phase requires special handling.
The PaC MUST retransmit the PANA-PAA-Discover message if a subsequent The PaC MUST retransmit the PANA-PAA-Discover message if a subsequent
PANA-Start-Request message is not received in time. Even though a PANA-Start-Request message is not received in time. Even though a
PANA-Start-Request message is received, the PANA-PAA-Discover message PANA-Start-Request message is received, the PANA-PAA-Discover message
may still have to be retransmitted. This is because stateless PAA may still have to be retransmitted. This is because stateless PAA
discovery requires one time transmission of a solicited discovery requires one time transmission of a solicited PANA-Start-
PANA-Start-Request message. The PAA MUST NOT start a timer and Request message. The PAA MUST NOT start a timer and retransmit the
retransmit the request in order to avoid state creation. If the request in order to avoid state creation. If the received PANA-
received PANA-Start-Request message included a Cookie AVP (an Start-Request message included a Cookie AVP (an indication of
indication of stateless PAA discovery), the PaC MUST retransmit the stateless PAA discovery), the PaC MUST retransmit the PANA-PAA-
PANA-PAA-Discover message until the first PANA-Auth-Request message Discover message until the first PANA-Auth-Request message is
is received. Otherwise, the PaC can rely on the PAA to retransmit received. Otherwise, the PaC can rely on the PAA to retransmit the
the PANA-Start-Request message as soon as the PaC receives the first PANA-Start-Request message as soon as the PaC receives the first one
one (i.e., the PaC can stop sending the PANA-PAA-Discover message). (i.e., the PaC can stop sending the PANA-PAA-Discover message).
The retransmission timers SHOULD be calculated as described in The retransmission timers SHOULD be calculated as described in
[RFC2988] to provide congestion control. See Section 8 for default [RFC2988] to provide congestion control. See Section 8 for default
timer and maximum retransmission count parameters. timer and maximum retransmission count parameters.
The PaC and PAA MUST respond to duplicate requests. The last The PaC and PAA MUST respond to duplicate requests. The last
transmitted answer MAY be cached in case it is not received by the transmitted answer MAY be cached in case it is not received by the
peer and that generates a retransmission of the last request. When peer and that generates a retransmission of the last request. When
available, the cached answer can be used instead of fully processing available, the cached answer can be used instead of fully processing
the retransmitted request and forming a new answer from scratch. the retransmitted request and forming a new answer from scratch.
skipping to change at page 25, line 45 skipping to change at page 26, line 45
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 a AAA-Key. A PANA SA is authentication succeeds with a creation of a AAA-Key. A PANA SA is
not created when the PANA authentication fails or no AAA-Key is not created when the PANA authentication fails or no AAA-Key is
produced by any EAP authentication method. In the case where two EAP produced by any EAP authentication method. In the case where two EAP
sessions are performed in sequence in the PANA authentication and sessions are performed in sequence in the PANA authentication and
authorization phase, it is possible that two AAA-Keys are derived. authorization phase, it is possible that two AAA-Keys are derived.
If this happens, the PANA SA MUST be generated from both AAA-Keys. If this happens, the PANA SA MUST be generated from both AAA-Keys.
When a new AAA-Key is derived in the PANA re-authentication phase, When a new AAA-Key is derived in the PANA re-authentication phase,
any key derived from the old AAA-Key MUST be updated to a new one any key derived from the old AAA-Key MUST be updated to a new one
that is derived from the new AAA-Key. In order to distinguish the that is derived from the new AAA-Key. In order to distinguish the
new AAA-Key from old ones, one Key-Id AVP MUST be carried in new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-
PANA-Bind-Request and PANA-Bind-Answer messages or Bind-Request and PANA-Bind-Answer messages or PANA-FirstAuth-End-
PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at Request and PANA-FirstAuth-End-Answer messages at the end of the EAP
the end of the EAP authentication which resulted in deriving a new authentication which resulted in deriving a new AAA-Key. The Key-Id
AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a AVP is of type Unsigned32 and MUST contain a value that uniquely
value that uniquely identifies the AAA-Key within the PANA session. identifies the AAA-Key within the PANA session. The PANA-Bind-Answer
The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer message (or the PANA-FirstAuth-End-Answer message) sent in response
message) sent in response to a PANA-Bind-Request message (or a to a PANA-Bind-Request message (or a PANA-FirstAuth-End-Request
PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a message) with a Key-Id AVP MUST contain a Key-Id AVP with the same
Key-Id AVP with the same AAA-Key identifier carried in the request. AAA-Key identifier carried in the request. PANA-Bind-Request, PANA-
PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and Bind-Answer, PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer
PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry messages with a Key-Id AVP MUST also carry a MAC AVP whose value is
a MAC AVP whose value is computed by using the new PANA_MAC_KEY computed by using the new PANA_MAC_KEY derived from the new AAA-Key
derived from the new AAA-Key (or the new pair of AAA-Keys when the (or the new pair of AAA-Keys when the PANA_MAC_KEY is derived from
PANA_MAC_KEY is derived from two AAA-Keys). Although the two AAA-Keys). Although the specification does not mandate a
specification does not mandate a particular method for calculation of particular method for calculation of the Key-Id AVP value, a simple
the Key-Id AVP value, a simple method is to use monotonically method is to use monotonically increasing numbers.
increasing numbers.
The PANA session lifetime is bounded by the lifetime granted by the The PANA session lifetime is bounded by the lifetime granted by the
authentication server (same as the AAA-Key lifetime). The lifetime authentication server (same as the AAA-Key lifetime). The lifetime
of the PANA SA (hence the PANA_MAC_KEY) is the same as the lifetime of the PANA SA (hence the PANA_MAC_KEY) is the same as the lifetime
of the PANA session. The created PANA SA is deleted when the of the PANA session. The created PANA SA is deleted when the
corresponding PANA session is deleted. corresponding PANA session is deleted.
PANA SA attributes as well as PANA session attributes are listed PANA SA attributes as well as PANA session attributes are listed
below: below:
PANA Session attributes: PANA Session attributes:
* Session-Id * Session-Id
* Device-Id of PaC * Device-Id of PaC
* IP address of PaC (may be the same as the Device-Id of PaC when * IP address and UDP port number of the PaC.
IP address is used as the device identifier)
* IP address of PAA * IP address of PAA
* List of device identifiers of EPs * List of device identifiers of EPs
* Sequence number of the last transmitted request * Sequence number of the last transmitted request
* Sequence number of the last received request * Sequence number of the last received request
* Last transmitted message payload * Last transmitted message payload
skipping to change at page 27, line 16 skipping to change at page 28, line 23
+ Nonce generated by PAA (PAA_nonce) + Nonce generated by PAA (PAA_nonce)
+ AAA-Key + AAA-Key
+ AAA-Key Identifier + AAA-Key Identifier
+ PANA_MAC_KEY + PANA_MAC_KEY
The PANA_MAC_KEY is derived from the available AAA-Key(s) and it is The PANA_MAC_KEY is derived from the available AAA-Key(s) and it is
used to integrity protect PANA messages. If there is only one used to integrity protect PANA messages. If there is only one AAA-
AAA-Key available, e.g., due to ISP-only authentication, or with one Key available, e.g., due to ISP-only authentication, or with one
failed and one successful separate NAP and ISP authentication (see failed and one successful separate NAP and ISP authentication (see
Section 4.7), the PANA_MAC_KEY computation is based on that single Section 4.7), the PANA_MAC_KEY computation is based on that single
key. Otherwise, two AAA-Keys available to PANA can be combined in key. Otherwise, two AAA-Keys available to PANA can be combined in
following way ('|' indicates concatenation): following way ('|' indicates concatenation):
AAA-Key = AAA-Key1 | AAA-Key2 AAA-Key = AAA-Key1 | AAA-Key2
The PANA_MAC_KEY is computed in the following way: The PANA_MAC_KEY is computed in the following way:
PANA_MAC_KEY = The first N bits of PANA_MAC_KEY = The first N bits of
skipping to change at page 28, line 13 skipping to change at page 29, line 32
MAC AVP is sent. When the PaC does not support the MAC algorithm MAC AVP is sent. When the PaC does not support the MAC algorithm
specified in the PANA-Bind-Request message, it MUST silently discard specified in the PANA-Bind-Request message, it MUST silently discard
the message. The PAA MUST NOT change the MAC algorithm throughout the message. The PAA MUST NOT change the MAC algorithm throughout
the continuation of the PANA session. the continuation of the PANA session.
5.5 Message Validity Check 5.5 Message Validity Check
When a PANA message is received, the message is considered to be When a PANA message is received, the message is considered to be
invalid at least when one of the following conditions are not met: invalid at least when one of the following conditions are not met:
o The IP Hop Limit (or TTL) field has a value of 255, i.e., the
packet could not possibly have been forwarded by a router.
o Each field in the message header contains a valid value including o Each field in the message header contains a valid value including
sequence number, message length, message type, version number, sequence number, message length, message type, version number,
flags, etc. flags, etc.
o The message type is one of the expected types in the current o The message type is one of the expected types in the current
state. Specifically the following messages are unexpected and state. Specifically the following messages are unexpected and
invalid: invalid:
* In the discovery and handshake phase: * In the discovery and handshake phase:
+ PANA-Termination-Request and PANA-Ping-Request. + PANA-Termination-Request and PANA-Ping-Request.
+ PANA-Bind-Request. + PANA-Bind-Request.
+ PANA-Update-Request. + PANA-Update-Request.
+ PANA-Reauth-Request. + PANA-Reauth-Request.
+ PANA-Error-Request. + PANA-Error-Request.
* In the authentication and authorization phase and the * In the authentication and authorization phase and the re-
re-authentication phase: authentication phase:
+ PANA-PAA-Discover. + PANA-PAA-Discover.
+ PANA-Update-Request. + PANA-Update-Request.
+ PANA-Start-Request after a PaC receives the first valid + PANA-Start-Request after a PaC receives the first valid
PANA-Auth-Request. PANA-Auth-Request.
+ PANA-Termination-Request before the PaC receives the first + PANA-Termination-Request before the PaC receives the first
successful PANA-Bind-Request. successful PANA-Bind-Request.
* In the access phase: * In the access phase:
+ PANA-Start-Request as well as a non-duplicate + PANA-Start-Request as well as a non-duplicate PANA-Bind-
PANA-Bind-Request. Request.
+ PANA-PAA-Discover. + PANA-PAA-Discover.
* In the termination phase: * In the termination phase:
+ PANA-PAA-Discover. + PANA-PAA-Discover.
+ All requests but PANA-Termination-Request. + All requests but PANA-Termination-Request.
o The message payload contains a valid set of AVPs allowed for the o The message payload contains a valid set of AVPs allowed for the
skipping to change at page 29, line 28 skipping to change at page 31, line 17
in the payload. in the payload.
o Each AVP is decoded correctly. o Each AVP is decoded correctly.
o When a MAC AVP is included, the AVP value matches the MAC value o When a MAC AVP is included, the AVP value matches the MAC value
computed against the received message. computed against the received message.
o When a Device-Id AVP is included, the AVP is valid if the device o When a Device-Id AVP is included, the AVP is valid if the device
identifier type contained in the AVP is supported (check performed identifier type contained in the AVP is supported (check performed
by both the PaC and the PAA) and is the requested one (check by both the PaC and the PAA) and is the requested one (check
performed by the PAA only) and the device identifier value performed by the PAA only). Note that a Device-Id AVP carries the
contained in the AVP matches the value extracted from the device identifier of the PaC in messages from the PaC to the PAA
lower-layer encapsulation header corresponding to the device and the device identifier(s) of the EP(s) in messages from the PAA
identifier type contained in the AVP (check performed by the PAA to the PaC.
only). Note that a Device-Id AVP carries the device identifier of
the PaC in messages from the PaC to the PAA and the device
identifier(s) of the EP(s) in messages from the PAA to the PaC.
o When an IP-Address AVP is received in a message, the AVP is valid
if the IP address matches the source address in the IP header.
Invalid messages MUST be discarded in order to provide robustness Invalid messages MUST be discarded in order to provide robustness
against DoS attacks. In addition, an error notification message MAY against DoS attacks. In addition, an error notification message MAY
be returned to the sender. See Section 5.10 for details. be returned to the sender. See Section 5.10 for details.
5.6 Device ID Choice 5.6 Device ID Choice
The device identifier used in the context of PANA can be an IP The device identifier used in the context of PANA can be an IP
address, a MAC address, or an identifier that is not carried in data address, a MAC address, or an identifier that is not carried in data
packets but has local significance in identifying a connected device packets but has local significance in identifying a connected device
(e.g., circuit id, PPP interface id). The last type of identifiers (e.g., circuit id, PPP interface id). The last type of identifiers
are commonly used in point-to-point links where MAC addresses are not are commonly used in point-to-point links where MAC addresses are not
available and lower-layers are already physically or available and lower-layers are already physically or
cryptographically secured. cryptographically secured.
It is assumed that the PAA knows the link type and the security It is assumed that the PAA knows the link type and the security
mechanisms being provided or required on the access network (e.g., mechanisms being provided or required on the access network (e.g.,
based on physical security, link-layer ciphers enabled before or based on physical security, link-layer ciphers enabled before or
after PANA, or IPsec). Based on that information, the PAA can decide after PANA, or IPsec). Based on that information, the PAA can decide
what type of EP device id will be used when running PANA with the what type of EP device id will be usedused when running PANA with the
client. When IPsec-based security [I-D.ietf-pana-ipsec] is the client.
choice of access control, the PAA SHOULD provide IP address(es) as
EP(s)' device ID, and expect the PaC to provide its IP address in When IPsec-based security [I-D.ietf-pana-ipsec] is the choice of
return. In case IPsec is not used, MAC addresses are used as device access control, the PAA SHOULD provide IP address(es) as EP(s)'
identifiers when available. If non-IPsec access control is enabled, device ID, and expect the PaC to provide its IP address in return.
and a MAC address is not available, device ID exchange does not occur Similarly, IP addresses are used when the EP(s) is not on the same IP
within PANA. Instead, peers rely on lower-layers to provide subnet as the PaC is.
locally-significant identifiers along with received PANA messages.
In other cases, MAC addresses are used as device identifiers when
they are available.
If non-IPsec access control is enabled, and a MAC address is not
available, locally-significant identifiers (e.g., as a circuit id)
MUST be used as device id. Note that these identifiers are not
exchanged within PANA messages. Instead, peers rely on lower-layers
to provide them along with received PANA messages.
5.7 PaC Updating its IP Address 5.7 PaC Updating its IP Address
A PaC's IP address can change in certain situations. For example, A PaC's IP address can change in certain situations. For example,
the PANA framework [I-D.ietf-pana-framework] describes a case in the PANA framework [I-D.ietf-pana-framework] describes a case in
which a PaC replaces a pre-PANA address (PRPA) with a post-PANA which a PaC replaces a pre-PANA address (PRPA) with a post-PANA
address (POPA), and the PaC and PAA create host routes to each other address (POPA). In order to establish reachability, the PAA needs to
in order to maintain on-link communication based on the POPA. The be notified about the change of PaC address.
PAA needs to be notified about the change of PaC address.
After the PaC has changed its address, it MUST send a After the PaC has changed its address, it MUST send a PANA-Update-
PANA-Update-Request message to the PAA. The message MUST carry the Request message to the PAA. The PAA MUST update the PANA session
new PaC address in an IP-Address AVP. If the address contained in with the new PaC address (source IP address) and return a PANA-
the request is invalid, the PAA MUST send a PANA-Error message with a Update-Answer message. If there is an established PANA SA, both
result code PANA_INVALID_IP_ADDRESS. Otherwise, the PAA MUST update
the PANA session with the new PaC address and return a
PANA-Update-Answer message. If there is an established PANA SA, both
PANA-Update-Request and PANA-Update-Answer messages MUST be protected PANA-Update-Request and PANA-Update-Answer messages MUST be protected
with a MAC AVP. with a MAC AVP.
5.8 Session Lifetime 5.8 Session Lifetime
The authentication and authorization phase determines the PANA The authentication and authorization phase determines the PANA
session lifetime when the network access authorization succeeds. The session lifetime when the network access authorization succeeds. The
Session-Lifetime AVP MAY be optionally included in the Session-Lifetime AVP MAY be optionally included in the PANA-Bind-
PANA-Bind-Request message to inform the PaC about the valid lifetime Request message to inform the PaC about the valid lifetime of the
of the PANA session. It MUST be ignored when included in other PANA PANA session. It MUST be ignored when included in other PANA
messages. 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 does not have to perform PaC to manage PANA-related state. The PaC does not have to perform
any actions when the lifetime expires, other than optionally purging any actions when the lifetime expires, other than optionally purging
local state. The PAA SHOULD initiate the PANA re-authentication local state. The PAA SHOULD initiate the PANA re-authentication
phase before the current session lifetime expires. phase before the current session lifetime expires.
The PaC and PAA MAY optionally rely on lower-layer indications to The PaC and PAA MAY optionally rely on lower-layer indications to
expedite the detection of a disconnected peer. Availability and expedite the detection of a disconnected peer. Availability and
skipping to change at page 31, line 37 skipping to change at page 33, line 26
identity of the NAP and a list of ISPs that are available through the identity of the NAP and a list of ISPs that are available through the
NAP. The PaC can not only learn the ISPs but also convey the NAP. The PaC can not only learn the ISPs but also convey the
selected ISP explicitly during the handshake phase. The PAA is selected ISP explicitly during the handshake phase. The PAA is
assumed to be pre-configured with the information of ISPs that are assumed to be pre-configured with the information of ISPs that are
served by the NAP. served by the NAP.
A PANA-Start-Request message sent from the PAA MAY contain zero or A PANA-Start-Request message sent from the PAA MAY contain zero or
one NAP-Information AVP, and zero or more ISP-Information AVPs. The one NAP-Information AVP, and zero or more ISP-Information AVPs. The
PaC MAY indicate its choice of ISP by including an ISP-Information PaC MAY indicate its choice of ISP by including an ISP-Information
AVP in the PANA-Start-Answer message. The PaC MAY convey its ISP AVP in the PANA-Start-Answer message. The PaC MAY convey its ISP
even when there is no ISP-Information AVP contained in the even when there is no ISP-Information AVP contained in the PANA-
PANA-Start-Request message. The PaC can do that when it is Start-Request message. The PaC can do that when it is pre-configured
pre-configured with ISP information. with ISP information.
In the absence of an ISP explicitly selected and conveyed by the PaC, In the absence of an ISP explicitly selected and conveyed by the PaC,
ISP selection is typically performed based on the client identifier ISP selection is typically performed based on the client identifier
(e.g., using the realm portion of an NAI carried in EAP method). A (e.g., using the realm portion of an NAI carried in EAP method). A
backend AAA protocol (e.g., RADIUS) will run between the AAA client backend AAA protocol (e.g., RADIUS) will run between the AAA client
on the PAA and a AAA server in the selected ISP domain. on the PAA and a AAA server in the selected ISP domain.
The PANA-based ISP selection mechanism dictates the next-hop AAA The PANA-based ISP selection mechanism dictates the next-hop AAA
proxy on the PAA. If the NAP requires all AAA traffic to go through proxy on the PAA. If the NAP requires all AAA traffic to go through
its local AAA proxy, it may have to rely on a mechanism to relay the its local AAA proxy, it may have to rely on a mechanism to relay the
selected ISP information from PAA (AAA client) to the local AAA selected ISP information from PAA (AAA client) to the local AAA
proxy. The local AAA proxy can forward the AAA traffic to the proxy. The local AAA proxy can forward the AAA traffic to the
selected ISP domain upon processing. Further details, including how selected ISP domain upon processing. Further details, including how
the AAA client relays AAA routing information to the AAA proxy, are the AAA client relays AAA routing information to the AAA proxy, are
outside the scope of PANA. outside the scope of PANA.
An alternative ISP discovery mechanism is outlined in An alternative ISP discovery mechanism is outlined in [I-D.adrangi-
[I-D.adrangi-eap-network-discovery] which suggests advertising ISP eap-network-discovery] which suggests advertising ISP information in-
information in-band with the ongoing EAP method execution. band with the ongoing EAP method execution. Deployments using the
Deployments using the PANA's built-in ISP discovery mechanism need PANA's built-in ISP discovery mechanism need not use the other
not use the other mechanism. mechanism.
5.10 Error Handling 5.10 Error Handling
A PANA-Error-Request message MAY be sent by either the PaC or the PAA A PANA-Error-Request message MAY be sent by either the PaC or the PAA
when a badly formed PANA message is received or in case of other when a badly formed PANA message is received or in case of other
errors. The receiver of this request MUST respond with a errors. The receiver of this request MUST respond with a PANA-Error-
PANA-Error-Answer message. If the cause of this error message was a Answer message. If the cause of this error message was a request
request message (e.g., PANA-PAA-Discover or *-Request), then the message (e.g., PANA-PAA-Discover or *-Request), then the request MAY
request MAY be retransmitted immediately without waiting for its be retransmitted immediately without waiting for its retransmission
retransmission timer to go off. If the cause of the error was a timer to go off. If the cause of the error was a response message,
response message, the receiver of the PANA-Error-Request message the receiver of the PANA-Error-Request message SHOULD NOT resend the
SHOULD NOT resend the same response until it receives the next same response until it receives the next request.
request.
Erroneous PANA messages may be exploited by adversaries to launch DoS Erroneous PANA messages may be exploited by adversaries to launch DoS
attacks on the victims. Unless the PaC or PAA rate-limits the attacks on the victims. Unless the PaC or PAA rate-limits the
generated PANA-Error-Request messages it may be overburdened by generated PANA-Error-Request messages it may be overburdened by
having to respond to bogus messages. Limiting the number of error having to respond to bogus messages. Limiting the number of error
notifications sent to a given peer during a (configurable) period of notifications sent to a given peer during a (configurable) period of
time may be useful. time may be useful.
When an error message is sent unprotected (i.e., no MAC AVP) and the When an error message is sent unprotected (i.e., no MAC AVP) and the
lower-layer is insecure, the error message is treated as an lower-layer is insecure, the error message is treated as an
informational message. The receiver of such an error message MUST informational message. The receiver of such an error message MUST
NOT change its state unless the error persists and the PANA session NOT change its state unless the error persists and the PANA session
is not making any progress. is not making any progress.
6. PANA Headers and Formats 6. PANA Headers and Formats
This section defines message formats for PANA protocol. This section defines message formats for PANA protocol.
6.1 IP and UDP Headers 6.1 IP and UDP Headers
The Hop Limit (or TTL) field of the IP header MUST be set to 255.
When a PANA-PAA-Discover message is multicast, IP destination address When a PANA-PAA-Discover message is multicast, IP destination address
of the message is set to a well-known link-local multicast address of the message is set to a well-known administratively scoped
(TBD). A PANA-PAA-Discover message MAY be unicast in some cases as multicast address (TBD). A PANA-PAA-Discover message MAY be unicast
specified in Section 4.2. Any other PANA packet is unicast between in some cases as specified in Section 4.2. Any other PANA message is
the PaC and the PAA. The source and destination addresses SHOULD be unicast between the PaC and the PAA. The source and destination
set to the addresses on the interfaces from which the message will be addresses SHOULD be set to the addresses on the interfaces from which
sent and received, respectively. the message will be sent and received, respectively.
When the PANA packet is sent in response to a request, the UDP source When the PANA message is sent in response to a request, the UDP
and destination ports of the response packet MUST be copied from the source and destination ports of the response message MUST be copied
destination and source ports of the request packet, respectively. from the destination and source ports of the request message,
The destination port of an unsolicited PANA packet MUST be set to an respectively.
assigned value (TBD), and the source port MUST be set to a value
chosen by the sender.
The maximum PANA packet size is limited by the maximum UDP payload. The source port of an unsolicited PANA message MUST be set to a value
chosen by the sender. The destination port MUST be set to the peer's
port number if it has already been discovered via earlier PANA
exchanges, set to the assigned PANA port (TBD) otherwise.
When the PANA message is sent in response to a request, the UDP
source and destination ports of the response message MUST be copied
from the destination and source ports of the request message,
respectively.
The source port of an unsolicited PANA message MUST be set to a value
chosen by the sender. The destination port MUST be set to the peer's
port number if it has already been discovered via earlier PANA
exchanges, set to the assigned PANA port (TBD) otherwise.
The maximum PANA message size is limited by the maximum UDP payload.
6.2 PANA Header 6.2 PANA Header
A summary of the PANA header format is shown below. The fields are A summary of the PANA header format is shown below. The fields are
transmitted in network byte order. transmitted in network byte order.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Length | | Version | Reserved | Message Length |
skipping to change at page 35, line 4 skipping to change at page 37, line 25
separate NAP and ISP authentication. The PaC may also respond separate NAP and ISP authentication. The PaC may also respond
with the S-flag not set which implies the PaC has chosen to with the S-flag not set which implies the PaC has chosen to
authenticate with the ISP only. When the S-flag is set in a authenticate with the ISP only. When the S-flag is set in a
PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and
PANA-Bind-Request/Answer messages it indicates that separate PANA-Bind-Request/Answer messages it indicates that separate
NAP and ISP authentication is being performed in the NAP and ISP authentication is being performed in the
authentication and authorization phase. For other cases, authentication and authorization phase. For other cases,
S-flag MUST NOT be set. S-flag MUST NOT be set.
N(AP authentication) N(AP authentication)
When the N-flag is set in a PANA-Auth-Request message, it When the N-flag is set in a PANA-Auth-Request message, it
indicates that the current EAP authentication is for NAP indicates that the current EAP authentication is for NAP
authentication. When the N-flag is unset in a authentication. When the N-flag is unset in a PANA-Auth-
PANA-Auth-Request message, it indicates that the current EAP Request message, it indicates that the current EAP
authentication is for ISP authentication. The PaC MUST copy authentication is for ISP authentication. The PaC MUST copy
the value of the flag in its requests from the last received the value of the flag in its requests from the last received
request of the PAA. The value of the flag on an answer MUST be request of the PAA. The value of the flag on an answer MUST be
copied from the request. The N-flag MUST NOT be set when copied from the request. The N-flag MUST NOT be set when
S-flag is not set. S-flag is not set.
r(eserved) r(eserved)
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.
skipping to change at page 35, line 39 skipping to change at page 38, line 25
AVPs AVPs
AVPs are a method of encapsulating information relevant to the AVPs are a method of encapsulating information relevant to the
PANA message. See section Section 6.3 for more information on PANA message. See section Section 6.3 for more information on
AVPs. AVPs.
6.3 AVP Header 6.3 AVP Header
Each AVP of type OctetString MUST be padded to align on a 32-bit Each AVP of type OctetString MUST be padded to align on a 32-bit
boundary, while other AVP types align naturally. A number of boundary, while other AVP types align naturally. A number of zero-
zero-valued bytes are added to the end of the AVP Data field till a valued bytes are added to the end of the AVP Data field till a word
word boundary is reached. The length of the padding is not reflected boundary is reached. The length of the padding is not reflected in
in the AVP Length field [RFC3588]. the AVP Length field [RFC3588].
The fields in the AVP header are sent in network byte order. The The fields in the AVP header are sent in network byte order. The
format of the header is: format of the header is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Flags | | AVP Code | AVP Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved | | AVP Length | Reserved |
skipping to change at page 36, line 33 skipping to change at page 39, line 26
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M(andatory) M(andatory)
The 'M' Bit, known as the Mandatory bit, indicates whether The 'M' Bit, known as the Mandatory bit, indicates whether
support of the AVP is required. support of the AVP is required.
If an AVP with the 'M' bit set is received by the PaC or PAA If an AVP with the 'M' bit set is received by the PaC or PAA
and either the AVP or its value is unrecognized, the message and either the AVP or its value is unrecognized, the message
MUST be rejected and the receiver MUST send a MUST be rejected and the receiver MUST send a PANA-Error-
PANA-Error-Request message. If the AVP was unrecognized the Request message. If the AVP was unrecognized the PANA-Error-
PANA-Error-Request message result code MUST be Request message result code MUST be PANA_AVP_UNSUPPORTED. If
PANA_AVP_UNSUPPORTED. If the AVP value was unrecognized the the AVP value was unrecognized the PANA-Error-Request message
PANA-Error-Request message result code MUST be result code MUST be PANA_INVALID_AVP_DATA. In either case the
PANA_INVALID_AVP_DATA. In either case the PANA-Error-Request PANA-Error-Request message MUST carry a Failed-AVP AVP
message MUST carry a Failed-AVP AVP containing the offending containing the offending mandatory AVP.
mandatory AVP.
AVPs with the 'M' bit cleared are informational only and a AVPs with the 'M' bit cleared are informational only and a
receiver that receives a message with such an AVP that is not receiver that receives a message with such an AVP that is not
supported, or whose value is not supported, MAY simply ignore supported, or whose value is not supported, MAY simply ignore
the AVP. the AVP.
V(endor) V(endor)
The 'V' bit, known as the Vendor-Specific bit, indicates The 'V' bit, known as the Vendor-Specific bit, indicates
whether the optional Vendor-Id field is present in the AVP whether the optional Vendor-Id field is present in the AVP
header. When set the AVP Code belongs to the specific vendor header. When set the AVP Code belongs to the specific vendor
code address space. code address space.
r(eserved) r(eserved)
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.
Unless otherwise noted, AVPs defined in this document will have Unless otherwise noted, AVPs defined in this document will have
the following default AVP Flags field settings: The 'M' bit MUST the following default AVP Flags field settings: The 'M' bit MUST
be set. The 'V' bit MUST NOT be set. be set. The 'V' bit MUST NOT be set.
AVP Length AVP Length
The AVP Length field is four octets, and indicates the number of The AVP Length field is four octets, and indicates the number of
octets in this AVP including the AVP Code, AVP Length, AVP Flags, octets in this AVP including the AVP Code, AVP Length, AVP Flags,
and the AVP data. and the AVP data.
skipping to change at page 42, line 8 skipping to change at page 46, line 8
PANA-Auth-Request ::= < PANA-Header: 3, REQ [, SEP] [, NAP] > PANA-Auth-Request ::= < PANA-Header: 3, REQ [, SEP] [, NAP] >
< Session-Id > < Session-Id >
< EAP-Payload > < EAP-Payload >
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.5 PANA-Auth-Answer (PAN) 7.2.5 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. It MAY carry an PAA in response to a PANA-Auth-Request message. It MAY carry an EAP-
EAP-Payload AVP. Payload AVP.
PANA-Auth-Answer ::= < PANA-Header: 3 [, SEP] [, NAP] > PANA-Auth-Answer ::= < PANA-Header: 3 [, SEP] [, NAP] >
< Session-Id > < Session-Id >
[ EAP-Payload ] [ EAP-Payload ]
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.6 PANA-Reauth-Request (PRAR) 7.2.6 PANA-Reauth-Request (PRAR)
skipping to change at page 42, line 49 skipping to change at page 47, line 9
7.2.8 PANA-Bind-Request (PBR) 7.2.8 PANA-Bind-Request (PBR)
The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to
deliver the result of PANA authentication. deliver the result of PANA authentication.
PANA-Bind-Request ::= < PANA-Header: 5, REQ [, SEP] [, NAP] > PANA-Bind-Request ::= < PANA-Header: 5, REQ [, SEP] [, NAP] >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ PPAC } { PPAC }
{ IP-Address }
[ EAP-Payload ] [ EAP-Payload ]
[ Session-Lifetime ] [ Session-Lifetime ]
[ Protection-Capability ] [ Protection-Capability ]
[ Key-Id ] [ Key-Id ]
* [ Device-Id ] * [ Device-Id ]
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.9 PANA-Bind-Answer (PBA) 7.2.9 PANA-Bind-Answer (PBA)
skipping to change at page 43, line 40 skipping to change at page 47, line 45
PAA for performing liveness test. PAA for performing liveness test.
PANA-Ping-Request ::= < PANA-Header: 6, REQ > PANA-Ping-Request ::= < PANA-Header: 6, REQ >
< Session-Id > < Session-Id >
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.11 PANA-Ping-Answer (PPA) 7.2.11 PANA-Ping-Answer (PPA)
The PANA-Ping-Answer (PPA) message is sent in response to a The PANA-Ping-Answer (PPA) message is sent in response to a PANA-
PANA-Ping-Request. Ping-Request.
PANA-Ping-Answer ::= < PANA-Header: 6 > PANA-Ping-Answer ::= < PANA-Header: 6 >
< Session-Id > < Session-Id >
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.12 PANA-Termination-Request (PTR) 7.2.12 PANA-Termination-Request (PTR)
The PANA-Termination-Request (PTR) message is sent either by the PaC The PANA-Termination-Request (PTR) message is sent either by the PaC
skipping to change at page 44, line 43 skipping to change at page 49, line 7
PANA-Error-Request ::= < PANA-Header: 8, REQ > PANA-Error-Request ::= < PANA-Header: 8, REQ >
< Session-Id > < Session-Id >
< Result-Code > < Result-Code >
* [ Failed-AVP ] * [ Failed-AVP ]
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.15 PANA-Error-Answer (PEA) 7.2.15 PANA-Error-Answer (PEA)
The PANA-Error-Answer (PEA) message is sent in response to a The PANA-Error-Answer (PEA) message is sent in response to a PANA-
PANA-Error-Request. Error-Request.
PANA-Error-Answer ::= < PANA-Header: 8 > PANA-Error-Answer ::= < PANA-Header: 8 >
< Session-Id > < Session-Id >
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.16 PANA-FirstAuth-End-Request (PFER) 7.2.16 PANA-FirstAuth-End-Request (PFER)
The PANA-FirstAuth-End-Request (PFER) message is sent by the PAA to The PANA-FirstAuth-End-Request (PFER) message is sent by the PAA to
skipping to change at page 45, line 37 skipping to change at page 49, line 47
< Session-Id > < Session-Id >
[ Key-Id ] [ Key-Id ]
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.18 PANA-Update-Request (PUR) 7.2.18 PANA-Update-Request (PUR)
The PANA-Update-Request (PUR) message is sent either by the PaC or The PANA-Update-Request (PUR) message is sent either by the PaC or
the PAA to deliver attribute updates and notifications. In the scope the PAA to deliver attribute updates and notifications. In the scope
of this specification only the PaC IP address attribute can be of this specification only the PaC IP address can be updated via this
updated via this mechanism. An IP-Address AVP can only be included mechanism.
in the PUR messages sent by the PaC. The PUR message can be used to
deliver just a notification as well.
PANA-Update-Request ::= < PANA-Header: 10, REQ > PANA-Update-Request ::= < PANA-Header: 10, REQ >
< Session-Id > < Session-Id >
[ IP-Address ]
[ Notification ] [ Notification ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
7.2.19 PANA-Update-Answer (PUA) 7.2.19 PANA-Update-Answer (PUA)
The PANA-Update-Answer (PUA) message is sent by the PAA to the PaC in The PANA-Update-Answer (PUA) message is sent by the PAA to the PaC in
response to a PANA-Update-Request. response to a PANA-Update-Request.
PANA-Update-Answer ::= < PANA-Header: 10 > PANA-Update-Answer ::= < PANA-Header: 10 >
skipping to change at page 47, line 15 skipping to change at page 51, line 18
+---------------------------------------------+ +---------------------------------------------+
| Message | | Message |
| Type | | Type |
+---+---+---+---+---+----+----+---+---+---+---+ +---+---+---+---+---+----+----+---+---+---+---+
Attribute Name |PDI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA| Attribute Name |PDI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA|
--------------------+---+---+---+---+---+----+----+---+---+---+---+ --------------------+---+---+---+---+---+----+----+---+---+---+---+
Cookie | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Cookie | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 | Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 |
EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 | EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
ISP-Information | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 |
MAC | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| MAC | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1|
NAP-Information | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Nonce | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Nonce | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Notification |0-1|0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1| Notification |0-1|0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1|
PPAC | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1 |0-1| 0 | 0 | PPAC | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1 |0-1| 0 | 0 |
Protection-Cap. | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | Protection-Cap. | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 |
Result-Code | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | Result-Code | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
Session-Id | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | Session-Id | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
skipping to change at page 48, line 14 skipping to change at page 52, line 14
+---------------------------------+ +---------------------------------+
| Message | | Message |
| Type | | Type |
+---+---+---+---+----+----+---+---+ +---+---+---+---+----+----+---+---+
Attribute Name |PTR|PTA|PER|PEA|PFER|PFEA|PUR|PUA| Attribute Name |PTR|PTA|PER|PEA|PFER|PFEA|PUR|PUA|
--------------------+---+---+---+---+----+----+---+---+ --------------------+---+---+---+---+----+----+---+---+
Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
EAP-Payload | 0 | 0 | 0 | 0 |0-1 | 0 | 0 | 0 | EAP-Payload | 0 | 0 | 0 | 0 |0-1 | 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0+| 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0+| 0 | 0 | 0 | 0 | 0 |
IP-Address | 0 | 0 | 0 | 0 | 0 | 0 |0-1| 0 |
ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 |0-1 |0-1 | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 |0-1 |0-1 | 0 | 0 |
MAC |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1| MAC |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|
NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Notification |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1| Notification |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|
PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Result-Code | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | Result-Code | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 |
Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
skipping to change at page 48, line 48 skipping to change at page 52, line 47
not affect interoperability and not specified in this document. An not affect interoperability and not specified in this document. An
example cookie generation algorithm is shown in Section 4.2. example cookie generation algorithm is shown in Section 4.2.
7.3.2 Device-Id AVP 7.3.2 Device-Id AVP
The Device-Id AVP (AVP Code 2) is used for carrying device The Device-Id AVP (AVP Code 2) is used for carrying device
identifiers of PaC and EP(s). The AVP data is of Address type identifiers of PaC and EP(s). The AVP data is of Address type
[RFC3588]. IPv4 and IPv6 addresses are encoded as specified in [RFC3588]. IPv4 and IPv6 addresses are encoded as specified in
[RFC3588]. The content and format of data (including byte and bit [RFC3588]. The content and format of data (including byte and bit
ordering) for link-layer addresses is expected to be specified in ordering) for link-layer addresses is expected to be specified in
specific documents that describe how IP operates over different specific documents that describe how IP operates over different link-
link-layers. For instance, [RFC2464]. Address families other than layers. For instance, [RFC2464]. Address families other than that
that are defined for link-layer or IP addresses MUST NOT be used for are defined for link-layer or IP addresses MUST NOT be used for this
this AVP. AVP.
7.3.3 EAP-Payload AVP 7.3.3 EAP-Payload AVP
The EAP-Payload AVP (AVP Code 3) is used for encapsulating the actual The EAP-Payload AVP (AVP Code 3) is used for encapsulating the actual
EAP message that is being exchanged between the EAP peer and the EAP EAP message that is being exchanged between the EAP peer and the EAP
authenticator. The AVP data is of type OctetString. authenticator. The AVP data is of type OctetString.
7.3.4 Failed-AVP AVP 7.3.4 Failed-AVP AVP
The Failed-AVP AVP (AVP Code 4) provides debugging information in The Failed-AVP AVP (AVP Code 4) provides debugging information in
cases where a request is rejected or not fully processed due to cases where a request is rejected or not fully processed due to
erroneous information in a specific AVP. The AVP data is of type erroneous information in a specific AVP. The AVP data is of type
Grouped. The format of the Failed-AVP AVP is defined in [RFC3588]. Grouped. The format of the Failed-AVP AVP is defined in [RFC3588].
In case of a failed grouped AVP, the Failed-AVP contains the whole
grouped AVP. In case of a failed AVP inside a grouped AVP, the
Failed-AVP contains the single offending AVP.
7.3.5 IP-Address AVP 7.3.5 ISP-Information AVP
The IP-Address AVP (AVP Code 5) contains an IP address of the PaC or
PAA. When it is sent by the PaC, it is used to convey the new IP
address of the PaC to the PAA when the PaC reconfigures its IP
address after the successful PANA authentication. This AVP is not
used if the PaC's IP address used during the authentication and
authorization phase is still valid. It is sent by the PAA in
PANA-Bind-Request to bind the IP address of the PAA to the PANA
session. The payload format of the IP-Address AVP is the same as
that of the Device-Id AVP (see See Section 7.3.2). Address families
for IPv4 or IPv6 MUST be used for this AVP.
7.3.6 ISP-Information AVP
The ISP-Information AVP (AVP Code 6) contains zero or one The ISP-Information AVP (AVP Code 5) contains zero or one Provider-
Provider-Identifier AVP which carries the identifier of the ISP and Identifier AVP which carries the identifier of the ISP and one
one Provider-Name AVP which carries the name of the ISP. The AVP Provider-Name AVP which carries the name of the ISP. The AVP data is
data is of type Grouped, and it has the following ABNF grammar: of type Grouped, and it has the following ABNF grammar:
ISP-Information ::= < AVP Header: 6 > ISP-Information ::= < AVP Header: 5 >
0*1 { Provider-Identifier } 0*1 { Provider-Identifier }
{ Provider-Name } { Provider-Name }
* [ AVP ] * [ AVP ]
7.3.7 Key-Id AVP 7.3.6 Key-Id AVP
The Key-Id AVP (AVP Code 7) is of type Integer32, and contains an The Key-Id AVP (AVP Code 6) is of type Integer32, and contains an
AAA-Key identifier. The AAA-Key identifier is assigned by PAA and AAA-Key identifier. The AAA-Key identifier is assigned by PAA and
MUST be unique within the PANA session. MUST be unique within the PANA session.
7.3.8 MAC AVP 7.3.7 MAC AVP
The MAC (Message Authentication Code) AVP is used to integrity The MAC (Message Authentication Code) AVP is used to integrity
protect PANA messages. The first octet of the this AVP (AVP Code 8) protect PANA messages. The first octet of the this AVP (AVP Code 7)
data contains the MAC algorithm type. Rest of the AVP data payload data contains the MAC algorithm type. Rest of the AVP data payload
contains the MAC encoded in network byte order. The 8-bit Algorithm contains the MAC encoded in network byte order. The 8-bit Algorithm
name space is managed by IANA [ianaweb]. The AVP length varies name space is managed by IANA [ianaweb]. The AVP length varies
depending on the used algorithm. depending on the used algorithm.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | MAC... | Algorithm | MAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm Algorithm
1 HMAC-SHA1 (20 bytes) 1 HMAC-SHA1 (20 bytes)
MAC MAC
The Message Authentication Code is encoded in network byte order. The Message Authentication Code is encoded in network byte order.
skipping to change at page 50, line 28 skipping to change at page 54, line 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm Algorithm
1 HMAC-SHA1 (20 bytes) 1 HMAC-SHA1 (20 bytes)
MAC MAC
The Message Authentication Code is encoded in network byte order. The Message Authentication Code is encoded in network byte order.
7.3.9 NAP-Information AVP 7.3.8 NAP-Information AVP
The NAP-Information AVP (AVP Code 9) contains zero or one The NAP-Information AVP (AVP Code 8) contains zero or one Provider-
Provider-Identifier AVP which carries the identifier of the NAP and Identifier AVP which carries the identifier of the NAP and one
one Provider-Name AVP which carries the name of the NAP. The AVP Provider-Name AVP which carries the name of the NAP. The AVP data is
data is of type Grouped, and it has the following ABNF grammar: of type Grouped, and it has the following ABNF grammar:
NAP-Information ::= < AVP Header: 9 > NAP-Information ::= < AVP Header: 8 >
0*1 { Provider-Identifier } 0*1 { Provider-Identifier }
{ Provider-Name } { Provider-Name }
* [ AVP ] * [ AVP ]
7.3.10 Nonce AVP 7.3.9 Nonce AVP
The Nonce AVP (AVP Code 10) carries a randomly chosen value that is The Nonce AVP (AVP Code 9) carries a randomly chosen value that is
used in cryptographic key computations. The AVP data is of type used in cryptographic key computations. The AVP data is of type
OctetString and it contains a randomly generated value in opaque OctetString and it contains a randomly generated value in opaque
format. The data length MUST be between 8 and 256 bytes inclusive. format. The data length MUST be between 8 and 256 bytes inclusive.
7.3.11 Notification AVP 7.3.10 Notification AVP
The Notification AVP (AVP Code 11) is optionally used to convey a The Notification AVP (AVP Code 10) is optionally used to convey a
displayable message sent by either the PaC or the PAA. It can be displayable message sent by either the PaC or the PAA. It can be
included in any message, whether it is a request or answer. In case included in any message, whether it is a request or answer. In case
a notification needs to be sent but there is no outgoing PANA message a notification needs to be sent but there is no outgoing PANA message
to deliver this AVP, a PANA-Update-Request that only carries a to deliver this AVP, a PANA-Update-Request that only carries a
Notification AVP SHOULD be generated. Notification AVP SHOULD be generated.
Receipt this AVP does not change PANA state. Receipt this AVP does not change PANA state.
AVP data is of type OctetString and it contains UTF-8 encoded ISO AVP data is of type OctetString and it contains UTF-8 encoded ISO
10646 characters [RFC2279]. The length of the displayable message is 10646 characters [RFC2279]. The length of the displayable message is
determined by the AVP Length field. The message MUST NOT be null determined by the AVP Length field. The message MUST NOT be null
terminated. terminated.
7.3.12 Post-PANA-Address-Configuration (PPAC) AVP 7.3.11 Post-PANA-Address-Configuration (PPAC) AVP
The PPAC AVP (AVP Code 12) is used for conveying the available types The PPAC AVP (AVP Code 11) is used for conveying the available types
of post-PANA IP address configuration mechanisms when sent by the of post-PANA IP address configuration mechanisms when sent by the
PAA, and the chosen one when sent by the PaC. Each possible PAA, and the chosen one when sent by the PaC. Each possible
mechanisms is represented by a flag. At least one or more of the mechanisms is represented by a flag. At least one or more of the
flags MUST be set when sent by the PAA, and exactly one flag MUST be flags MUST be set when sent by the PAA, and exactly one flag MUST be
set when sent by the PaC. The AVP data is of type Unsigned32. set when sent by the PaC. The AVP data is of type Unsigned32.
The format of the AVP data is as follows: The format of the AVP data is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 52, line 25 skipping to change at page 56, line 20
Reserved 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.
Unless the N-flag is set, the PaC MUST configure a new IP address Unless the N-flag is set, the PaC MUST configure a new IP address
using one of the methods indicated by the other flags. Refer to using one of the methods indicated by the other flags. Refer to
[I-D.ietf-pana-framework] for a detailed discussion on when these [I-D.ietf-pana-framework] for a detailed discussion on when these
methods can be used. methods can be used.
7.3.13 Protection-Capability AVP 7.3.12 Protection-Capability AVP
The Protection-Capability AVP (AVP Code 13) indicates the The Protection-Capability AVP (AVP Code 12) indicates the
cryptographic data protection capability supported and required by cryptographic data protection capability supported and required by
the EPs. The AVP data is of type Unsigned32. Below is a list of the EPs. The AVP data is of type Unsigned32. Below is a list of
valid data values and associated protection capabilities: valid data values and associated protection capabilities:
0 L2_PROTECTION 0 L2_PROTECTION
1 IPSEC_PROTECTION 1 IPSEC_PROTECTION
7.3.14 Provider-Identifier AVP 7.3.13 Provider-Identifier AVP
The Provider-Identifier AVP (AVP Code 14) is of type Unsigned32, and The Provider-Identifier AVP (AVP Code 13) is of type Unsigned32, and
contains an IANA assigned "SMI Network Management Private Enterprise contains an IANA assigned "SMI Network Management Private Enterprise
Codes" [ianaweb] value, encoded in network byte order. Codes" [ianaweb] value, encoded in network byte order.
7.3.15 Provider-Name AVP 7.3.14 Provider-Name AVP
The Provider-Name AVP (AVP Code 15) is of type UTF8String, and The Provider-Name AVP (AVP Code 14) is of type UTF8String, and
contains the UTF8-encoded name of the provider. contains the UTF8-encoded name of the provider.
7.3.16 Result-Code AVP 7.3.15 Result-Code AVP
The Result-Code AVP (AVP Code 16) is of type Unsigned32 and indicates The Result-Code AVP (AVP Code 15) is of type Unsigned32 and indicates
whether an EAP authentication was completed successfully or whether whether an EAP authentication was completed successfully or whether
an error occurred. Here are Result-Code AVP values taken from an error occurred. Here are Result-Code AVP values taken from
[RFC3588] and adapted for PANA. [RFC3588] and adapted for PANA.
7.3.16.1 Authentication Results Codes 7.3.15.1 Authentication Results Codes
These result code values inform the PaC about the authentication and These result code values inform the PaC about the authentication and
authorization result. The authentication result and authorization authorization result. The authentication result and authorization
result can be different as described below, but only one result is result can be different as described below, but only one result is
returned to the PaC. These codes are used with PANA-Bind-Request and returned to the PaC. These codes are used with PANA-Bind-Request and
PANA-FirstAuth-End-Request messages. PANA-FirstAuth-End-Request messages.
PANA_SUCCESS 2001 PANA_SUCCESS 2001
Both authentication and authorization processes are successful. Both authentication and authorization processes are successful.
skipping to change at page 53, line 28 skipping to change at page 57, line 28
Authentication has failed. When this error is returned, it is Authentication has failed. When this error is returned, it is
assumed that authorization is automatically failed. assumed that authorization is automatically failed.
PANA_AUTHORIZATION_REJECTED 5003 PANA_AUTHORIZATION_REJECTED 5003
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.
7.3.16.2 Protocol Error Result Codes 7.3.15.2 Protocol Error Result Codes
These codes are used with PANA-Error-Request messages. Unless stated These codes are used with PANA-Error-Request messages. Unless stated
otherwise, they can be generated by both the PaC and the PAA. otherwise, they can be generated by both the PaC and the PAA.
PANA_MESSAGE_UNSUPPORTED 3001 PANA_MESSAGE_UNSUPPORTED 3001
Message type not recognized or supported. Message type not recognized or supported.
PANA_UNABLE_TO_DELIVER 3002 PANA_UNABLE_TO_DELIVER 3002
The PAA was unable to deliver the EAP payload to the The PAA was unable to deliver the EAP payload to the
authentication server. Only the PAA can generate this code. authentication server. Only the PAA can generate this code.
PANA_INVALID_HDR_BITS 3008 PANA_INVALID_HDR_BITS 3008
A message was received whose bits in the PANA header were either A message was received whose bits in the PANA header were either
set to an invalid combination, or to a value that is inconsistent set to an invalid combination, or to a value that is inconsistent
with the message type definition. with the message type definition.
PANA_INVALID_AVP_FLAGS 3009 PANA_INVALID_AVP_FLAGS 3009
skipping to change at page 55, line 33 skipping to change at page 60, line 20
PANA_UNABLE_TO_COMPLY 5012 PANA_UNABLE_TO_COMPLY 5012
This error is returned when a request is rejected for unspecified This error is returned when a request is rejected for unspecified
reasons. For example, when an EAP authentication fails at an EAP reasons. For example, when an EAP authentication fails at an EAP
pass-through authenticator without passing an EAP Failure message pass-through authenticator without passing an EAP Failure message
to the PAA, a Result-Code AVP with this error code is carried in to the PAA, a Result-Code AVP with this error code is carried in
the PANA-Error-Request message. the PANA-Error-Request message.
PANA_INVALID_AVP_LENGTH 5014 PANA_INVALID_AVP_LENGTH 5014
The message contained an AVP with an invalid length. The The message contained an AVP with an invalid length. The PANA-
PANA-Error-Request message indicating this error MUST include the Error-Request message indicating this error MUST include the
offending AVPs within a Failed-AVP AVP. offending AVPs within a Failed-AVP AVP.
PANA_INVALID_MESSAGE_LENGTH 5015 PANA_INVALID_MESSAGE_LENGTH 5015
This error is returned when a message is received with an invalid This error is returned when a message is received with an invalid
message length. message length.
PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016
This error is returned when the PaC receives a PANA-Bind-Request This error is returned when the PaC receives a PANA-Bind-Request
skipping to change at page 56, line 4 skipping to change at page 60, line 37
message length. message length.
PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016
This error is returned when the PaC receives a PANA-Bind-Request This error is returned when the PaC receives a PANA-Bind-Request
message with a Protection-Capability AVP and a valid MAC AVP but message with a Protection-Capability AVP and a valid MAC AVP but
does not support the protection capability specified in the does not support the protection capability specified in the
Protection-Capability AVP. Only the PaC can generate this code. Protection-Capability AVP. Only the PaC can generate this code.
PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 PANA_PPAC_CAPABILITY_UNSUPPORTED 5017
This error is returned when there is no match between the list of This error is returned when there is no match between the list of
PPAC methods offered by the PAA and the ones available on the PaC. PPAC methods offered by the PAA and the ones available on the PaC.
Only the PaC can generate this code. Only the PaC can generate this code.
PANA_INVALID_IP_ADDRESS 5018 7.3.16 Session-Id AVP
This error is returned in a PANA-Error-Request message when the
IP-Address AVP in the received PANA-Update-Request message is
invalid (e.g., a non-unicast address). Only the PAA can generate
this code.
7.3.17 Session-Id AVP
All messages pertaining to a specific PANA session MUST include a All messages pertaining to a specific PANA session MUST include a
Session-Id AVP (AVP Code 17) which carries a PAA-assigned fixed Session-Id AVP (AVP Code 16) which carries a PAA-assigned fixed
session identifier value throughout the lifetime of a session. When session identifier value throughout the lifetime of a session. When
present, the Session-Id AVP SHOULD appear immediately following the present, the Session-Id AVP SHOULD appear immediately following the
PANA header. PANA header.
The Session-Id MUST be globally and eternally unique, as it is meant The Session-Id MUST be globally and eternally unique, as it is meant
to identify a PANA session without reference to any other to identify a PANA session without reference to any other
information, and may be needed to correlate historical authentication information, and may be needed to correlate historical authentication
information with accounting information. The PANA Session-Id AVP has information with accounting information. The PANA Session-Id AVP has
the same format as the Diameter Session-Id AVP [RFC3588]. the same format as the Diameter Session-Id AVP [RFC3588].
7.3.18 Session-Lifetime AVP 7.3.17 Session-Lifetime AVP
The Session-Lifetime AVP (AVP Code 18) contains the number of seconds The Session-Lifetime AVP (AVP Code 17) contains the number of seconds
remaining before the current session is considered expired. The AVP remaining before the current session is considered expired. The AVP
data is of type Unsigned32. data is of type Unsigned32.
7.3.19 Termination-Cause AVP 7.3.18 Termination-Cause AVP
The Termination-Cause AVP (AVP Code 19) is used for indicating the The Termination-Cause AVP (AVP Code 18) is used for indicating the
reason why a session is terminated by the requester. The AVP data is reason why a session is terminated by the requester. The AVP data is
of type Enumerated. The following Termination-Cause data values are of type Enumerated. The following Termination-Cause data values are
used with PANA. used with PANA.
LOGOUT 1 (PaC -> PAA) LOGOUT 1 (PaC -> PAA)
The client initiated a disconnect The client initiated a disconnect
ADMINISTRATIVE 4 (PAA -> PaC) ADMINISTRATIVE 4 (PAA -> PaC)
The client was not granted access, or was disconnected, due to The client was not granted access, or was disconnected, due to
administrative reasons. administrative reasons.
SESSION_TIMEOUT 8 (PAA -> PaC) SESSION_TIMEOUT 8 (PAA -> PaC)
The session has timed out, and service has been terminated. The session has timed out, and service has been terminated.
8. Retransmission Timers 8. Retransmission Timers
The PANA protocol provides retransmissions for the PANA-PAA-Discover The PANA protocol provides retransmissions for the PANA-PAA-Discover
message and all request messages, with the exception that the message and all request messages, with the exception that the PANA-
PANA-Start-Answer message is retransmitted instead of the Start-Answer message is retransmitted instead of the PANA-Start-
PANA-Start-Request message in stateless PAA discovery. Request message in stateless PAA discovery.
PANA retransmission timers are based on the model used in DHCPv6 PANA retransmission timers are based on the model used in DHCPv6
[RFC3315]. Variables used here are also borrowed from this [RFC3315]. Variables used here are also borrowed from this
specification. PANA is a request response like protocol. The specification. PANA is a request response like protocol. The
message exchange terminates when either the request sender message exchange terminates when either the request sender
successfully receives the appropriate answer, or when the message successfully receives the appropriate answer, or when the message
exchange is considered to have failed according to the retransmission exchange is considered to have failed according to the retransmission
mechanism described below. mechanism described below.
The retransmission behavior is controlled and described by the The retransmission behavior is controlled and described by the
skipping to change at page 61, line 37 skipping to change at page 65, line 37
in the cases where it is possible, concrete suggestions on how the in the cases where it is possible, concrete suggestions on how the
request can be modified so as to become acceptable. request can be modified so as to become acceptable.
9.1 PANA UDP Port Number 9.1 PANA UDP Port Number
PANA uses one well-known UDP port number (Section 5.1, Section 4.2 PANA uses one well-known UDP port number (Section 5.1, Section 4.2
and Section 6.1), which needs to be assigned by the IANA. and Section 6.1), which needs to be assigned by the IANA.
9.2 PANA Multicast Address 9.2 PANA Multicast Address
PANA uses one well-known IPv4 multicast address for which the scope PANA uses one well-known administratively scoped IPv4 multicast
is limited to be link-local by setting the TTL field to 255, and one address, and one well-known administratively scoped IPv6 multicast
well-known IPv6 link-local scoped multicast address (Section 4.2 and address (Section 4.2 and Section 6.1), which need to be assigned by
Section 6.1), which need to be assigned by the IANA. the IANA.
9.3 PANA Header 9.3 PANA Header
As defined in Section 6.2, the PANA header contains two fields that As defined in Section 6.2, the PANA header contains two fields that
requires IANA namespace management; the Message Type and Flags field. requires IANA namespace management; the Message Type and Flags field.
9.3.1 Message Type 9.3.1 Message Type
The Message Type namespace is used to identify PANA messages. Values The Message Type namespace is used to identify PANA messages. Values
0-65,533 are for permanent, standard message types, allocated by IETF 0-65,533 are for permanent, standard message types, allocated by IETF
skipping to change at page 62, line 31 skipping to change at page 66, line 31
As defined in Section 6.3, the AVP header contains three fields that As defined in Section 6.3, the AVP header contains three fields that
requires IANA namespace management; the AVP Code, AVP Flags and requires IANA namespace management; the AVP Code, AVP Flags and
Vendor-Id fields where only the AVP Code and AVP Flags create new Vendor-Id fields where only the AVP Code and AVP Flags create new
namespaces. namespaces.
9.4.1 AVP Code 9.4.1 AVP Code
The AVP Code namespace is used to identify attributes. There are The AVP Code namespace is used to identify attributes. There are
multiple namespaces. Vendors can have their own AVP Codes namespace multiple namespaces. Vendors can have their own AVP Codes namespace
which will be identified by their Vendor-ID (also known as which will be identified by their Vendor-ID (also known as
Enterprise-Number) and they control the assignments of their Enterprise-Number) and they control the assignments of their vendor-
vendor-specific AVP codes within their own namespace. The absence of specific AVP codes within their own namespace. The absence of a
a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA
controlled AVP Codes namespace. The AVP Codes and sometimes also controlled AVP Codes namespace. The AVP Codes and sometimes also
possible values in an AVP are controlled and maintained by IANA. possible values in an AVP are controlled and maintained by IANA.
AVP Code 0 is not used. This document defines the AVP Codes 1-19. AVP Code 0 is not used. This document defines the AVP Codes 1-18.
See Section 7.3.8 through Section 7.3.5 for the assignment of the See Section 7.3.1 through Section 7.3.18 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 with Specification
Required [IANA]. Release of blocks of AVPs (more than 3 at a time Required [IANA]. Release of blocks of AVPs (more than 3 at a time
for a given purpose) should require IETF Consensus. for a given purpose) should require IETF Consensus.
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
skipping to change at page 63, line 22 skipping to change at page 67, line 22
9.5 AVP Values 9.5 AVP Values
Certain AVPs in PANA define a list of values with various meanings. Certain AVPs in PANA define a list of values with various meanings.
For attributes other than those specified in this section, adding For attributes other than those specified in this section, adding
additional values to the list can be done on a First Come, First additional values to the list can be done on a First Come, First
Served basis by IANA [IANA]. Served basis by IANA [IANA].
9.5.1 Algorithm Values of MAC AVP 9.5.1 Algorithm Values of MAC AVP
As defined in Section 7.3.8, the Algorithm field of MAC AVP (AVP Code As defined in Section 7.3.7, the Algorithm field of MAC AVP (AVP Code
8) defines the value of 1 (one) for HMAC-SHA1. 7) defines the value of 1 (one) for HMAC-SHA1.
All remaining values are available for assignment via IETF Consensus All remaining values are available for assignment via IETF Consensus
[IANA]. [IANA].
9.5.2 Post-PANA-Address-Configuration AVP Values 9.5.2 Post-PANA-Address-Configuration AVP Values
As defined in Section 7.3.12, the Post-PANA-Address-Configuration AVP As defined in Section 7.3.11, the Post-PANA-Address-Configuration AVP
(AVP Code 12) defines the bits 0 ('N': no configuration), 1 ('D': (AVP Code 11) defines the bits 0 ('N': no configuration), 1 ('D':
DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec
tunnel mode) and 4 ('I': IKEv2). tunnel mode) and 4 ('I': IKEv2).
All remaining values are available for assignment via a Standards All remaining values are available for assignment via a Standards
Action [IANA]. Action [IANA].
9.5.3 Protection-Capability AVP Values 9.5.3 Protection-Capability AVP Values
As defined in Section 7.3.13, the Protection-Capability AVP (AVP Code As defined in Section 7.3.12, the Protection-Capability AVP (AVP Code
13) defines the values 0 and 1. 12) defines the values 0 and 1.
All remaining values are available for assignment via a Standards All remaining values are available for assignment via a Standards
Action [IANA]. Action [IANA].
9.5.4 Result-Code AVP Values 9.5.4 Result-Code AVP Values
As defined in Section 7.3.16.1 and Section 7.3.16.2 the Result-Code As defined in Section 7.3.15.1 and Section 7.3.15.2 the Result-Code
AVP (AVP Code 16) defines the values 2001, 3001-3002, 3008-3009, AVP (AVP Code 15) defines the values 2001, 3001-3002, 3008-3009,
4001, 5001-5009 and 5011-5019. 4001, 5001-5009 and 5011-5017.
All remaining values are available for assignment via IETF Consensus All remaining values are available for assignment via IETF Consensus
[IANA]. [IANA].
9.5.5 Termination-Cause AVP Values 9.5.5 Termination-Cause AVP Values
As defined in Section 7.3.19, the Termination-Cause AVP (AVP Code 19) As defined in Section 7.3.18, the Termination-Cause AVP (AVP Code 18)
defines the values 1, 4 and 8. defines the values 1, 4 and 8.
All remaining values are available for assignment via IETF Consensus All remaining values are available for assignment via IETF Consensus
[IANA]. [IANA].
10. Security Considerations 10. Security Considerations
The PANA protocol defines a UDP-based EAP encapsulation that runs The PANA protocol defines a UDP-based EAP encapsulation that runs
between two IP-enabled nodes on the same IP link. Various security between two IP-enabled nodes on the same IP link. Various security
threats that are relevant to a protocol of this nature are outlined threats that are relevant to a protocol of this nature are outlined
in [I-D.ietf-pana-threats-eval]. Security considerations stemming in [RFC4016]. Security considerations stemming from the use of EAP
from the use of EAP and EAP methods are discussed in [RFC3748]. This and EAP methods are discussed in [RFC3748]. This section provides a
section provides a discussion on the security-related issues that are discussion on the security-related issues that are related to PANA
related to PANA framework and protocol design. 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 crytographically-secured cdma2000 networks and 3GPP2 networks with crytographically-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, one needs to be
created in conjunction with PANA using a link-layer or network-layer created in conjunction with PANA using a link-layer or network-layer
cryptographic mechanism (e.g., IPsec). cryptographic mechanism (e.g., IPsec).
10.1 General Security Measures 10.1 General Security Measures
PANA provides multiple mechanisms to secure a PANA session. PANA provides multiple mechanisms to secure a PANA session.
Since the PaC and PAA are on the same IP link, a simple TTL check on
the received PANA messages prevents off-link attacks.
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
addition to accomplishing orderly delivery of EAP messages and addition to accomplishing orderly delivery of EAP messages and
duplicate elimination, this scheme also helps prevent an adversary duplicate elimination, this scheme also helps prevent an adversary
spoof messages to disturb ongoing PANA and EAP sessions unless it can spoof messages to disturb ongoing PANA and EAP sessions unless it can
also eavesdrop to synchronize on the expected sequence number. also eavesdrop to synchronize on the expected sequence number.
Furthermore, impact of replay attacks is reduced as any stale message Furthermore, impact of replay attacks is reduced as any stale message
skipping to change at page 66, line 18 skipping to change at page 70, line 16
PANA messages when the used EAP method can generate cryptographic PANA messages when the used EAP method can generate cryptographic
session keys. A PANA SA is generated based on the AAA-Key exported session keys. A PANA SA is generated based on the AAA-Key exported
by the EAP method. This SA is used for generating per-packet MAC to by the EAP method. This SA is used for generating per-packet MAC to
protect the PANA header and payload (including the complete EAP protect the PANA header and payload (including the complete EAP
message). message).
The cryptographic protection prevents an adversary from acting as a The cryptographic protection prevents an adversary from acting as a
man-in-the-middle, injecting messages, replaying messages and man-in-the-middle, injecting messages, replaying messages and
modifying the content of the exchanged messages. Any packet that modifying the content of the exchanged messages. Any packet that
fails to pass the MAC verification is silently discarded. The fails to pass the MAC verification is silently discarded. The
earliest this protection can be enabled is when the very first earliest this protection can be enabled is when the very first PANA-
PANA-Bind-Request or PANA-FirstAuth-End-Request message that signals Bind-Request or PANA-FirstAuth-End-Request message that signals a
a successful authentication is generated. Starting with these successful authentication is generated. Starting with these
messages, any subsequent PANA message until the session gets torn messages, any subsequent PANA message until the session gets torn
down can be cryptographically protected. down can be cryptographically protected.
The PANA SA enables authenticated and integrity protected exchange of The PANA SA enables authenticated and integrity protected exchange of
the device ID information between the PaC and PAA. This ensures the device ID information between the PaC and PAA. This ensures
there were no man-in-the-middle during the PANA authentication. there were no man-in-the-middle during the PANA authentication.
The lifetime of the PANA SA is set to PANA session lifetime which is The lifetime of the PANA SA is set to PANA session lifetime which is
bounded by the lifetime granted by the authentication server. An bounded by the lifetime granted by the authentication server. An
implementation MAY add a tolerance period to that value. Unless the implementation MAY add a tolerance period to that value. Unless the
skipping to change at page 66, line 46 skipping to change at page 70, line 44
environment. Insecure lower-layers necessitate use of key-generating environment. Insecure lower-layers necessitate use of key-generating
EAP methods. In networks where lower-layers are already secured, EAP methods. In networks where lower-layers are already secured,
cryptographic protection of PANA messages is not necessary. cryptographic protection of PANA messages is not necessary.
10.2 Discovery 10.2 Discovery
The discovery and handshake phase is vulnerable to spoofing attacks The discovery and handshake phase is vulnerable to spoofing attacks
as these messages are not authenticated and integrity protected. In as these messages are not authenticated and integrity protected. In
order to prevent very basic denial-of service attacks an adversary order to prevent very basic denial-of service attacks an adversary
should not be able to cause state creation by sending discovery should not be able to cause state creation by sending discovery
messages to the PAA. This protection is achieved by using a messages to the PAA. This protection is achieved by using a cookie-
cookie-based scheme (similar to [RFC2522] which allows the responder based scheme (similar to [RFC2522] which allows the responder (PAA)
(PAA) to be stateless in the first round of message exchange. A to be stateless in the first round of message exchange. A return-
return-routability test does not provide additional protection as routability test does not provide additional protection as PANA
PANA traffic is not routed but simply forwarded on-link. It is traffic is not routed but simply forwarded on-link. It is difficult
difficult to prevent this threat entirely. to prevent this threat entirely.
In networks where lower-layers are not secured prior to running PANA, In networks where lower-layers are not secured prior to running PANA,
the capability discovery enabled through inclusion of the capability discovery enabled through inclusion of Protection-
Protection-Capability and Post-PANA-Address-Configuration AVPs in a Capability and Post-PANA-Address-Configuration AVPs in a PANA-Start-
PANA-Start-Request message is susceptible to spoofing leading to Request message is susceptible to spoofing leading to denial-of
denial-of service attacks. Therefore, usage of these AVPs during the service attacks. Therefore, usage of these AVPs during the discovery
discovery and handshake phase in such insecure networks is NOT and handshake phase in such insecure networks is NOT RECOMMENDED.
RECOMMENDED. The same AVPs are delivered via an integrity-protected The same AVPs are delivered via an integrity-protected PANA-Bind-
PANA-Bind-Request upon successful authentication. Request upon successful authentication.
10.3 EAP Methods 10.3 EAP Methods
Eavesdropping EAP messages might cause problems when the EAP method Eavesdropping EAP messages might cause problems when the EAP method
is weak and enables dictionary or replay attacks or even allows an is weak and enables dictionary or replay attacks or even allows an
adversary to learn the long-term password directly. Furthermore, if adversary to learn the long-term password directly. Furthermore, if
the optional EAP Response/Identity payload is used then it allows the the optional EAP Response/Identity payload is used then it allows the
adversary to learn the identity of the PaC. In such a case a privacy adversary to learn the identity of the PaC. In such a case a privacy
problem is prevalent. problem is prevalent.
skipping to change at page 68, line 28 skipping to change at page 72, line 26
The lifetime of PaC-EP master key is bounded by the lifetime of the The lifetime of PaC-EP master key is bounded by the lifetime of the
PANA SA. This key may be used with a secure association protocol PANA SA. This key may be used with a secure association protocol
[I-D.ietf-ipsec-ikev2] to produce further cipher-specific and [I-D.ietf-ipsec-ikev2] to produce further cipher-specific and
transient keys. transient keys.
10.6 Per-packet Ciphering 10.6 Per-packet Ciphering
Networks that are not secured at the lower-layers prior to running Networks that are not secured at the lower-layers prior to running
PANA can rely on enabling per-packet data traffic ciphering upon PANA can rely on enabling per-packet data traffic ciphering upon
successful PANA session establishment. The PANA framework allows successful PANA session establishment. The PANA framework allows
generation of a PaC-EP master key from AAA-Key for using with a generation of a PaC-EP master key from AAA-Key for using with a per-
per-packet protection mechanism, such as link-layer or IPsec-based packet protection mechanism, such as link-layer or IPsec-based
ciphering [I-D.ietf-pana-ipsec]. In case the master key is not ciphering [I-D.ietf-pana-ipsec]. In case the master key is not
readily useful to the ciphering mechanism, an additional secure readily useful to the ciphering mechanism, an additional secure
association protocol [I-D.ietf-ipsec-ikev2] may be needed to produce association protocol [I-D.ietf-ipsec-ikev2] may be needed to produce
the required keying material. These mechanisms ultimately establish the required keying material. These mechanisms ultimately establish
a cryptographic binding between the data traffic generated by and for a cryptographic binding between the data traffic generated by and for
a client and the authenticated identity of the client. Data traffic a client and the authenticated identity of the client. Data traffic
must be minimally data origin authenticated, replay and integrity must be minimally data origin authenticated, replay and integrity
protected, and optionally encrypted. protected, and optionally encrypted.
10.7 PAA-to-EP Communication 10.7 PAA-to-EP Communication
skipping to change at page 69, line 35 skipping to change at page 73, line 34
available in order to prevent threats associated with the abuse of available in order to prevent threats associated with the abuse of
this functionality. this functionality.
Any valid PANA answer message received in response to a recently sent Any valid PANA answer message received in response to a recently sent
request message can be taken as an indication of peer's liveness. request message can be taken as an indication of peer's liveness.
The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a
recent exchange has already confirmed that the peer is alive. recent exchange has already confirmed that the peer is alive.
10.9 Updating PaC's IP Address 10.9 Updating PaC's IP Address
Even though the IP-Address AVP in a PANA-Update-Request can be There is no way to prove the ownership of the IP address presented by
cryptographically protected by the MAC AVP, there is not way to prove the PaC. Hence an authorized PaC can launch a redirect attack by
the ownership of the IP address presented by the PaC. Hence an spoofing a victim's IP address.
authorized PaC can launch a redirect attack by spoofing a victim's IP
address.
10.10 Early Termination of a Session 10.10 Early Termination of a Session
The PANA protocol supports the ability for both the PaC and the PAA The PANA protocol supports the ability for both the PaC and the PAA
to transmit a tear-down message before the session lifetime expires. to transmit a tear-down message before the session lifetime expires.
This message causes state removal, a stop of the accounting procedure This message causes state removal, a stop of the accounting procedure
and removes the installed per-PaC state on the EP(s). This message and removes the installed per-PaC state on the EP(s). This message
is cryptographically protected when PANA SA is present. is cryptographically protected when PANA SA is present.
11. Acknowledgments 11. Acknowledgments
skipping to change at page 71, line 12 skipping to change at page 75, line 12
and all members of the PANA working group for their valuable comments and all members of the PANA working group for their valuable comments
to this document. to this document.
12. References 12. References
12.1 Normative References 12.1 Normative References
[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.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
2131, March 1997. RFC 2131, March 1997.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. RFC 2365, July 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
M. Carney, "Dynamic Host Configuration Protocol for IPv6 Timer", RFC 2988, November 2000.
(DHCPv6)", RFC 3315, July 2003.
[RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003. IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
3748, June 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[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-04 (work in Management Framework", draft-ietf-eap-keying-06 (work in
progress), November 2004. progress), April 2005.
[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.
12.2 Informative References 12.2 Informative References
[I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-09 (work in progress), August
2004.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[I-D.ietf-pana-threats-eval] [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication
Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security
and Network Access Threat Analysis and Security Requirements", RFC 4016, March 2005.
Requirements", draft-ietf-pana-threats-eval-07 (work in
progress), August 2004. [I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-09 (work in progress),
August 2004.
[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-05 (work in progress), Control", draft-ietf-pana-ipsec-05 (work in progress),
December 2004. December 2004.
[I-D.ietf-pana-framework] [I-D.ietf-pana-framework]
Jayaraman, P., "PANA Framework", Jayaraman, P., "PANA Framework",
draft-ietf-pana-framework-02 (work in progress), September draft-ietf-pana-framework-03 (work in progress),
2004. December 2004.
[I-D.ietf-pana-snmp] [I-D.ietf-pana-snmp]
Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for Mghazli, Y., "SNMP usage for PAA-EP interface",
PAA-2-EP interface", draft-ietf-pana-snmp-02 (work in draft-ietf-pana-snmp-03 (work in progress), February 2005.
progress), October 2004.
[I-D.ietf-eap-statemachine] [I-D.ietf-eap-statemachine]
Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, 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", (EAP) Peer and Authenticator",
draft-ietf-eap-statemachine-05 (work in progress), draft-ietf-eap-statemachine-06 (work in progress),
September 2004. December 2004.
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October draft-ietf-ipsec-ikev2-17 (work in progress),
2004. October 2004.
[I-D.ietf-dna-link-information] [I-D.ietf-dna-link-information]
Yegin, A., "Link-layer Event Notifications for Detecting Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 Network Attachments", draft-ietf-dna-link-information-01
(work in progress), September 2004. (work in progress), February 2005.
[I-D.adrangi-eap-network-discovery] [I-D.adrangi-eap-network-discovery]
Adrangi, F., "Mediating Network Discovery in the Adrangi, F., "Identity selection hints for Extensible
Extensible Authentication Protocol (EAP)", Authentication Protocol (EAP)",
draft-adrangi-eap-network-discovery-07 (work in progress), draft-adrangi-eap-network-discovery-12 (work in progress),
December 2004. April 2005.
[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.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", RFC 2279, January 1998.
Authors' Addresses Authors' Addresses
Dan Forsberg Dan Forsberg
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 NOKIA GROUP FIN-00045 NOKIA GROUP
Finland Finland
Phone: +358 50 4839470 Phone: +358 50 4839470
EMail: dan.forsberg@nokia.com Email: dan.forsberg@nokia.com
Yoshihiro Ohba Yoshihiro Ohba
Toshiba America Research, Inc. Toshiba America Research, Inc.
1 Telcordia Drive 1 Telcordia Drive
Piscataway, NJ 08854 Piscataway, NJ 08854
USA USA
Phone: +1 732 699 5305 Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com Email: yohba@tari.toshiba.com
Basavaraj Patil Basavaraj Patil
Nokia Nokia
6000 Connection Dr. 6000 Connection Dr.
Irving, TX 75039 Irving, TX 75039
USA USA
Phone: +1 972-894-6709 Phone: +1 972-894-6709
EMail: Basavaraj.Patil@nokia.com Email: Basavaraj.Patil@nokia.com
Hannes Tschofenig Hannes Tschofenig
Siemens Corporate Technology Siemens Corporate Technology
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
EMail: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Alper E. Yegin Alper E. Yegin
Samsung Advanced Institute of Technology Samsung Advanced Institute of Technology
75 West Plumeria Drive 75 West Plumeria Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 544 5656 Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com Email: alper.yegin@samsung.com
Appendix A. Example Sequence of Separate NAP and ISP Authentication Appendix A. Example Sequence of Separate NAP and ISP Authentication
A PANA message sequence with separate NAP and ISP authentication is A PANA message sequence with separate NAP and ISP authentication is
illustrated in Figure 12. The example assumes the following illustrated in Figure 12. The example assumes the following
scenario: scenario:
o The PaC initiates the discovery and handshake phase. o The PaC initiates the discovery and handshake phase.
o The PAA offers separate NAP and ISP authentication, as well as a o The PAA offers separate NAP and ISP authentication, as well as a
skipping to change at page 76, line 24 skipping to change at page 80, line 48
-----> PANA-Auth-Request(y+1) // S-flag set -----> PANA-Auth-Request(y+1) // S-flag set
[Session-Id, EAP{Response}, MAC] [Session-Id, EAP{Response}, MAC]
<----- PANA-Auth-Answer(y+1) // S-flag set <----- PANA-Auth-Answer(y+1) // S-flag set
[Session-Id, MAC] [Session-Id, MAC]
<----- PANA-Auth-Request(x+5) // S-flag set <----- PANA-Auth-Request(x+5) // S-flag set
[Session-Id, EAP{Request}, MAC] [Session-Id, EAP{Request}, MAC]
-----> PANA-Auth-Answer(x+5) // S-flag set -----> PANA-Auth-Answer(x+5) // S-flag set
[Session-Id, EAP{Response}, MAC] // Piggybacking [Session-Id, EAP{Response}, MAC] // Piggybacking
<----- PANA-Bind-Request(x+6) // S-flag set <----- PANA-Bind-Request(x+6) // S-flag set
[Session-Id, Result-Code, EAP{Success}, Device-Id, [Session-Id, Result-Code, EAP{Success}, Device-Id,
IP-Address, Key-Id, Lifetime, Key-Id, Lifetime, Protection-Cap., PPAC, MAC]
Protection-Cap., PPAC, MAC]
-----> PANA-Bind-Answer(x+6) // S-flag set -----> PANA-Bind-Answer(x+6) // S-flag set
[Session-Id, Device-Id, Key-Id, [Session-Id, Device-Id, Key-Id,
PPAC, MAC] PPAC, MAC]
Figure 12: A Complete Message Sequence for Separate NAP and ISP Figure 12: A Complete Message Sequence for Separate NAP and ISP
Authentication Authentication
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
skipping to change at page 77, line 41 skipping to change at page 82, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/