draft-ietf-pana-pana-07b.txt		draft-ietf-pana-pana-07c.txt
PANA Working Group D. Forsberg		PANA Working Group D. Forsberg
Internet-Draft Nokia		Internet-Draft Nokia
Expires: June 13, 2005 Y. Ohba (Ed.)		Expires: June 15, 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 13, 2004		December 15, 2004
Protocol for Carrying Authentication for Network Access (PANA)		Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-07b		draft-ietf-pana-pana-07c
Status of this Memo		Status of this Memo
By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
RFC 3668.		RFC 3668.
Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
Skipping to change at page 1, line 41:
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 13, 2005.		This Internet-Draft will expire on June 15, 2005.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
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
Skipping to change at page 2, line 24:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Specification of Requirements . . . . . . . . . . . . . . 5		1.1 Specification of Requirements . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . 15
4.4 Access Phase . . . . . . . . . . . . . . . . . . . . . . . 18		4.4 Access Phase . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Re-authentication Phase . . . . . . . . . . . . . . . . . 18		4.5 Re-authentication Phase . . . . . . . . . . . . . . . . . 19
4.6 Termination Phase . . . . . . . . . . . . . . . . . . . . 20		4.6 Termination Phase . . . . . . . . . . . . . . . . . . . . 20
4.7 Separate NAP and ISP Authentication . . . . . . . . . . . 21		4.7 Separate NAP and ISP Authentication . . . . . . . . . . . 21
4.7.1 Negotiating Separate NAP and ISP Authentication . . . 21		4.7.1 Negotiating Separate NAP and ISP Authentication . . . 21
4.7.2 Execution of Separate NAP and ISP Authentication . . . 22		4.7.2 Execution of Separate NAP and ISP Authentication . . . 22
4.7.3 AAA-Key Calculation . . . . . . . . . . . . . . . . . 23		4.7.3 AAA-Key Calculation . . . . . . . . . . . . . . . . . 23
5. Protocol Design Details and Processing Rules . . . . . . . . 24		5. Protocol Design Details and Processing Rules . . . . . . . . 24
5.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 24		5.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 24
5.1.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 24		5.1.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 24
5.2 Sequence Number and Retransmission . . . . . . . . . . . . 24		5.2 Sequence Number and Retransmission . . . . . . . . . . . . 24
5.3 PANA Security Association . . . . . . . . . . . . . . . . 25		5.3 PANA Security Association . . . . . . . . . . . . . . . . 25
Skipping to change at page 3, line 21:
7.2.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . 43		7.2.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . 43
7.2.12 PANA-Termination-Request (PTR) . . . . . . . . . . . 43		7.2.12 PANA-Termination-Request (PTR) . . . . . . . . . . . 43
7.2.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . 44		7.2.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . 44
7.2.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . 44		7.2.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . 44
7.2.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . 44		7.2.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . 44
7.2.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 44		7.2.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 44
7.2.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 45		7.2.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 45
7.2.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . 45		7.2.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . 45
7.2.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 45		7.2.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 45
7.3 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 45		7.3 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 45
7.3.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 48		7.3.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 47
7.3.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 49		7.3.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 48
7.3.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . 49		7.3.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . 48
7.3.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 49		7.3.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 48
7.3.5 Protection-Capability AVP . . . . . . . . . . . . . . 49		7.3.5 Protection-Capability AVP . . . . . . . . . . . . . . 48
7.3.6 Termination-Cause AVP . . . . . . . . . . . . . . . . 50		7.3.6 Termination-Cause AVP . . . . . . . . . . . . . . . . 49
7.3.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . 50		7.3.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . 49
7.3.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 53		7.3.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 52
7.3.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . 54		7.3.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . 53
7.3.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . 54		7.3.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . 53
7.3.11 NAP-Information AVP . . . . . . . . . . . . . . . . 54		7.3.11 NAP-Information AVP . . . . . . . . . . . . . . . . 53
7.3.12 ISP-Information AVP . . . . . . . . . . . . . . . . 54		7.3.12 ISP-Information AVP . . . . . . . . . . . . . . . . 53
7.3.13 Provider-Identifier AVP . . . . . . . . . . . . . . 54		7.3.13 Provider-Identifier AVP . . . . . . . . . . . . . . 53
7.3.14 Provider-Name AVP . . . . . . . . . . . . . . . . . 54		7.3.14 Provider-Name AVP . . . . . . . . . . . . . . . . . 53
7.3.15 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . 55		7.3.15 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . 54
7.3.16 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 55		7.3.16 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 54
7.3.17 Nonce AVP . . . . . . . . . . . . . . . . . . . . . 56		7.3.17 Nonce AVP . . . . . . . . . . . . . . . . . . . . . 55
7.3.18 IP-Address AVP . . . . . . . . . . . . . . . . . . . 56		7.3.18 IP-Address AVP . . . . . . . . . . . . . . . . . . . 55
8. Retransmission Timers . . . . . . . . . . . . . . . . . . . 57		8. Retransmission Timers . . . . . . . . . . . . . . . . . . . 56
8.1 Transmission and Retransmission Parameters . . . . . . . . 58		8.1 Transmission and Retransmission Parameters . . . . . . . . 57
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 60		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 59
9.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 60		9.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 59
9.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 60		9.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 59
9.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 60		9.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 59
9.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . 60		9.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . 59
9.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 61		9.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 61		9.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . 61		9.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . 60
9.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 62		9.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 61
9.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 62		9.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 61
9.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . . 62		9.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . . 61
9.5.2 Protection-Capability AVP Values . . . . . . . . . . . 62		9.5.2 Protection-Capability AVP Values . . . . . . . . . . . 61
9.5.3 Termination-Cause AVP Values . . . . . . . . . . . . . 62		9.5.3 Termination-Cause AVP Values . . . . . . . . . . . . . 61
9.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . 62		9.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . 61
9.5.5 Post-PANA-Address-Configuration AVP Values . . . . . . 63		9.5.5 Post-PANA-Address-Configuration AVP Values . . . . . . 62
10. Security Considerations . . . . . . . . . . . . . . . . . . 64		10. Security Considerations . . . . . . . . . . . . . . . . . . 63
10.1 General Security Measures . . . . . . . . . . . . . . . 64		10.1 General Security Measures . . . . . . . . . . . . . . . 63
10.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 65		10.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 64
10.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 66		10.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 65
10.4 Separate NAP and ISP Authentication . . . . . . . . . . 66		10.4 Separate NAP and ISP Authentication . . . . . . . . . . 65
10.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 66		10.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 65
10.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 67		10.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 66
10.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 67		10.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 66
10.8 Liveness Test . . . . . . . . . . . . . . . . . . . . . 68		10.8 Liveness Test . . . . . . . . . . . . . . . . . . . . . 67
10.9 Updating PaC's IP Address . . . . . . . . . . . . . . . 68		10.9 Updating PaC's IP Address . . . . . . . . . . . . . . . 67
10.10 Early Termination of a Session . . . . . . . . . . . . . 68		10.10 Early Termination of a Session . . . . . . . . . . . . . 67
11. Open Issues and Change History . . . . . . . . . . . . . . . 69		11. Open Issues and Change History . . . . . . . . . . . . . . . 68
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 70		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 69
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 71		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.1 Normative References . . . . . . . . . . . . . . . . . . . 71		13.1 Normative References . . . . . . . . . . . . . . . . . . . 70
13.2 Informative References . . . . . . . . . . . . . . . . . . 72		13.2 Informative References . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 74		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 73
A. Example Sequence of Separate NAP and ISP Authentication . . 76		A. Example Sequence of Separate NAP and ISP Authentication . . 75
Intellectual Property and Copyright Statements . . . . . . . 78		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.
Skipping to change at page 7, line 12:
"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.		network access authorization. The PaC and the EAP peer are
		co-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). Note the		and identified by a Device Identifier (DI). The PAA and the EAP
authentication and authorization procedure can, according to the		authenticator (and optionally the EAP server) are co-located in
EAP model, be also offloaded to the backend AAA infrastructure.		the same node. Note the authentication and authorization
		procedure can, according to the EAP model, be also offloaded to
		the backend AAA infrastructure.
PANA Session:		PANA Session:
A PANA session begins with the handshake between the PANA Client		A PANA session begins with the handshake between the PANA Client
(PaC) and the PANA Authentication Agent (PAA), and terminates as a		(PaC) and the PANA Authentication Agent (PAA), and terminates as a
result of an authentication failure, a timeout, or an explicit		result of an authentication failure, a timeout, or an explicit
termination message. A fixed session identifier is maintained		termination message. A fixed session identifier is maintained
throughout a session. A session cannot be shared across multiple		throughout a session. A session cannot be shared across multiple
network interfaces.		network interfaces.
Skipping to change at page 16, line 51:
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
(PANA-FirstAuth-End-Request, PANA-Bind-Request) and any subsequent		(PANA-FirstAuth-End-Request, PANA-Bind-Request) and any subsequent
message MUST contain a MAC AVP.		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), and
the IP address of the PAA to the PANA SA. To achieve this, the		the IP address of the PAA to the PANA SA. To achieve this, the
PANA-Bind-Request SHOULD contain the device identifier(s) of the		PANA-Bind-Request message MUST contain the device identifier in a
EP(s) in Device-Id AVP(s) when they are either MAC or IP address(es),		Device-Id AVP for each EP if a Protection-Capability AVP is included
and the IP address of the PAA in an IP-Address AVP. PANA-Bind-Answer		in the message. Otherwise, the message SHOULD contain the device
SHOULD contain PaC's device identifier in a Device-Id AVP when it is		identifier in a Device-Id AVP for each EP when a link-layer or IP
already presented with that of EP(s). The PaC MUST use the same type		address is used as the device identifier of the PaC. The
of device identifier as contained in the PANA-Bind-Request message.		PANA-Bind-Request message MUST also contain the IP address of the PAA
This exchange when protected by a MAC AVP prevents man-in-the-middle		in an IP-Address AVP. The PANA-Bind-Answer message MUST contain the
attacks. The PANA-Bind-Request message MAY also contain a		PaC's device identifier in a Device-Id AVP when it is already
Protection-Capability AVP to indicate if link-layer or network-layer		presented with that of EP(s) in the request with using the same type
ciphering should be initiated after PANA. No link-layer or		of device identifier as contained in the request. If the
network-layer specific information is included in the		PANA-Bind-Answer message sent from the PaC does not contain a
Protection-Capability AVP. It is assumed that the PAA is aware of		Device-Id AVP with the same device identifier type contained in the
the security capabilities of the access network. The PANA protocol		request, the PAA sends a PANA-Error-Request message with a
does not specify how the PANA SA and the Protection-Capability AVP		PANA_MISSING_AVP result code, and wait for a PANA-Error-Answer
will be used to provide per-packet protection for data traffic.		message to terminate the session. The PANA-Bind-Request message with
		a PANA_SUCCESS result code MUST also contain a Protection-Capability
		AVP if link-layer or network-layer ciphering is enabled after the
		authentication and authorization phase. The PANA-Bind-Request
		message MAY also contain a Protection-Capability AVP to indicate if
		link-layer or network-layer ciphering should be initiated after PANA.
		No link-layer or network-layer specific information is included in
		the Protection-Capability AVP. It is assumed that the PAA is aware
		of 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. The		address MUST be configured and the available methods to do so. The
PaC MUST include a PPAC AVP in order to indicate its choice of method		PaC MUST include a PPAC AVP in order to indicate its choice of method
when there is a match between the methods offered by the PAA and the		when there is a match between the methods offered by the PAA and the
methods available on the PaC. When there is no match, the PaC MUST		methods available on the PaC. When there is no match, the PaC MUST
send a PANA-Error-Request message with a		send a PANA-Error-Request message with a
PANA_PPAC_CAPABILITY_UNSUPPORTED result code and terminate the PANA		PANA_PPAC_CAPABILITY_UNSUPPORTED result code and terminate the PANA
Skipping to change at page 19, line 9:
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 a PaC wants to initiate re-authentication, it sends a		When a PaC wants to initiate re-authentication, it sends a
PANA-Reauth-Request message to the PAA. This message MUST contain a		PANA-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 identifier, it MUST first respond with a		with the matching identifier, it MUST first respond with a
PANA-Reauth-Answer, followed by a PANA-Auth-Request that starts a new		PANA-Reauth-Answer, followed by a PANA-Auth-Request that starts a new
EAP authentication. If PAA cannot identify the session, it MUST		EAP authentication. If the PAA cannot identify the session based on
respond with a PANA-Error-Request with the error code		the received Session-Id, it MUST respond with a PANA-Error-Request
PANA_UNKNOWN_SESSION_ID. PANA-Reauth-Request/Answer messages MUST		with the error code PANA_UNKNOWN_SESSION_ID. The PAA MUST terminate
contain a MAC AVP when PANA SA is available.		the session once it receives a PANA-Error-Answer for the
		PANA-Error-Request. The PANA-Reauth-Request/Answer messages MUST
		contain a MAC AVP when there is a PANA SA in order to avoid a denial
		of service attack.
PaC may receive a PANA-Auth-Request before receiving the answer to		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 when		packet re-ordering or a race condition between the PaC and PAA when
they both attempt to engage in re-authentication. PaC MUST keep		they both attempt to engage in re-authentication. PaC MUST keep
discarding the received PANA-Auth-Requests until it receives the		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-Request message containing the session identifier for the		PANA-Auth-Request message containing the session identifier for the
Skipping to change at page 24, line 40:
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 PaC and PAA		The initial sequence numbers (ISN) are randomly picked by PaC and PAA
as they send their very first request messages. PANA-PAA-Discover		as they send their very first request messages. PANA-PAA-Discover
message carries sequence number 0.		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 the following messages:		expected value. This check does not apply to the PANA-PAA-Discover,
PANA-PAA-Discover, PANA-Start-Request and PANA-Start-Answer.		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.
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).
Skipping to change at page 46, line 19:
0-1 Zero or one instance of the AVP MAY be present in the message.		0-1 Zero or one instance of the AVP MAY be present in the message.
It is considered an error if there are more than one instance		It is considered an error if there are more than one instance
of the AVP.		of the AVP.
1 One instance of the AVP MUST be present in the message.		1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the		1+ At least one instance of the AVP MUST be present in the
message.		message.
+-----------------------------------------+		+-------------------------------------------+
| Message |
| Type |
+-----+-----+-----+-----+-----+-----+-----+
Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
--------------------+-----+-----+-----+-----+-----+-----+-----+
Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 |
Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
EAP-Payload | 0-1 | 0-1 | 1 | 0-1 | 0-1 | 0 | 0 |
MAC | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0 |
Nonce | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0+ | 0-1 | 0 |
Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 |
PPAC | 0-1 | 0 | 0 | 0 | 1 | 0-1 | 0 |
Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
ISP-Information | 0+ | 0-1 | 0 | 0 | 0 | 0 | 0 |
NAP-Information | 0-1 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 |
IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
--------------------+-----+-----+-----+-----+-----+-----+-----+
Figure 10: AVP Occurrence Table (1/3)
+-------------------------------------+
| Message |		| Message |
| Type |		| Type |
+-----+-----+-----+-----+------+------+		+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name | PPR | PPA | PTR | PTA | PFER | PFEA |		Attribute Name |PSR|PSA|PAR|PAN|PBR|PBA|PDI|PPR|PPA|PTR|PTA|
--------------------+-----+-----+-----+-----+------+------+		--------------------+---+---+---+---+---+---+---+---+---+---+---+
Result-Code | 0 | 0 | 0 | 0 | 1 | 0 |		Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
Session-Id | 1 | 1 | 1 | 1 | 1 | 1 |		Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 1 |
Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 |		Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
EAP-Payload | 0 | 0 | 0 | 0 | 1 | 0 |		EAP-Payload |0-1|0-1| 1 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 |
MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 |		MAC | 0 |0-1|0-1|0-1|0-1|0-1| 0 |0-1|0-1|0-1|0-1|
Nonce | 0 | 0 | 0 | 0 | 0 | 0 |		Nonce | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0 | 0 |		Device-Id | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 |
Cookie | 0 | 0 | 0 | 0 | 0 | 0 |		Cookie |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 |		Protection-Cap. |0-1| 0 | 0 | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 |
PPAC | 0 | 0 | 0 | 0 | 0 | 0 |		PPAC |0-1| 0 | 0 | 0 | 1 |0-1| 0 | 0 | 0 | 0 | 0 |
Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 |		Session-Lifetime | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 |		Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 |		ISP-Information | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 |		NAP-Information |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 |		Key-Id | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 |
IP-Address | 0 | 0 | 0 | 0 | 0 | 0 |		IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
--------------------+-----+-----+-----+-----+------+------+		--------------------+---+---+---+---+---+---+---+---+---+---+---+
Figure 11: AVP Occurrence Table (2/3)		Figure 10: AVP Occurrence Table (1/2)
+-------------------------------------+		+-----------------------------------+
| Message |		| Message |
| Type |		| Type |
+-----+-----+-----+-----+------+------+		+----+----+---+---+---+---+----+----+
Attribute Name | PUR | PUA | PER | PEA | PRAR | PRAA |		Attribute Name |PFER|PFEA|PUR|PUA|PER|PEA|PRAR|PRAA|
--------------------+-----+-----+-----+-----+------+------+		--------------------+----+----+---+---+---+---+----+----+
Result-Code | 0 | 0 | 1 | 0 | 0 | 0 |		Result-Code | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
Session-Id | 1 | 1 | 1 | 1 | 1 | 1 |		Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 |		Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
EAP-Payload | 0 | 0 | 0 | 0 | 0 | 0 |		EAP-Payload | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
MAC | 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 |
Nonce | 0 | 0 | 0 | 0 | 0 | 0 |		Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0 | 0 |		Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Cookie | 0 | 0 | 0 | 0 | 0 | 0 |		Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 |		Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
PPAC | 0 | 0 | 0 | 0 | 0 | 0 |		PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 |		Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0+ | 0 | 0 | 0 |		Failed-AVP | 0 | 0 | 0 | 0 | 0+| 0 | 0 | 0 |
ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 |		ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 |		NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0 | 0 |		Key-Id |0-1 |0-1 | 0 | 0 | 0 | 0 | 0 | 0 |
IP-Address | 1 | 0 | 0 | 0 | 0 | 0 |		IP-Address | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
--------------------+-----+-----+-----+-----+------+------+		--------------------+----+----+---+---+---+---+----+----+
Figure 12: AVP Occurrence Table (3/3)		Figure 11: AVP Occurrence Table (2/2)
7.3.1 MAC AVP		7.3.1 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 1)		protect PANA messages. The first octet of the this AVP (AVP Code 1)
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.
Skipping to change at page 69, line 9:
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. Open Issues and Change History		11. Open Issues and Change History
A list of open issues is maintained at [1].		A list of open issues is maintained at [1].
Open issues: 114, 115, 116, 117, 126, 127, 131, 149 and 150.		Open issues: 114, 115, 117, 149 and 150.
Issues resolved in PANA-07b December 2004: 112, 113, 118, 119, 120,		Issues resolved in PANA-07c December 2004: 112, 113, 116, 118, 119,
121, 122, 123, 124, 125, 128, 129, 130, 132, 133, 134, 135, 136, 137,		120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133,
138, 139, 140, 141, 142, 143, 145, 146, 147, 148, 151, 152 and 153.		134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 145, 146, 147, 148,
		151, 152 and 153.
12. Acknowledgments		12. Acknowledgments
We would like to thank Jari Arkko, Mohan Parthasarathy, Julien		We would like to thank Jari Arkko, Mohan Parthasarathy, Julien
Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik		Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik
Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo		Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo
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.
13. References		13. References
Skipping to change at page 76, line 8:
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 13. 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
choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer		choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer
from PAA, with choosing "ISP1" as the ISP.		from PAA, with choosing "ISP1" as the ISP.
o NAP authentication and ISP authentication is performed in this		o NAP authentication and ISP authentication is performed in this
order in the authentication and authorization phase.		order in the authentication and authorization phase.
Skipping to change at page 77, line 30:
-----> 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, EAP{Success}, Device-Id,		[Session-Id, EAP{Success}, Device-Id,
IP-Address, Key-Id, Lifetime,		IP-Address, 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 13: 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
made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information