draft-ietf-pana-pana-03.txt draft-ietf-pana-pana-04.txt
PANA Working Group D. Forsberg PANA Working Group D. Forsberg
Internet-Draft Nokia Internet-Draft Nokia
Expires: August 9, 2004 Y. Ohba Expires: November 5, 2004 Y. Ohba (Ed.)
Toshiba Toshiba
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
A. Yegin A. Yegin
DoCoMo USA Labs Samsung
February 9, 2004 May 7, 2004
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-03 draft-ietf-pana-pana-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
  Skipping to change at page 1, line 38:
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 August 9, 2004. This Internet-Draft will expire on November 5, 2004.
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
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 can authentication method that can be specified as an EAP method, and can
be used on any link that can carry IP. PANA covers the be used on any link that can carry IP. PANA covers the
client-to-network access authentication part of an overall secure client-to-network access authentication part of an overall secure
network access framework, which additionally includes other protocols network access framework, which additionally includes other protocols
and mechanisms for service provisioning, access control as a result and mechanisms for service provisioning, access control as a result
of initial authentication, and accounting. of initial authentication, and accounting.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Specification of Requirements . . . . . . . . . . . . . . 4 1.1 Specification of Requirements . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . 10
4.1 Common Processing Rules . . . . . . . . . . . . . . . . . 9 4.1 Common Processing Rules . . . . . . . . . . . . . . . . . 10
4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 9 4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 10
4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . 10 4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . 11
4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 10 4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4 Sequence Number and Retransmission . . . . . . . . . . . . 10 4.1.4 Sequence Number and Retransmission . . . . . . . . . . . . 11
4.1.5 PANA Security Association . . . . . . . . . . . . . . . . 11 4.1.5 PANA Security Association . . . . . . . . . . . . . . . . 12
4.1.6 Message Authentication Code . . . . . . . . . . . . . . . 12 4.1.6 Message Authentication Code . . . . . . . . . . . . . . . 14
4.1.7 Message Validity Check . . . . . . . . . . . . . . . . . . 13 4.1.7 Message Validity Check . . . . . . . . . . . . . . . . . . 14
4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . . . 14 4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 14 4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 16
4.3 Authentication Phase . . . . . . . . . . . . . . . . . . . 17 4.3 Authentication Phase . . . . . . . . . . . . . . . . . . . 19
4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 19 4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 22
4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 20 4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 23
4.6 Illustration of a Complete Message Sequence . . . . . . . 21 4.6 Illustration of a Complete Message Sequence . . . . . . . 24
4.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 22 4.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 27
4.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 22 4.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 27
4.9 Mobility Handling . . . . . . . . . . . . . . . . . . . . 23 4.9 Mobility Handling . . . . . . . . . . . . . . . . . . . . 28
4.10 Event Notification . . . . . . . . . . . . . . . . . . . . 24 4.10 Support for Separate EP . . . . . . . . . . . . . . . . . 30
4.11 Support for Separate EP . . . . . . . . . . . . . . . . . 24 5. PANA Security Association Establishment . . . . . . . . . 31
5. PANA Security Association Establishment . . . . . . . . . 25 6. Message Formats . . . . . . . . . . . . . . . . . . . . . 32
6. Authentication Method Choice . . . . . . . . . . . . . . . 26 6.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 32
7. Filter Rule Installation . . . . . . . . . . . . . . . . . 27 6.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 32
8. Data Traffic Protection . . . . . . . . . . . . . . . . . 28 6.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Message Formats . . . . . . . . . . . . . . . . . . . . . 29 6.4 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 36
9.1 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 29 6.4.1 Message Specifications . . . . . . . . . . . . . . . . . . 36
9.2 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 37
9.3 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 32 6.4.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 37
9.3.1 Message Specifications . . . . . . . . . . . . . . . . . . 33 6.4.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 37
9.3.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 33 6.4.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 38
9.3.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 33 6.4.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 38
9.3.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 33 6.4.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 38
9.3.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 34 6.4.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 38
9.3.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 34 6.4.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 39
9.3.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 34 6.4.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 39
9.3.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 35 6.4.11 PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 39
9.3.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 35 6.4.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 39
9.3.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 35 6.4.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . . . . 40
9.3.11 PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 35 6.4.14 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . . . . 40
9.3.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 36 6.4.15 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . . . . 40
9.3.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . . . . 36 6.5 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 40
9.4 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 36 6.5.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.4.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.5.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 41
9.4.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 37 6.5.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 41
9.4.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 37 6.5.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 42
9.4.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 38 6.5.5 Protection-Capability AVP . . . . . . . . . . . . . . . . 42
9.4.5 Protection-Capability AVP . . . . . . . . . . . . . . . . 38 6.5.6 Termination-Cause AVP . . . . . . . . . . . . . . . . . . 42
9.4.6 Termination-Cause AVP . . . . . . . . . . . . . . . . . . 38 6.5.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 42
9.4.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 38 6.5.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 46
9.4.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 42 6.5.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 46
9.4.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 42 6.5.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 46
9.4.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 42 6.5.11 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 46
9.4.11 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 42 6.5.12 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 47
9.4.12 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 42 6.5.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . . 47
9.4.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . . 42 6.5.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 47
9.4.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 43 6.5.15 EP-Device-Id AVP . . . . . . . . . . . . . . . . . . . . . 47
9.4.15 EP-Device-Id AVP . . . . . . . . . . . . . . . . . . . . . 43 6.5.16 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 47
9.4.16 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 43 6.5.17 Post-PANA-Address-Configuration (PPAC) AVP . . . . . . . . 47
9.5 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 43 6.5.18 Nonce AVP . . . . . . . . . . . . . . . . . . . . . . . . 48
10. PANA Protocol Message Retransmissions . . . . . . . . . . 45 6.6 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 49
10.1 Transmission and Retransmission Parameters . . . . . . . . 47 7. PANA Protocol Message Retransmissions . . . . . . . . . . 51
11. Security Considerations . . . . . . . . . . . . . . . . . 48 7.1 Transmission and Retransmission Parameters . . . . . . . . 53
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 54
13. Change History . . . . . . . . . . . . . . . . . . . . . . 54 8.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 54
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 55 8.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 54
Normative References . . . . . . . . . . . . . . . . . . . 56 8.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 54
Informative References . . . . . . . . . . . . . . . . . . 57 8.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 59 8.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A. Adding sequence number to PANA for carrying EAP . . . . . 61 8.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 54
A.1 Why is sequence number needed for PANA to carry EAP? . . . 61 8.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.2 Single sequence number approach . . . . . . . . . . . . . 62 8.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2.1 Single sequence number with EAP retransmission method . . 62 8.4.3 Vendor Id . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2.2 Single sequence number with PANA-layer retransmission 8.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 55
method . . . . . . . . . . . . . . . . . . . . . . . . . . 63 8.5.1 MAC AVP Values . . . . . . . . . . . . . . . . . . . . . . 55
A.3 Dual sequence number approach . . . . . . . . . . . . . . 66 8.5.2 Device-Id AVP Values . . . . . . . . . . . . . . . . . . . 55
A.3.1 Dual sequence number with orderly-delivery method . . . . 66 8.5.3 Protection-Capability AVP Values . . . . . . . . . . . . . 55
A.3.2 Dual sequence number with reliable-delivery method . . . . 68 8.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . . . 55
A.3.3 Comparison of the dual sequence number methods . . . . . . 69 8.5.5 Termination-Cause AVP Values . . . . . . . . . . . . . . . 55
A.4 Consensus . . . . . . . . . . . . . . . . . . . . . . . . 69 8.5.6 Provider-Identifier AVP Values . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . 70 8.5.7 Post-PANA-Address-Configuration AVP Values . . . . . . . . 55
9. Security Considerations . . . . . . . . . . . . . . . . . 56
10. Open Issues and Change History . . . . . . . . . . . . . . 62
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 63
Normative References . . . . . . . . . . . . . . . . . . . 64
Informative References . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 69
Intellectual Property and Copyright Statements . . . . . . 71
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. Initial and subsequent client-to-network authentication networks. Initial and subsequent client-to-network authentication
provides parameters that are needed to police the traffic flow provides parameters that are needed to police the traffic flow
through the enforcement points. A protocol is needed to carry through the enforcement points. A protocol is needed to carry
authentication methods between the client and the access network. authentication methods between the client and the access network.
  Skipping to change at page 4, line 38:
Various environments and usage models for PANA are identified in the Various environments and usage models for PANA are identified in the
[I-D.ietf-pana-usage-scenarios] Internet-Draft. Potential security [I-D.ietf-pana-usage-scenarios] Internet-Draft. 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] draft. These two drafts discussed in [I-D.ietf-pana-threats-eval] draft. These two drafts
have been essential in defining the requirements have been essential in defining the requirements
[I-D.ietf-pana-requirements] on the PANA protocol. Note that some of [I-D.ietf-pana-requirements] on the PANA protocol. Note that some of
these requirements are imposed by the chosen payload, EAP these requirements are imposed by the chosen payload, EAP
[I-D.ietf-eap-rfc2284bis]. [I-D.ietf-eap-rfc2284bis].
There are components that are part of a complete secure network
solution but are outside of the PANA protocol specification,
including IP address configuration, authentication method choice,
filter rule installation, data traffic protection and PAA-EP
protocol. These components are described in separate documents
[I-D.ietf-pana-framework][I-D.ietf-pana-snmp].
1.1 Specification of Requirements 1.1 Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
  Skipping to change at page 5, line 32:
network access. network access.
Session Identifier: Session Identifier:
This identifier is used to uniquely identify a PANA session on the This identifier is used to uniquely identify a PANA session on the
PAA and PaC. It is included in PANA messages to bind the message PAA and PaC. It is included in PANA messages to bind the message
to a specific PANA session. to a specific PANA session.
PANA Security Association: PANA Security Association:
The representation of the trust relation between the PaC and the A PANA security association is a relationship between the PaC and
PAA that is created at the end of the authentication phase. This PAA, formed by the sharing of cryptographic keying material and
security association includes the device identifier of the peer, associated context. Security associations are duplex. That is,
and a shared key when available. one security association is needed to protect the bidirectional
traffic between the PaC and the PAA.
PANA Client (PaC): PANA Client (PaC):
The client side of the protocol that resides in the host device The client side of the protocol that resides in the host device
which is responsible for providing the credentials to prove its which is responsible for providing the credentials to prove its
identity for network access authorization. identity for network access authorization.
Device Identifier (DI): Device Identifier (DI):
The identifier used by the network as a handle to control and The identifier used by the network as a handle to control and
  Skipping to change at page 9, line 20:
The payload of any PANA message consists of zero or more AVPs The payload of any PANA message consists of zero or more AVPs
(Attribute Value Pairs). A brief description of the AVPs defined in (Attribute Value Pairs). A brief description of the AVPs defined in
this document is listed below: this document is listed below:
o Cookie AVP: contains a random value that is used for making o Cookie AVP: contains a random value that is used for making
initial handshake robust against blind resource consumption DoS initial handshake robust against blind resource consumption DoS
attacks. attacks.
o Protection-Capability AVP: contains information which protection o Protection-Capability AVP: contains information which protection
should be initiated after the PANA exchange (e.g. link-layer or should be initiated after the PANA exchange (e.g., link-layer or
network layer protection). network layer protection).
o Device-Id AVP: contains a device identifier of the sender of the o Device-Id AVP: contains a device identifier of the sender of the
message. A device identifier is represented as a pair of device message. A device identifier is represented as a pair of device
identifier type and device identifier value. Either a layer-2 identifier type and device identifier value. Either a layer-2
address or an IP address is used for the device identifier value. address or an IP address is used for the device identifier value.
o EP-Device-Id AVP: contains the device identifier of an EP. o EP-Device-Id AVP: contains the device identifier of an EP.
o EAP AVP: contains an EAP PDU. o EAP AVP: contains an EAP PDU.
  Skipping to change at page 10, line 5:
o Session-Lifetime AVP: contains the duration of authorized access. o Session-Lifetime AVP: contains the duration of authorized access.
o Failed-AVP: contains the offending AVP that caused a failure. o Failed-AVP: contains the offending AVP that caused a failure.
o NAP-Information AVP, ISP-Information AVP: contains the information o NAP-Information AVP, ISP-Information AVP: contains the information
on a NAP and an ISP, respectively. on a NAP and an ISP, respectively.
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. Conveys the list
of IP address configuration methods available when sent by the
PAA, and the chosen method when sent by the PaC.
o Nonce AVP: contains a randomly chosen value.
4.1.2 Transport Layer Protocol 4.1.2 Transport Layer Protocol
PANA uses UDP as its transport layer protocol. The UDP port number PANA uses UDP as its transport layer protocol. The UDP port number
is TBD. All messages except for PANA-PAA-Discover are always is TBD. All messages except for PANA-PAA-Discover are always
unicast. PaC MUST NOT use unspecified IP address for communicating unicast. PANA-PAA-Discover MAY be unicasted when the PaC knows the
with PAA. IP address of the PAA.
4.1.3 Fragmentation 4.1.3 Fragmentation
PANA does not provide fragmentation of PANA messages. Instead, it PANA does not provide fragmentation of PANA messages. Instead, it
relies on fragmentation provided by EAP methods and IP layer when relies on fragmentation provided by EAP methods and IP layer when
needed. needed.
4.1.4 Sequence Number and Retransmission 4.1.4 Sequence Number and Retransmission
PANA uses sequence numbers to provide ordered delivery of EAP PANA uses sequence numbers to provide ordered delivery of EAP
messages. The design involves use of two sequence numbers to prevent messages. The design involves use of two sequence numbers to prevent
some of the DoS attacks on the sequencing scheme. Every PANA packet some of the DoS attacks on the sequencing scheme. Every PANA packet
include one transmitted sequence number (tseq) and one received include one transmitted sequence number (tseq) and one received
sequence number (rseq) in the PANA header. See Appendix A for sequence number (rseq) in the PANA header. See [1] for detailed
detailed explanation on why two sequence numbers are needed. explanation on why two sequence numbers are needed.
The two sequence number fields have the same length of 32 bits and The two sequence number fields have the same length of 32 bits and
appear in PANA header. tseq starts from initial sequence number appear in PANA header. tseq starts from initial sequence number
(ISN) and is monotonically increased by 1. The serial number (ISN) and is monotonically increased by 1. The serial number
arithmetic defined in [RFC1982] is used for sequence number arithmetic defined in [RFC1982] is used for sequence number
operation. The ISNs are exchanged between PaC and PAA during the operation. The ISNs are exchanged between PaC and PAA during the
discovery and initial handshake phase (see Section 4.2). The rules discovery and initial handshake phase (see Section 4.2). The rules
that govern the sequence numbers in other phases are described as that govern the sequence numbers in other phases are described as
follows. follows.
  Skipping to change at page 11, line 7:
PANA relies on EAP-layer retransmissions, or for example NAS PANA relies on EAP-layer retransmissions, or for example NAS
functionality [I-D.ietf-aaa-eap], for retransmitting EAP Requests functionality [I-D.ietf-aaa-eap], for retransmitting EAP Requests
based on timer. Other PANA layer messages that require a response based on timer. Other PANA layer messages that require a response
from the communicating peer are retransmitted based on timer at from the communicating peer are retransmitted based on timer at
PANA-layer until a response is received (in which case the PANA-layer until a response is received (in which case the
retransmission timer is stopped) or the number of retransmission retransmission timer is stopped) or the number of retransmission
reaches the maximum value (in which case the PANA session MUST be reaches the maximum value (in which case the PANA session MUST be
deleted immediately). For PANA-layer retransmission, the deleted immediately). For PANA-layer retransmission, the
retransmission timer SHOULD be calculated as described in [RFC2988] retransmission timer SHOULD be calculated as described in [RFC2988]
to provide congestion control. See Section 10 for default timer and to provide congestion control. See Section 7 for default timer and
maximum retransmission count parameters. maximum retransmission count parameters.
4.1.5 PANA Security Association 4.1.5 PANA Security Association
A PANA SA is created as an attribute of a PANA session when EAP A PANA SA is created as an attribute of a PANA session when EAP
authentication succeeds with a creation of 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
authentications are performed in a sequence in a single PANA authentications are performed in sequence in a single PANA
authentication, it is possible that two AAA-Keys are derived. If this authentication phase, it is possible that two AAA-Keys are derived.
happens, the PANA SA MUST be bound to the AAA-Key derived from the If this happens, the PANA SA MUST be generated from both AAA-Keys.
first EAP authentication. When a new AAA-Key is derived as a result When a new AAA-Key is derived as a result of EAP-based
of EAP-based re-authentication, any key derived from the old AAA-Key re-authentication, any key derived from the old AAA-Key MUST be
MUST be updated to a new one that is derived from the new AAA-Key. updated to a new one that is derived from the new AAA-Key. In order
In order to distinguish the new AAA-Key from old ones, one Key-Id AVP to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be
MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at carried in PANA-Bind-Request and PANA-Bind-Answer messages or
the end of the authentication phase which resulted in deriving a new PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at
the end of the EAP authentication which resulted in deriving a new
AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a
value that uniquely identifies the AAA-Key within the PANA session. value that uniquely identifies the AAA-Key within the PANA session.
The PANA-Bind-Answer message sent in response to a PANA-Bind-Request The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer
with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key message) sent in response to a PANA-Bind-Request message (or a
identifier carried in the request. PANA-Bind-Request and PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a
PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP Key-Id AVP with the same AAA-Key identifier carried in the request.
whose value is computed by using the new AAA-Key. Although the PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and
PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry
a MAC AVP whose value is computed by using the new PANA-MAC-Key
derived from the new AAA-Key (or the new pair of AAA-Keys when the
PANA_MAC_KEY is derived from two AAA-Keys). Although the
specification does not mandate a particular method for calculation of specification does not mandate a particular method for calculation of
Key-Id AVP value, a simple method is to use monotonically increasing Key-Id AVP value, a simple method is to use monotonically increasing
numbers. numbers."
The created PANA SA is deleted when the corresponding PANA session is The created PANA SA is deleted when the corresponding PANA session is
deleted. The lifetime of the PANA SA is the same as the lifetime of deleted. The lifetime of the PANA SA is the same as the lifetime of
the PANA session for simplicity. the PANA session for simplicity.
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:
  Skipping to change at page 12, line 28:
* Protection-Capability * Protection-Capability
* PANA SA attributes: * PANA SA attributes:
+ AAA-Key + AAA-Key
+ AAA-Key Identifier + AAA-Key Identifier
+ PANA_MAC_Key + PANA_MAC_Key
The PANA_MAC_Key is used to integrity protect PANA messages and The PANA_MAC_Key is used to integrity protect PANA messages. When
derived from the AAA-Key in the following way: the PANA_MAC_Key is derived from a single AAA-Key, it is computed in
the following way:
PANA_MAC_KEY = The first N bits of PANA_MAC_KEY = The first N bits of
HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID)
where the value of N depends on the integrity protection algorithm in where the value of N depends on the integrity protection algorithm in
use, i.e., N=160 for HMAC-SHA1. use, i.e., N=160 for HMAC-SHA1.
The length of AAA-Key MUST be N bits or longer. See Section 4.1.6 When the PANA_MAC_Key is derived from two AAA-Keys, it is computed in
for the detailed usage of the PANA_MAC_Key. the following way:
PANA_MAC_KEY = The first N bits of
HMAC_SHA1(AAA-Key1 | AAA-Key2, ISN_pac | ISN_paa |
Session-ID)
where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second EAP
authentication in a single PANA authentication phase, respectively.
The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or
longer. See Section 4.1.6 for the detailed usage of the
PANA_MAC_Key.
4.1.6 Message Authentication Code 4.1.6 Message Authentication Code
A PANA message can contain a MAC (Message Authentication Code) AVP A PANA message can contain a MAC (Message Authentication Code) AVP
for cryptographically protecting the message. for cryptographically protecting the message.
When a MAC AVP is included in a PANA message, the value field of the When a MAC AVP is included in a PANA message, the value field of the
MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP is calculated by using the PANA_MAC_Key in the following way:
MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU)
  Skipping to change at page 13, line 20:
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.
4.1.7 Message Validity Check 4.1.7 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 When a device identifier of the communication peer is bound to the o When a device identifier of the communication peer is bound to the
PANA session, it matches the device identifier carried in MAC and/ PANA session, it matches the device identifier carried in MAC and/
or IP header(s). or IP header(s), or other auxiliary indetifier provided by the
lower-layers (e.g., circuit ID).
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. state.
o The message payload contains a valid set of AVPs allowed for the o The message payload contains a valid set of AVPs allowed for the
message type and there is no missing AVP that needs to be included message type and there is no missing AVP that needs to be included
in the payload. in the payload.
o Each AVP is decoded correctly. o Each AVP is decoded correctly.
  Skipping to change at page 14, line 31:
When an error message is sent unprotected with MAC AVP and the When an error message is sent unprotected with 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.
4.2 Discovery and Initial Handshake Phase 4.2 Discovery and Initial Handshake Phase
When a PaC attaches to a network, and knows that it has to discover When a PaC attaches to a network, and knows that it has to discover
PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a well- PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a
known link local multicast address (TBD) and UDP port (TBD). PANA well-known link local multicast address (TBD) and UDP port (TBD).
PAA discovery assumes that PaC and PAA are one hop away from each PANA PAA discovery assumes that PaC and PAA are one hop away from
other. If PaC knows the IP address of the PAA (some each other. If PaC knows the IP address of the PAA (some
pre-configuration), it MAY unicast the PANA discovery message to that pre-configuration), it MAY unicast the PANA discovery message to that
address. PAA SHOULD answer to the PANA-PAA-Discover message with a address. PAA SHOULD answer to the PANA-PAA-Discover message with a
PANA-Start-Request message. PANA-Start-Request message.
When the PAA receives such a request, or upon receiving some lower When the PAA receives such a request, or upon receiving some lower
layer indications of a new PaC, PAA SHOULD unicast a layer indications of a new PaC, PAA SHOULD unicast a
PANA-Start-Request message. PANA-Start-Request message.
There can be multiple PAAs on the link. The authentication and There can be multiple PAAs on the link. The authentication and
authorization result does not depend on which PAA is chosen by the authorization result does not depend on which PAA is chosen by the
PaC. By default the PaC MAY choose the PAA that sent the that sent PaC. By default the PaC MAY choose the PAA that sent the first
the first response. response.
PaC may also choose to start sending packets before getting PaC MAY also choose to start sending packets before getting
authenticated. In that case, the network should detect this and send authenticated. In that case, the network MAY detect this and send an
an unsolicited PANA-Start-Request message to PaC. EP is the node that unsolicited PANA-Start-Request message to PaC in addition to
can detect such activity. If EP and PAA are co-located, then an filtering the unauthorized traffic. EP is the node that can detect
internal mechanism (e.g. API) between the EP module and the PAA such activity. PAA-to-EP protocol MAY be used for this purpose.
module on the same host can prompt PAA to start PANA. In case they
are separate, there needs to be an explicit message to prompt PAA.
Upon detecting the need to authenticate a client, EP can send a
PANA-PAA-Discover message to the PAA on behalf of the PaC. This
message carries a device identifier of the PaC in a Device-ID AVP. So
that, the PAA can send the unsolicited PANA-Start-Request message
directly to the PaC. If the link between the EP and PAA is not
secure, the PANA-PAA-Discover message sent from the EP to the PAA
MUST be protected by using, e.g., IPsec.
A PANA-Start-Request message MAY carry a Cookie AVP that contains a A PANA-Start-Request message MAY carry a Cookie AVP that contains a
cookie. The rseq field of the header is set to zero (0). The tseq cookie. The rseq field of the header is set to zero (0). The tseq
field of the header contains the initial sequence number. The cookie field of the header contains the initial sequence number. The cookie
is used for preventing the PAA from resource consumption DoS attacks is used for preventing the PAA from resource consumption DoS attacks
by blind attackers. The cookie is computed in such a way that it does by blind attackers. The cookie is computed in such a way that it does
not require any per-session state maintenance on the PAA in order to not require any per-session state maintenance on the PAA in order to
verify the cookie returned in a PANA-Start-Answer message. The exact verify the cookie returned in a PANA-Start-Answer message. The exact
algorithms and syntax used for generating cookies does not affect algorithms and syntax used for generating cookies does not affect
interoperability and hence is not specified here. An example interoperability and hence is not specified here. An example
  Skipping to change at page 15, line 36:
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 secret- generating the cookie and '|' indicates concatenation. The secret-
version should be changed frequently enough to prevent replay version should be changed frequently enough to prevent replay
attacks. The secret key is locally known to the PAA only and valid attacks. The secret key is locally known to the PAA only and valid
for a certain time frame. for a certain time frame.
Protection-Capability and Post-PANA-Address-Configuration AVPs MAY be
optionally included in the PANA-Start-Request in order to indicate
required and available capabilities for the network access. These
AVPs MAY be used by the PaC for assessing the capability match even
before the authentication takes place. But these AVPs are provided
during the insecure discovery phase, there are certain security risks
involved in using the provided information. See Section 9 for further
discussion on this.
PAA MAY enable NAP-ISP authentication separation by setting the PAA MAY enable NAP-ISP authentication separation by setting the
S-flag of the message header of the PANA-Start-Request. Also, the S-flag of the message header of the PANA-Start-Request. Also, the
PANA-Start-Request MAY contain zero or one NAP-Information AVP and PANA-Start-Request MAY contain zero or one NAP-Information AVP and
zero or more ISP-Information AVPs to advertise the information on the zero or more ISP-Information AVPs to advertise the information on the
NAP and/or ISPs. NAP and/or ISPs.
When a PaC receives the PANA-Start-Request message in response to the When a PaC receives the PANA-Start-Request message in response to the
PANA-PAA-Discover message, it responds with a PANA-Start-Answer PANA-PAA-Discover message, it responds with a PANA-Start-Answer
message if it wishes to enter the authentication phase. The message if it wishes to enter the authentication phase. The
PANA-Start-Answer message contains the initial sequence numbers in PANA-Start-Answer message contains the initial sequence numbers in
the tseq and rseq fields of the PANA header, a copy of the received the tseq and rseq fields of the PANA header, a copy of the received
Cookie (if any) as the PANA payload. Cookie (if any) as the PANA payload.
If the S-flag of the received PANA-Start-Request message is not set, If the S-flag of the received PANA-Start-Request message is not set,
PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent
back to the PAA. In this case, PaC can indicate its choice of ISP by back to the PAA. In this case, PaC MAY indicate its choice of ISP by
including its ISP-Information AVP in the PANA-Start-Answer message. including an ISP-Information AVP in the PANA-Start-Answer message.
AAA routing will be based on the ISP choice if an ISP-Information AVP When a AAA backend is used, the identity of the destination AAA
is specified in the PANA-Start-Answer message, otherwise it will be server or realm MUST be determined based on the explicitly chosen
based on EAP identifier. ISP. When the ISP-Information AVP is not present, the access network
MAY rely on the client identifier carried in the EAP authentication
method to make this determination.
If the S-flag of the received PANA-Start-Request message is set, PaC If the S-flag of the received PANA-Start-Request message is set, PaC
can indicate its desire to perform separate EAP authentication for can indicate its desire to perform separate EAP authentication for
NAP and ISP by setting the S-flag in the PANA-Start-Answer message. NAP and ISP by setting the S-flag in the PANA-Start-Answer message.
In this case, PaC can also indicate its choice of ISP by including If the S-flag in the PANA-Start-Answer message is not set, only one
its ISP-Information AVP in the PANA-Start-Answer message. AAA authentication is performed and the processing occurs as described
routing for NAP authentication will be based on the NAP. AAA routing earlier. If the S-flag in the PANA-Start-Answer message is set, the
for ISP authentication will be based on the ISP choice if an determination of the destination AAA server or realm for ISP
ISP-Information AVP is specified in the PANA-Start-Answer message, authentication is performed as described earlier. In addition, where
otherwise it will be based on EAP identifier. If the S-flag of the backend AAA servers are used for NAP authentication, the NAP is
received PANA-Start-Request message is set and the S-flag of the considered the ultimate AAA realm, and the destination AAA server for
corresponding PANA-Start-Answer message is not set, only one EAP this authentication is determined entirely by the local configuration
authentication occurs without distinction between NAP and ISP on the access server hosting PAA (NAS).
authentications. In this case, PaC can still indicate its choice of
ISP by including its ISP-Information AVP in the PANA-Start-Answer The PaC can choose an ISP and contain an ISP-Information AVP for the
message. chosen ISP in a PANA-Start-Answer message even when there is no
ISP-Information AVP contained in the PANA-Start-Request message.
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 phase. Otherwise, it valid, the protocol enters the authentication phase. Otherwise, it
MUST silently discard the received message. MUST silently discard the received message.
When a Cookie-AVP is carried in a PANA-Start-Request message, the Initial EAP Request MAY be optionally carried by the
initial EAP Request MUST NOT be carried in the PANA-Start-Request PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
message in order for the PAA to be stateless. message in order to reduce the number of round-trips. This
optimization SHOULD NOT be used if the PAA discovery is desired to be
stateless.
When a Cookie-AVP is not carried in a PANA-Start-Request message, the When the S-flag is set in a PANA-Start-Request message, the initial
PAA does not need to be stateless. In this case, the initial EAP EAP Request MUST NOT be carried in the PANA-Start-Request message.
Request message MAY be carried in the PANA-Start-Request message. (If the initial EAP Request were contained in the PANA-Start-Request
message during the S-flag negotiation, the PaC cannot tell whether
the EAP Request is for NAP authentication or ISP authentication.)
If the initial EAP Request message is carried in the If the initial EAP Request message is carried in the
PANA-Start-Request message, an EAP Response message MUST be carried PANA-Start-Request message, an EAP Response message MUST be carried
in the PANA-Start-Answer message returned to the PAA. in the PANA-Start-Answer message returned to the PAA.
In any case, PANA MUST NOT generate an EAP message on behalf of EAP In any case, PANA MUST NOT generate an EAP message on behalf of EAP
peer or EAP (pass-through) authenticator. peer or EAP (pass-through) authenticator.
The PANA-Start-Request/Answer exchange is needed before entering The PANA-Start-Request/Answer exchange is needed before entering
authentication phase even when the PaC is pre-configured with PAAs IP authentication phase even when the PaC is pre-configured with PAAs IP
address and the PANA-PAA-Discover message is unicast. address and the PANA-PAA-Discover message is unicast.
A PANA-Start-Request message is never retransmitted. A A PANA-Start-Request message that carries a Cookie AVP is never
PANA-Start-Answer message is retransmitted based on timer in the same retransmitted. A PANA-Start-Request message that does not carry a
manner as other messages retransmitted at PANA-layer. Cookie AVP is retransmitted based on timer. A PANA-Start-Answer
message that carries a Cookie AVP is retransmitted based on timer. A
PANA-Start-Answer message that does not carry a Cookie AVP is never
retransmitted based on timer.
It is possible that both PAA and PaC initiate the discovery and It is possible that both PAA and PaC initiate the discovery and
initial handshake procedure at the same time, i.e., the PAA sends a initial handshake procedure at the same time, i.e., the PAA sends a
PANA-Start-Request message while the PaC sends a PANA-PAA-Discover PANA-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 for the has sent a PANA-Start-Request message with creating a state (i.e., no
PaC. Cookie AVP included) for the PaC. In this case PAA will retransmit
PANA-Start-Request based on a timer, if PaC doesn't respond in time
(message was lost for example). If PAA had sent stateless
PANA-Start-Request message (i.e., a Cookie AVP was included), then it
SHOULD answer to the PANA-PAA-Discover message.
PaC PAA Message PaC PAA Message
------------------------------------------------------ ------------------------------------------------------
-----> PANA-PAA-Discover(0,0) -----> PANA-PAA-Discover(0,0)
<----- PANA-Start-Request(x,0)[Cookie] <----- PANA-Start-Request(x,0)[Cookie]
-----> PANA-Start-Answer(y,x)[Cookie] -----> PANA-Start-Answer(y,x)[Cookie]
(continued to authentication phase) (continued to authentication phase)
Figure 2: Example Sequence for Discovery and Initial Handshake Phase Figure 2: Example Sequence for Discovery and Initial Handshake Phase
when PANA-PAA-Discover is sent by PaC when PANA-PAA-Discover is sent by PaC
PaC EP PAA Message PaC EP PAA Message
------------------------------------------------------ ------------------------------------------------------
---->o (Data packet arrival or L2 trigger) ---->o (Data packet arrival or L2 trigger)
------> PANA-PAA-Discover(0,0)[Device-Id] ------> PAA-to-EP protocol, or another mechanism
<------------ PANA-Start-Request(x,0)[ Cookie] <------------ PANA-Start-Request(x,0)[ Cookie]
------------> PANA-Start-Answer(y,x)[ Cookie] ------------> PANA-Start-Answer(y,x)[ Cookie]
(continued to authentication phase) (continued to authentication phase)
Figure 3: Example Sequence for Discovery and Initial Handshake when Figure 3: Example Sequence for Discovery and Initial Handshake when
PANA-PAA-Discover is sent by EP discovery is triggered by data traffic
4.3 Authentication Phase 4.3 Authentication Phase
The main task in authentication phase is to carry EAP messages The main task in authentication phase is to carry EAP messages
between PaC and PAA. All EAP messages except for EAP Success/Failure between PaC and PAA. EAP Request messages are carried in PANA-
messages are carried in the PANA-Auth-Request/PANA-Auth-Answer Auth-Request messages and optionally carried in PANA-Start-Request
messages. When an EAP Success/Failure message is sent from a PAA, messages. EAP Response messages are carried in PANA-Auth-Answer
the message is carried in the PANA-Bind-Request message. The PANA- messages and optionally carried in PANA-Start-Answer messages. When
Bind-Request message is acknowledged with a PANA-Bind-Answer. It is an EAP Success/Failure message is sent from a PAA, the message is
possible to carry multiple EAP sequences in a single PANA session. carried in a PANA-Bind-Request (PBR) or PANA-FirstAuth-End-Request
(PFER) message. The PANA-FirstAuth-End-Reques message MUST be used
at the end of the first EAP when the PaC and PAA have negotiated
during the discovery and initial handshake phase to perform separate
NAP and ISP authentications in a single PANA authentication phase.
Otherwise, the PANA-Bind-Request message MUST be used. The
PANA-Bind-Request and PANA-FirstAuth-End-Request messages MUST be
acknowledged with a PANA-Bind-Answer (PBA) and a
PANA-FirstAuth-End-Answer (PFEA) messages, respectively.
When PaC and PAA negotiated during the discovery and initial When the PaC and PAA have negotiated during the discovery and initial
handshake phase to perform separate NAP and ISP authentications in a handshake phase to perform separate NAP and ISP authentications, the
single PANA session, the PAA determines the execution order of NAP S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST be
authentication and ISP authentication. In this case, the PAA can set. Otherwise, the S-flag MUST NOT be set.
indicate which EAP authentication is currently occurring by including
a NAP-Information or an ISP-Information AVP of the corresponding EAP When separate NAP and ISP authentications are performed, the PAA
authentication in the first PANA-Auth-Request message sent to the determines the execution order of NAP authentication and ISP
PaC. In the case where the PaC agreed to perform separate authentication. In this case, the PAA can indicate which EAP
authentications but did not specify its ISP choice in authentication is currently occurring by using N-flag in the PANA
PANA-Start-Answer message, the PAA MUST include its NAP-Information message header. When NAP authentication is performed, the N-flag
AVP in PANA-Auth-Request message when it performs NAP authentication MUST be set. When ISP authentication is performed, the N-flag MUST
and MUST NOT include any service provider information AVP when it NOT be set. The N-flag MUST NOT be set when S-flag is not set.
performs ISP authentication so that the PaC can always distinguish
ISP authentication from NAP authentication. The PAA SHOULD stop When separate NAP and ISP authentications are performed, if the first
including a NAP-Information or an ISP-Information AVP once it EAP authentication has failed, the PAA can choose not to perform the
receives the first PANA-Auth-Answer message of the current EAP second EAP authentication by clearing the S-flag of the
authentication. PANA-FirstAuth-End-Request message. In this case, the S-flag 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 is set when
the first EAP authentication has failed, the PaC can choose not to
perform the second EAP authentication by clearing 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 PANA-FirstAuth-End-Answer
message as a result of those operations, the PANA session MUST be
immediately deleted. Otherwise, the second EAP authentication MUST be
performed.
Currently, use of multiple EAP methods in PANA is designed only for Currently, use of multiple EAP methods in PANA is designed only for
NAP-ISP authentication separation. It is not for arbitrary EAP NAP-ISP authentication separation. It is not for arbitrary EAP
method sequencing, or giving the PaC another chance when an method sequencing, or giving the PaC another chance when an
authentication method fails. The NAP and ISP authentication are authentication method fails. The NAP and ISP authentication are
considered completely independent. Presence or success of one should considered completely independent. Presence or success of one should
not effect the other. Making an authentication decision based on the not effect the other. Making a network access authorization decision
success or failure of each authentication is a network policy issue. based on the success or failure of each authentication is a network
PANA signals only the result of the immediately preceding EAP policy issue.
authentication method in PANA-Bind-Request messages.
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 phase and the keys are successfully derived the the authentication phase and the keys are successfully derived, the
PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or
PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent
PANA-Bind-Answer message exchange is also used for binding device PANA messages MUST contain a MAC AVP.
identifiers of the PaC and the PAA to the PANA SA. To achieve this,
the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a When separate NAP and ISP authentications are performed and the
device identifier of the PAA and the PaC, respectively, in a lower-layer is insecure, the two EAP methods MUST be capable of
Device-Id AVP. The PaC MUST use the same type of device identifier deriving keys. In this case, if the first EAP authentication is
as contained in the PANA-Bind-Request message. The PANA-Bind-Request successful, the PANA-FirstAuth-End-Request and
message MAY also contain a Protection-Capability AVP to indicate if PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and
link-layer or network-layer ciphering should be initiated after PANA. PANA-Auth-Answer messages in the second EAP authentication MUST be
No link layer or network layer specific information is included in protected with the key derived from the AAA-Key for the first EAP
the Protection-Capability AVP. When the information is preconfigured authentication. The PANA-Bind-Request and PANA-Bind-Answer messages
on the PaC and the PAA this AVP can be omitted. It is assumed that at and all subsequent PANA messages MUST be protected either with the
least PAA is aware of the security capabilities of the access AAA-Key for the first EAP authentication if the first EAP
network. The PANA protocol does not specify how the PANA SA and the authentication succeeds and the second EAP authentication fails, or
Protection-Capability AVP will be used to provide per-packet with the AAA-Key for the second EAP authentication if the first EAP
protection for data traffic. authentication fails and the second EAP authentication succeeds, or
with the compound key 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 second EAP authentications
succeed (see Section 4.1.5 for how the compound key is derived).
The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
also used for binding device identifiers of the PaC and the PAA to
the PANA SA when the identifiers are either IP or MAC addresses. To
achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD
contain a device identifier of the PAA and the PaC, respectively, in
a Device-Id AVP. Device identifier exchange that is protected by a
MAC AVP prevents man-in-the-middle attacks. The PaC MUST use the
same type of device identifier as contained in the PANA-Bind-Request
message. 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. When the information is preconfigured on the PaC and the PAA
this AVP can be omitted. It is assumed that at least 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, PANA-Bind-Request MUST include a
Post-PANA-Address-Configuration AVP, which helps PAA to inform PaC
about whether a new IP address MUST be configured and the available
methods to do so. 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 methods available on the PaC. When there
is no match, a PPAC AVP MUST NOT be included and the Result-Code AVP
MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the
PANA-Bind-Answer message.
PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted
based on the retransmission rule described in Appendix A. based on the retransmission rule described in Section 4.1.4.
EAP authentication can fail at a pass-through authenticator without
sending an EAP-Failure message [I-D.ietf-eap-statemachine]. When
this occurs, the PAA SHOULD send a PANA-Error message to the PaC with
using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD ignore the
message unless it is secured by PANA or lower layer. In any case, a
more appropriate way is to rely on a timeout on the PaC.
There is a case where EAP authentication succeeds with producing an
EAP-Success message but network access authorization fails due to,
e.g., authorization rejected by a AAA proxy or authorization locally
rejected by a PAA. When this occurs, the PAA MUST send
PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If
a AAA-Key is established between PaC and PAA by the time when the
EAP-Success is generated by the EAP server (this is the case when the
EAP method provides protected success indication), the this PANA-Bind
message exchange MUST be protected with a MAC AVP and with carrying a
Key-Id AVP. The AAA-Key and the PANA session MUST be deleted after
the PANA-Bind message exchange.
PaC PAA Message(tseq,rseq)[AVPs] PaC PAA Message(tseq,rseq)[AVPs]
------------------------------------------------- -------------------------------------------------
(continued from discovery and initial handshake phase) (continued from discovery and initial handshake phase)
<----- PANA-Auth-Request(x+1,y)[EAP{Request}] <----- PANA-Auth-Request(x+1,y)[EAP{Request}]
-----> PANA-Auth-Answer(y+1,x+1)[EAP{Response}] -----> PANA-Auth-Answer(y+1,x+1)[EAP{Response}]
. .
. .
<----- PANA-Auth-Request (x+2,y+1)[EAP{Request}] <----- PANA-Auth-Request (x+2,y+1)[EAP{Request}]
-----> PANA-Auth-Answer (y+2,x+2)[EAP{Response}] -----> PANA-Auth-Answer (y+2,x+2)[EAP{Response}]
<----- PANA-Bind-Request(x+3,y+2) <----- PANA-Bind-Request(x+3,y+2)
[EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] [EAP{Success}, Device-Id, Lifetime, Protection-Cap.,
-----> PANA-Bind-Answer(y+3,x+3) PPAC, MAC]
[Device-Id, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3)[Device-Id, PPAC, MAC]
Figure 4: Example Sequence in Authentication Phase Figure 4: Example Sequence in Authentication Phase
4.4 Re-authentication 4.4 Re-authentication
There are two types of re-authentication supported by PANA. There are two types of re-authentication supported by PANA.
The first type of re-authentication is based on EAP by entering an The first type of re-authentication is based on EAP by entering an
authentication phase. In this case, some or all message exchanges authentication phase. In this case, some or all message exchanges
for discovery and initial handshake phase MAY be omitted in the for discovery and initial handshake phase MAY be omitted in the
  Skipping to change at page 19, line 43:
it sends a PANA-Auth-Request message containing the same identifier it sends a PANA-Auth-Request message containing the same identifier
to start an authentication phase. If the PAA can not recognize the to start an authentication phase. If the PAA can not recognize the
session identifier, it proceeds with regular authentication by session identifier, it proceeds with regular authentication by
sending back PANA-Start-Request. When the PAA initiates EAP-based sending back PANA-Start-Request. When the PAA initiates EAP-based
re-authentication, it sends a PANA-Auth-Request message containing re-authentication, it sends a PANA-Auth-Request message containing
the session identifier for the PaC to enter an authentication phase. the session identifier for the PaC to enter an authentication phase.
PAA SHOULD initiate EAP authentication before the current session PAA SHOULD initiate EAP authentication before the current session
lifetime expires. In both cases, the tseq and rseq values are lifetime expires. In both cases, the tseq and rseq values are
inherited from the previous (re-)authentication. For any EAP-based inherited from the previous (re-)authentication. For any EAP-based
re-authentication, if there is an established PANA SA, re-authentication, if there is an established PANA SA,
PANA-Auth-Request and PANA-Auth-Answer messages SHOULD be protected PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by
by adding a MAC AVP to each message. adding a MAC AVP to each message.
The second type of re-authentication is based on a single protected The second type of re-authentication is based on a single protected
message exchange without entering the authentication phase. message exchange without entering the authentication phase.
PANA-Reauth-Request and PANA-Reauth-Answer messages are used for this PANA-Reauth-Request and PANA-Reauth-Answer messages are used for this
purpose. If there is an established PANA SA, both the PaC and the purpose. If there is an established PANA SA, both the PaC and the
PAA are allowed to send a PANA-Reauth-Request message to the PAA are allowed to send a PANA-Reauth-Request message to the
communicating peer whenever it needs to make sure the availability of communicating peer whenever it needs to make sure the availability of
the PANA SA on the peer and expect the peer to return a PANA- the PANA SA on the peer and expect the peer to return a PANA-
Reauth-Answer message. Both PANA-Reauth-Request/ PANA-Reauth-Answer Reauth-Answer message. Both PANA-Reauth-Request/ PANA-Reauth-Answer
messages MUST be protected with a MAC AVP. messages MUST be protected with a MAC AVP.
Implementations MUST limit the rate of performing re-authentication Implementations MUST limit the rate of performing re-authentication
for both types of re-authentication. for both types of re-authentication. The PaC and the PAA can handle
rate limitation on their own, they don't have to perform any
coordination with each other. There is no negotiation of timers for
this purpose.
PaC PAA Message(tseq,rseq)[AVPs] PaC PAA Message(tseq,rseq)[AVPs]
------------------------------------------------------ ------------------------------------------------------
-----> PANA-Reauth-Request(q,p)[MAC] -----> PANA-Reauth-Request(q,p)[MAC]
<----- PANA-Reauth-Answer(p+1,q)[MAC] <----- PANA-Reauth-Answer(p+1,q)[MAC]
Figure 5: Example Sequence for PaC-initiated second type Figure 5: Example Sequence for PaC-initiated second type
Re-authentication Re-authentication
PaC PAA Message(tseq,rseq)[AVPs] PaC PAA Message(tseq,rseq)[AVPs]
  Skipping to change at page 20, line 36:
4.5 Termination Phase 4.5 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 PaC (i.e., disconnect indication) or from PAA initiated either from PaC (i.e., disconnect indication) or from PAA
(i.e., session revocation). The PANA-Termination-Request and the (i.e., session revocation). The PANA-Termination-Request and the
PANA-Termination-Answer message exchanges are used for disconnect PANA-Termination-Answer message exchanges are used for disconnect
indication and session revocation procedures. indication and session revocation procedures.
The reason for termination is indicated in the Termination-Cause AVP. The reason for termination is indicated in the Termination-Cause AVP.
When there is an established PANA SA established between the PaC and When there is an established PANA SA established between the PaC and
the PAA, all messages exchanged during the termination phase MUST be the PAA, all messages exchanged during the termination phase MUST be
protected with a MAC AVP. When the sender of the PANA- protected with a MAC AVP. When the sender of the
Termination-Request receives a valid acknowledgment, all states PANA-Termination-Request receives a valid acknowledgment, all states
maintained for the PANA session MUST be deleted immediately. maintained for the PANA session MUST be deleted immediately.
PaC PAA Message(tseq,rseq)[AVPs] PaC PAA Message(tseq,rseq)[AVPs]
------------------------------------------------------ ------------------------------------------------------
-----> PANA-Termination-Request(q,p)[MAC] -----> PANA-Termination-Request(q,p)[MAC]
<----- PANA-Termination-Answer(p+1,q)[MAC] <----- PANA-Termination-Answer(p+1,q)[MAC]
Figure 7: Example Sequence for Session Termination Figure 7: Example Sequence for Session Termination
4.6 Illustration of a Complete Message Sequence 4.6 Illustration of a Complete Message Sequence
A complete PANA message sequence is illustrated in Figure 8. The A complete PANA message sequence is illustrated in Figure 8. The
example assumes the following scenario: example assumes the following scenario:
o PaC multicasts PANA-PAA-Discover message o PaC multicasts PANA-PAA-Discover message
o The ISNs used by the PAA and the PaC are x and y, respectively. o The ISNs used by the PAA and the PaC are x and y, respectively.
  Skipping to change at page 21, line 47:
<----- PANA-Start-Request (x,0)[Cookie] <----- PANA-Start-Request (x,0)[Cookie]
-----> PANA-Start-Request-Answer (y,x)[Cookie] -----> PANA-Start-Request-Answer (y,x)[Cookie]
// Authentication phase // Authentication phase
<----- PANA-Auth-Request(x+1,y)[EAP] <----- PANA-Auth-Request(x+1,y)[EAP]
-----> PANA-Auth-Answer(y+1,x+1)[EAP] -----> PANA-Auth-Answer(y+1,x+1)[EAP]
<----- PANA-Auth-Request(x+2,y+1)[EAP] <----- PANA-Auth-Request(x+2,y+1)[EAP]
-----> PANA-Auth-Answer(y+2,x+2)[EAP] -----> PANA-Auth-Answer(y+2,x+2)[EAP]
<----- PANA-Bind-Request(x+3,y+2) <----- PANA-Bind-Request(x+3,y+2)
[EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC]
-----> PANA-Bind-Answer(y+3,x+3) -----> PANA-Bind-Answer(y+3,x+3)[Device-Id, MAC]
[Device-Id, Protection-Cap., MAC]
// Re-authentication // Re-authentication
<----- PANA-Reauth-Request (x+4,y+3)[MAC] <----- PANA-Reauth-Request (x+4,y+3)[MAC]
-----> PANA-Reauth-Answer (y+4,x+4)[MAC] -----> PANA-Reauth-Answer (y+4,x+4)[MAC]
// Termination phase // Termination phase
-----> PANA-Termination-Request(y+5,x+4)[MAC] -----> PANA-Termination-Request(y+5,x+4)[MAC]
<----- PANA-Termination-Answer (x+5,y+5)[MAC] <----- PANA-Termination-Answer (x+5,y+5)[MAC]
Figure 8: A Complete Message Sequence Figure 8: A Complete Message Sequence
Another PANA message sequence is illustrated in Figure 9. The example
assumes the following scenario:
o PaC multicasts PANA-PAA-Discover message
o The ISNs used by the PAA and the PaC are x and y, respectively.
o PAA offers NAP and ISP separate authentication, as well as a
choice of ISP from "ISP1" and "ISP2". PaC accepts the offer from
PAA, with choosing "ISP1" as the ISP.
o An EAP sequence for NAP authentication and an EAP sequence for ISP
authentication is performed in this order in authentication phase.
o An EAP authentication method with a single round trip is used in
the EAP sequence.
o The EAP authentication methods derive keys. Once the two EAP
authenticatioins are successful, the PANA_MAC_KEY is derived from
the two AAA-Keys.
o After PANA SA is established, all messages are integrity and
replay protected with the MAC AVP.
o Re-authentication based on the PANA-Reauth-Request/ PANA-Reauth-
Answer exchange is performed.
o Re-authentication and termination phase are not shown.
PaC PAA Message(tseq,rseq)[AVPs]
-----------------------------------------------------
// Discovery and initial handshake phase
-----> PANA-PAA-Discover (0,0)
<----- PANA-Start-Request (x,0) // S-flag set
[Cookie, ISP-Information("ISP1"),
ISP-Information("ISP2"),
NAP-Information("MyNAP")]
-----> PANA-Start-Request-Answer (y,x) // S-flag set
[Cookie, ISP-Information("ISP1")] // PaC chooses "ISP1"
// Authentication phase
<----- PANA-Auth-Request(x+1,y)[EAP] // NAP authentication
// S- and N-flags set
-----> PANA-Auth-Answer(y+1,x+1)[EAP] // S- and N-flags set
<----- PANA-Auth-Request(x+2,y+1)[EAP] // S- and N-flags set
-----> PANA-Auth-Answer(y+2,x+2)[EAP] // S- and N-flags set
<----- PANA-FirstAuth-End-Request(x+3,y+2) // S- and N-flags set
[EAP{Success}, Key-Id, MAC]
-----> PANA-FirstAuth-End-Answer(y+3,x+3) // S- and N-flags set
[Key-Id, MAC]
<----- PANA-Auth-Request(x+3,y+4)[EAP, MAC]// ISP authentication
// S-flag set
-----> PANA-Auth-Answer(y+4,x+4)[EAP, MAC] // S-flag set
<----- PANA-Auth-Request(x+4,y+5)[EAP, MAC]// S-flag set
-----> PANA-Auth-Answer(y+5,x+5)[EAP, MAC] // S-flag set
<----- PANA-Bind-Request(x+5,y+6) // S-flag set
[EAP{Success}, Device-Id, Key-Id,
Lifetime, Protection-Cap., PPAC, MAC]
-----> PANA-Bind-Answer(y+6,x+5) // S-flag set
[Device-Id, Key-Id, PPAC, MAC]
Figure 9: A Complete Message Sequence for NAP and ISP Separate
Authentications
4.7 Device ID Choice 4.7 Device ID Choice
A PaC SHOULD configure an IP address before PANA if it can. It might The device identifiers used in the context of PANA can be an IP
either have a pre-configured IP address, or have to obtain one via address, a MAC address, or an identifier that is not carried on data
dynamic methods such as DHCP or stateless address autoconfiguration. packets but has local significance in identifying a connected host
Dynamic methods may or may not succeed depending on the local (e.g., circuit ID). The last type of identifiers are commonly used
security policy. In networks where clients have to be authorized in physically secured point-to-point links where MAC addresses are
before they are allowed to obtain an IP address, EPs will detect the not available.
associated activity and PANA protocol will be engaged before the
clients can configure a valid IP address.
Either an IP address or a link-layer address SHOULD be used as device It is assumed that PAA knows the link type and the security
ID at any time. It is assumed that PAA knows the security mechanisms mechanisms being provided or required on the access network (e.g.,
being provided or required on the access network (e.g., based on based on physical security, link-layer ciphers enabled before or
physical security, link-layer ciphers enabled before or after PANA, after PANA, or IPsec). Based on that information, the PAA can decide
or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the what type of device ID will be used when running PANA with the
choice of access control, PAA SHOULD provide its IP address as device client. When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the
ID, and expect the PaC to provide its IP address in return. In all choice of access control, PAA SHOULD provide an IP address as device
other cases, link-layer addresses can be provided from both sides. ID, and expect the PaC to provide its IP address in return. In case
IPsec is not used, MAC addresses are used as device IDs when
available. If non-IPsec access control is enabled, and a MAC address
is not available, device ID exchange does not occur within PANA.
Instead, peers rely on lower-layers to provide locally-significant
identifiers along with received PANA packets.
4.8 Session Lifetime 4.8 Session Lifetime
The authentication phase determines the PANA session lifetime when The authentication phase determines the PANA session lifetime when
the network access authorization succeeds. The Session-Lifetime AVP the network access authorization succeeds. The Session-Lifetime AVP
MAY be optionally included in the PANA-Bind-Request message to inform MAY be optionally included in the PANA-Bind-Request message to inform
PaC about the valid lifetime of the PANA session. It MUST be ignored PaC about the valid lifetime of the PANA session. It MUST be ignored
when included in other PANA messages. When there are multiple EAP when included in other PANA messages. When there are multiple EAP
authentication taking place, this AVP SHOULD be included after the authentication taking place, this AVP SHOULD be included after the
final authentication. final authentication.
The lifetime is a non-negotiable parameter that can be used by PaC to The lifetime is a non-negotiable parameter that can be used by PaC to
manage PANA-related state. PaC does not have to perform any actions manage PANA-related state. PaC does not have to perform any actions
when the lifetime expires, other than optionally purging local state. when the lifetime expires, other than optionally purging local state.
PAA SHOULD initiate EAP authentication before the current session PAA SHOULD initiate EAP authentication before the current session
lifetime expires. lifetime expires.
PaC and PAA MAY optionally rely on lower-layer indications to 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
reliability of such indications depend on the specific access reliability of such indications depend on the specific access
technologies. PANA peer can use PANA-Reauth-Request message to verify technologies. PANA peer can use PANA-Reauth-Request message to
the disconnection before taking an action. verify the disconnection before taking an action.
The session lifetime parameter is not related to the transmission of The session lifetime parameter is not related to the transmission of
PANA-Reauth-Request messages. These messages can be used for PANA-Reauth-Request messages. These messages can be used for
asynchronously verifying the liveness of the peer and enabling asynchronously verifying the liveness of the peer and enabling
mobility optimizations. The decision to send PANA-Reauth-Request mobility optimizations. The decision to send PANA-Reauth-Request
message is taken locally and does not require coordination between message is taken locally and does not require coordination between
the peers. the peers.
When separate EAP authentications are performed for ISP and NAP in a When separate EAP authentications are performed for ISP and NAP in a
single PANA session, it is possible that different authorization single PANA session, it is possible that different authorization
lifetime values are associated with the two authentications. In this lifetime values are associated with the two authentications. In this
case, the smaller authorization lifetime value MUST be used for case, the smaller authorization lifetime value MUST be used for
calculating the PANA Session-Lifetime value. As a result, when calculating the PANA Session-Lifetime value. As a result, when
EAP-based re-authentication occurs, both NAP and ISP authentications EAP-based re-authentication occurs, both NAP and ISP authentications
will be performed in the same re-authentication procedure. will be performed in the same re-authentication procedure.
4.9 Mobility Handling 4.9 Mobility Handling
When a PaC wants to resume an ongoing PANA session after connecting A mobile PaC's AAA performance can be enhanced by deploying a
to another link in the same access network, it MAY send the unexpired context-transfer-based mechanism, where some session attributes are
PANA session identifier in its PANA-Start-Answer message. In the transferred from the previous PAA to the current one in order to
absence of a Session-Id AVP in this message, PAA MUST assume this is avoid performing a full EAP authentication (reactive approach).
a fresh session and continue its normal execution. Additional mechanisms that are based on the proactive AAA state
establishment at one or more candidate PAAs may be developed in the
future [I-D.irtf-aaaarch-handoff]. The details of a
context-transfer-based mechanism is provided in this section.
Upon changing its point of attachment, a PaC that wants to quickly
resume its ongoing PANA session without running EAP MAY send its
unexpired PANA session identifier in its PANA-Start-Answer message.
Along with the Session-Id AVP, MAC and Nonce AVPs MUST be included in
this message. Nonce AVP carries a randomly chosen value (PaC_Nonce),
and MAC AVP is computed by using the PANA_MAC_Key shared between the
PaC and its previous PAA that has an unexpired PANA session with the
PaC. This action signals PaC's desire to perform the mobility
optimization. In the absence of Session-Id AVP in this message, PANA
session takes its usual course (i.e., EAP-based authentication is
performed).
If PAA receives a session identifier in the PANA-Start-Answer If PAA receives a session identifier in the PANA-Start-Answer
message, and it is configured to enable fast re-authentication, it message, and it is configured to enable this optimization, it SHOULD
SHOULD retrieve the PANA session attributes from the previous PAA of retrieve the PANA session attributes from the previous PAA. Current
the PaC. The mechanism required to determine the previous PAA of the PAA determines the identity of the previous PAA by looking at the
PaC by relying on the PANA session identifier is outside the scope of DiameterIdentity part of the PANA session identifier. The MAC AVP
PANA protocol. A possible solution is to embed the PAA identifier in can only be verified by the previous PAA, therefore a copy of the
the PANA session identifier. Furthermore, the mechanism required to PANA message SHOULD be provided to the previous PAA. The mechanism
retrieve the session attributes from the previous PAA is outside the required to send a copy of the PANA-Start-Answer message from current
scope of this protocol. Seamoby Context Transfer Protocol PAA to the previous PAA, and retrieve the session attributes is
[I-D.ietf-seamoby-ctp] might be useful for this purpose. outside the scope of PANA protocol. Seamoby Context Transfer
Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose.
When the PAA is not configured to enable fast re-authentication, or When the previous or current PAA is not configured to enable this
can not retrieve the PANA session attributes, or the PANA session has optimization, the current PAA can not retrieve the PANA session
already expired (i.e., session lifetime is zero), the PAA MUST send attributes, or the PANA session has already expired (i.e., session
the PANA-Auth-Request message with the new session identifier and let lifetime is zero), the PAA MUST send the PANA-Auth-Request message
the PANA exchange take its usual course. This action will engage EAP with a new session identifier and let the PANA exchange take its
authentication and create a fresh PANA session from scratch. usual course. This action will engage EAP-based authentication and
create a fresh PANA session from scratch.
In case the new PAA retrieves the on-going PANA session attributes In case the current PAA can retrieve the on-going PANA session
from the previous PAA, the PANA session continues with a PANA-Reauth attributes from the previous PAA, the PANA session continues with a
exchange. The MAC AVP contained in the PANA-Reauth messages MUST be PANA-Bind exchange.
generated and verified by using the retrieved PANA SA attributes.
This exchange MUST also include Session-Id AVP that contains the
newly assigned session identifier, and Device-Id AVP. A new PANA
session is created upon successful completion of this exchange. This
session inherits only the session lifetime, protection capability,
and AAA-Key attributes from the previous session. Other attributes
are generated based on the PANA exchanges on the new link. While
AAA-Key stays the same, a new PANA_MAC_Key is computed using the new
parameters. Subsequent MAC-AVPs are processed using this new PANA SA.
4.10 Event Notification As part of the context transfer, an intermediate AAA-Key material is
provided by the previous PAA to the current PAA.
Upon detecting the need to authenticate a client, EP can send a AAA-Key-int = The first N bits of
trigger message to the PAA on behalf of the PaC. This can be one of HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
the messages provided by the PAA-to-EP protocol, or, in the absence
of such a facility, PANA-PAA_Discover can be used as well. This
message MUST carry the device identifier of the PaC. So that, the PAA
can send the unsolicited PANA-Start-Request message directly to the
PaC. If the link between the EP and PAA is not physically secured,
this message sent from EP to PAA MUST be cryptographically protected
(e.g., by using IPsec).
4.11 Support for Separate EP In case there are two AAA-Keys generated from a NAP-ISP
authentication, the AAA-Key-int computation is:
AAA-Key-int = The first N bits of
HMAC-SHA1(AAA-Key1 | AAA-Key2, DiameterIdentity |
Session-ID)
The value of N depends on the integrity protection algorithm in use,
i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the
current PAA. Session-ID is the identifier of the PaC's PANA session
with the previous PAA.
The current PAA and PaC compute the new AAA-Key by using the nonce
values and the AAA-Key-int. PAA_Nonce is the randomly chosen value
that MUST be carried in a Nonce AVP in the PANA-Bind-Request message.
AAA-Key-new = The first N bits of
HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)
New PANA_MAC_Key is computed based on the algorithm described in
Section 4.1.5, by using the new AAA-Key and the new Session-ID
assigned by the current PAA. The MAC AVP contained in the
PANA-Bind-Request and PANA-Bind-Answer messages MUST be generated and
verified by using the new PANA_MAC_Key. The Session-ID AVP MUST
include a new session identifier assigned by the current PAA. A new
PANA session is created upon successful completion of this exchange.
Note that correct operation of this optimization relies on many
factors, including applicability of authorization state from one
network attachment to another. [I-D.ietf-eap-keying] identifies this
operation as "fast handoff" and provides deployment considerations.
Operators are recommended to take those guidelines into account when
using this optimization in their networks.
4.10 Support for Separate EP
PANA allows PAA and EP to be separate entities. In this case, if PANA allows PAA and EP to be separate entities. In this case, if
data traffic protection needs to be initiated after successful PANA data traffic protection needs to be initiated after successful PANA
authentication phase, PaC needs to know the device identifier of authentication phase, PaC needs to know the device identifier of
EP(s) so that it is able to establish a security association with EP(s) so that it is able to establish a security association with
each EP to protect data traffic. each EP to protect data traffic.
To this end, when a Protection-Capability AVP with either To this end, when a Protection-Capability AVP with either
L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a
PANA-Bind-Request message and if there is an EP that has a different PANA-Bind-Request message and if there is an EP that has a different
device identifier than that of the PAA, one or more EP-Device-Id AVPs device identifier than that of the PAA, one or more EP-Device-Id AVPs
MUST also be carried in the PANA-Bind-Request message. In this case, MUST also be carried in the PANA-Bind-Request message. In this case,
if one EP has the same device identifier as the PAA, an EP-Device-Id if one EP has the same device identifier as the PAA, an EP-Device-Id
AVP that contains the device identifier of the EP (i.e., the PAA) AVP that contains the device identifier of the EP (i.e., the PAA)
MUST also be included in the PANA-Bind-Request. MUST also be included in the PANA-Bind-Request.
Aside from provisioning EP, the same PAA-to-EP protocol MAY be used
for triggering the PAA upon detecting the need to authenticate a new
client.
5. PANA Security Association Establishment 5. PANA Security Association Establishment
When PANA is used over an already established secure channel, such as When PANA is used over an already established secure channel, such as
physically secured wires or ciphered link-layers, we can reasonably physically secured wires or ciphered link-layers, we can reasonably
assume that man-in-the-middle attack or service theft is not possible assume that man-in-the-middle attack or service theft is not possible
[I-D.ietf-pana-threats-eval]. [I-D.ietf-pana-threats-eval].
Anywhere else where there is no secure channel prior to PANA, the Anywhere else where there is no secure channel prior to PANA, the
protocol needs to protect itself against such attacks. The device protocol needs to protect itself against such attacks. The device
identifier that is used during the authentication needs to be identifier that is used during the authentication needs to be
verified at the end of the authentication to prevent service theft verified at the end of the authentication to prevent service theft
and DoS attacks. Additionally, a free loader should be prevented from and DoS attacks. Additionally, a free loader should be prevented
spoofing data packets by using the device identifier of an already from spoofing data packets by using the device identifier of an
authorized legitimate client. Both of these requirements necessitate already authorized legitimate client. Both of these requirements
generation of a security association between the PaC and the PAA at necessitate generation of a security association between the PaC and
the end of the authentication. This can only be done when the the PAA at the end of the authentication. This can only be done when
authentication method used can generate cryptographic keys. Use of the authentication method used can generate cryptographic keys. Use
secret keys can prevent attacks which would otherwise be very easy to of secret keys can prevent attacks which would otherwise be very easy
launch by eavesdropping on and spoofing traffic over an insecure to launch by eavesdropping on and spoofing traffic over an insecure
link. link.
PANA relies on EAP and the EAP methods to provide a session key in PANA relies on EAP and the EAP methods to provide a session key in
order to establish a PANA security association. An example of such a order to establish a PANA security association. An example of such a
method is EAP-TLS [RFC2716], whereas EAP-MD5 method is EAP-TLS [RFC2716], whereas EAP-MD5
[I-D.ietf-eap-rfc2284bis] is an example of a method that cannot [I-D.ietf-eap-rfc2284bis] is an example of a method that cannot
create such keying material. The choice of EAP method becomes create such keying material. The choice of EAP method becomes
important, as discussed in the next section. important, as discussed in the next section.
This keying material is already used within PANA during the final This keying material is already used within PANA during the final
handshake. This handshake ensures that the device identifier that is handshake. This handshake ensures that the device identifier that is
bound to the PaC at the end of the authentication process is not bound to the PaC at the end of the authentication process is not
coming from a man-in-the-middle, but from the legitimate PaC. coming from a man-in-the-middle, but from the legitimate PaC.
Knowledge of the same keying material on both PaC and the PAA helps Knowledge of the same keying material on both PaC and the PAA helps
prove this. The other use of the keying material will be discussed in prove this. The other use of the keying material is discussed in
Section 7 and Section 8. [I-D.ietf-pana-framework].
6. Authentication Method Choice
Authentication methods' capabilities and therefore applicability to
various environments differ among them. Not all methods provide
support for mutual authentication, key derivation or distribution,
and DoS attack resiliency that are necessary for operating in
insecure networks. Such networks might be susceptible to
eavesdropping and spoofing, therefore a stronger authentication
method needs to be used to prevent attacks on the client and the
network.
The authentication method choice is a function of the underlying
security of the network (e.g., physically secured, shared link,
etc.). It is the responsibility of the user and the network operator
to pick the right method for authentication. PANA carries EAP
regardless of the EAP method used. It is outside the scope of PANA to
mandate, recommend, or limit use of any authentication methods. PANA
cannot increase the strength of a weak authentication method to make
it suitable for an insecure environment. There are some EAP- based
approaches to achieve this goal (see
[I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls],
[I-D.tschofenig-eap-ikev2]). PANA can carry these EAP encapsulating
methods but it does not concern itself with how they achieve
protection for the weak methods (i.e., their EAP method payloads).
7. Filter Rule Installation
PANA protocol provides client authentication and authorization
functionality for securing network access. The other component of a
complete solution is the access control which ensures that only
authenticated and authorized clients can gain access to the network.
PANA enables access control by identifying legitimate clients and
generating filtering information for access control mechanisms.
Getting this filtering information to the EPs (Enforcement Points)
and performing filtering are outside the scope of PANA.
Access control can be achieved by placing EPs in the network for
policing the traffic flow. EPs should prevent data traffic from and
to any unauthorized client unless it's PANA traffic. When a client is
authenticated and authorized, PAA should notify EP(s) and ask for
changing filtering rules to allow traffic for a recently authorized
client. There needs to be a protocol between PAA and EP(s) when these
entities are not co-located. PANA Working Group will not be defining
a new protocol for this interaction. Instead, it will (preferably)
identify one of the existing protocols that can fit the requirements.
Possible candidates include but not limited to COPS, SNMP, DIAMETER.
This task is similar to what MIDCOM Working Group is trying to
achieve, therefore some of the MIDCOM's output might be useful here.
EPs' location in the network topology should be appropriate for
performing access control functionality. The closest IP-capable
access device to the client devices is the logical choice. PAA and
EPs on an access network should be aware of each other as this is
necessary for access control. Generally this can be achieved by
manual configuration. Dynamic discovery is another possibility, but
this is clearly outside the scope of PANA.
Filtering rules generally include device identifiers for a client,
and also cryptographic keying material when needed. Such keys are
needed when attackers can eavesdrop and spoof on the device
identifiers easily. They are used with link-layer or network-layer
ciphering to provide additional protection. For issues regarding
data-origin authentication see Section 8.
8. Data Traffic Protection
Protecting data traffic of authenticated and authorized clients from
others is another component of providing a complete secure network
access solution. Authentication, integrity and replay protection of
data packets are needed to prevent spoofing when the underlying
network is not physically secured. Encryption is needed when
eavesdropping is a concern in the network.
When the network is physically secured, or the link-layer ciphering 6. Message Formats
is already enabled prior to PANA, data traffic protection is already
in place. In other cases, enabling link-layer ciphering or network-
layer ciphering might rely on PANA authentication. The user and
network have to make sure an appropriate EAP method that can generate
required keying materials is used. Once the keying material is
available, it needs to be provided to the EP(s) for use with
ciphering.
Network-layer ciphering, i.e., IPsec, can be used when data traffic This section defines message formats for PANA protocol.
protection is required but link-layer ciphering capability is not
available. Note that a simple shared secret generated by an EAP
method is not readily usable by IPsec for authentication and
encryption of IP packets. Fresh and unique session key derived from
the EAP method is still insufficient to produce an IPsec SA since
both traffic selectors and other IPsec SA parameters are missing.
The shared secret can be used in conjunction with a key management
protocol like IKE [RFC2409] to turn a simple shared secret into the
required IPsec SA. The details of such mechanisms are outside the
scope of this document and can be found in [I-D.ietf-pana-ipsec].
Using network-layer ciphers should be regarded as a substitute for 6.1 IP and UDP Headers
link-layer ciphers when the latter is not available. IKE involves
several message exchanges which can incur additional delay and header
overhead in getting basic IP connectivity for a mobile device. Such a
latency is inevitable when there is no other alternative and this
level of protection is required. Network-layer ciphering can also be
used in addition to link-layer ciphering if the added benefits
outweigh its cost to the user and the network.
9. Message Formats 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
of the message is set to a well-known link-local multicast address
(TBD). A PANA-PAA-Discover message MAY be unicast in some cases as
specified in Section 4.2. Any other PANA packet is unicasted between
the PaC and the PAA. The source and destination addresses SHOULD be
set to the addresses on the interfaces from which the message will be
sent and received, respectively.
This section defines message formats for PANA protocol. When the PANA packet is sent in response to a request, the UDP source
and destination ports of the response packet MUST be copied from the
destination and source ports of the request packet, respectively.
The destination port of an unsolicited PANA packet MUST be set to an
assigned value (TBD), and the source port MUST be set to a value
chosen by the sender.
9.1 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 | Message Length | | Version | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Message Type | | Flags | Message Type |
  Skipping to change at page 29, line 43:
The Message Length field is three octets and indicates the length The Message Length field is three octets and indicates the length
of the PANA message including the header fields. of the PANA message including the header fields.
Flags Flags
The Flags field is eight bits. The following bits are assigned: The Flags field is eight bits. The following bits are assigned:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R r r r S r r r| |R r r r S N r r|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
R(equest) R(equest)
If set, the message is a request. If cleared, the message is an If set, the message is a request. If cleared, the message is
answer. an answer.
S(eparate) S(eparate)
When the S-flag is set in a PANA-Start-Request message it When the S-flag is set in a PANA-Start-Request message it
indicates that PAA is willing to offer separate EAP indicates that PAA is willing to offer separate EAP
authentication for NAP and ISP. When the S-flag is set in a authentications for NAP and ISP. When the S-flag is set in a
PANA-Start-Answer message it indicates that PaC accepts on PANA-Start-Answer message it indicates that PaC accepts on
performing separate EAP authentication for NAP and ISP. performing separate EAP authentications for NAP and ISP. When
the S-flag is set in a PANA-Auth-Request/Answer,
PANA-FirstAuth-End-Request/Answer and PANA-Bind-Request/Answer
messages it indicates that separate authentications are being
performed in the authentication phase.
N(AP authentication)
When the N-flag is set in a PANA-Auth-Request message, it
indicates that PAA is performing NAP authentication. When the
N-flag is unset in a PANA-Auth-Request message, it indicates
that PAA is performing ISP authentication. The N-flag MUST NOT
be set when 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.
Message Type Message Type
The Message Type field is three octets, and is used in order to The Message Type field is three octets, and is used in order to
communicate the message type with the message. The 24-bit address communicate the message type with the message. The 24-bit address
space is managed by IANA [ianaweb]. PANA uses its own address space is managed by IANA [ianaweb]. PANA uses its own address
space for this field. space for this field.
Transmitted Sequence Number Transmitted Sequence Number
The Transmitted Sequence Number field contains the monotonically The Transmitted Sequence Number field contains the monotonically
increasing 32 bit sequence number that the message sender increasing 32 bit sequence number that the message sender
increments every time a new PANA message is sent. increments every time a new PANA message is sent.
  Skipping to change at page 30, line 40:
Received Sequence Number Received Sequence Number
The Received Sequence Number field contains the 32 bit transmitted The Received Sequence Number field contains the 32 bit transmitted
sequence number that the message sender has last received from its sequence number that the message sender has last received from its
peer. peer.
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 9.2 for more information on PANA message. See section Section 6.3 for more information on
AVPs. AVPs.
9.2 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-valued bytes are added to the end of the AVP Data field till a zero-valued bytes are added to the end of the AVP Data field till a
word boundary is reached. The length of the padding is not reflected word boundary is reached. The length of the padding is not reflected
in the AVP Length field [RFC3588]. in the AVP Length field [RFC3588].
The fields in the AVP header MUST be sent in network byte order. The The fields in the AVP header MUST be sent in network byte order. The
format of the header is: format of the header is:
  Skipping to change at page 32, line 25:
uniquely assigned id value, encoded in network byte order. Any uniquely assigned id value, encoded in network byte order. Any
vendor wishing to implement a vendor-specific PANA AVP MUST use vendor wishing to implement a vendor-specific PANA AVP MUST use
their own Vendor-Id along with their privately managed AVP address their own Vendor-Id along with their privately managed AVP address
space, guaranteeing that they will not collide with any other space, guaranteeing that they will not collide with any other
vendor's vendor-specific AVP(s), nor with future IETF vendor's vendor-specific AVP(s), nor with future IETF
applications. applications.
Data Data
The Data field is zero or more octets and contains information The Data field is zero or more octets and contains information
specific to the Attribute. The format and length of the Data field specific to the Attribute. The format and length of the Data
is determined by the AVP Code and AVP Length fields. field is determined by the AVP Code and AVP Length fields.
9.3 PANA Messages 6.4 PANA Messages
Figure 9 lists all PANA messages defined in this document Figure 10 lists all PANA messages defined in this document
Message Direction: PaC---PAA Message Direction: PaC---PAA
---------------------------------- ----------------------------------------
PANA-PAA-Discover --------> PANA-PAA-Discover -------->
PANA-Start-Request <-------- PANA-Start-Request <--------
PANA-Start-Answer --------> PANA-Start-Answer -------->
PANA-Auth-Request <-------- PANA-Auth-Request <--------
PANA-Auth-Answer --------> PANA-Auth-Answer -------->
PANA-FirstAuth-End-Request <--------
PANA-FirstAuth-End-Answer -------->
PANA-Bind-Request <-------- PANA-Bind-Request <--------
PANA-Bind-Answer --------> PANA-Bind-Answer -------->
PANA-Reauth-Request <-------> PANA-Reauth-Request <------->
PANA-Reauth-Answer <-------> PANA-Reauth-Answer <------->
PANA-Termination-Request <-------> PANA-Termination-Request <------->
PANA-Termination-Answer <-------> PANA-Termination-Answer <------->
PANA-Error <-------> PANA-Error <------->
Figure 9: PANA Message Overview
Additionally the EP can also send a PANA-PAA-Discover message to the Figure 10: PANA Message Overview
PAA.
9.3.1 Message Specifications 6.4.1 Message Specifications
Every PANA message MUST include a corresponding ABNF [RFC2234] Every PANA message MUST include a corresponding ABNF [RFC2234]
specification found in [RFC3588]. Note that PANA messages have a specification found in [RFC3588]. Note that PANA messages have a
different header format compared to Diameter. different header format compared to Diameter.
Example: Example:
message ::= < PANA-Header: <Message type>, [REQ] [SEP] > message ::= < PANA-Header: <Message type>, [REQ] [SEP] >
* [ AVP ] * [ AVP ]
9.3.2 PANA-PAA-Discover (PDI) 6.4.2 PANA-PAA-Discover (PDI)
The PANA-PAA-Discover (PDI) message is used to discover the address The PANA-PAA-Discover (PDI) message is used to discover the address
of PAA(s). Both sequence numbers in this message are set to zero (0). of PAA(s). Both sequence numbers in this message are set to zero
If the EP detects a new PaC and sends the PANA-PAA-Discover to the (0).
PAA, it MUST include the Device-Id of the PaC.
PANA-PAA-Discover ::= < PANA-Header: 1 > PANA-PAA-Discover ::= < PANA-Header: 1 >
0*1 < Device-Id >
0*1 < Session-Id > 0*1 < Session-Id >
* [ AVP ] * [ AVP ]
9.3.3 PANA-Start-Request (PSR) 6.4.3 PANA-Start-Request (PSR)
PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets
the transmission sequence number to an initial random value. The the transmission sequence number to an initial random value. The
received sequence number is set to zero (0). received sequence number is set to zero (0).
PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] >
[ Cookie ] [ Cookie ]
[ EAP-Payload ] [ EAP-Payload ]
[ NAP-Information ] [ NAP-Information ]
* [ ISP-Information ] * [ ISP-Information ]
[ Protection-Capability]
[ PPAC ]
* [ AVP ] * [ AVP ]
9.3.4 PANA-Start-Answer (PSA) 6.4.4 PANA-Start-Answer (PSA)
PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to
a PANA-Start-Request message. The PANA_start message transmission a PANA-Start-Request message. The PANA_start message transmission
sequence number field is copied to the received sequence number sequence number field is copied to the received sequence number
field. The transmission sequence number is set to initial random field. The transmission sequence number is set to initial random
value. value.
PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >
[ Session-Id ]
[ Cookie ] [ Cookie ]
[ Nonce ]
[ EAP-Payload ] [ EAP-Payload ]
[ ISP-Information ] [ ISP-Information ]
* [ AVP ] * [ AVP ]
9.3.5 PANA-Auth-Request (PAR) 6.4.5 PANA-Auth-Request (PAR)
PANA-Auth-Request (PAR) is sent by the PAA to the PaC. PANA-Auth-Request (PAR) is sent by the PAA to the PaC.
PANA-Auth-Request ::= < PANA-Header: 3, REQ > PANA-Auth-Request ::= < PANA-Header: 3, REQ [SEP] [NAP] >
< Session-Id > < Session-Id >
< EAP-Payload > < EAP-Payload >
0*1 [ NAP-Information ]
0*1 [ ISP-Information ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
(Both NAP-Information and ISP-Information MUST NOT be included at the (Both NAP-Information and ISP-Information MUST NOT be included at the
same time) same time)
9.3.6 PANA-Auth-Answer (PAN) 6.4.6 PANA-Auth-Answer (PAN)
PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a
PANA-Auth-Request message. PANA-Auth-Request message.
PANA-Auth-Answer ::= < PANA-Header: 3 > PANA-Auth-Answer ::= < PANA-Header: 3 [SEP] [NAP] >
< Session-Id > < Session-Id >
< EAP-Payload > < EAP-Payload >
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.7 PANA-Bind-Request (PBR) 6.4.7 PANA-Bind-Request (PBR)
PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request (PBR) is sent by the PAA to the PaC.
PANA-Bind-Request ::= < PANA-Header: 4, REQ > PANA-Bind-Request ::= < PANA-Header: 4, REQ [SEP] [NAP] >
< Session-Id > < Session-Id >
< Device-Id >
{ EAP-Payload }
{ Result-Code } { Result-Code }
{ PPAC }
[ EAP-Payload ]
[ Device-Id ]
[ Session-Lifetime ] [ Session-Lifetime ]
[ Protection-Capability ] [ Protection-Capability ]
[ Key-Id ] [ Key-Id ]
[ Nonce ]
* [ EP-Device-Id ] * [ EP-Device-Id ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.8 PANA-Bind-Answer (PBA) 6.4.8 PANA-Bind-Answer (PBA)
PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a
PANA-Result-Request message. PANA-Result-Request message.
PANA-Bind-Answer ::= < PANA-Header: 4 > PANA-Bind-Answer ::= < PANA-Header: 4 [,SEP] [NAP] >
< Session-Id > < Session-Id >
< Device-Id > { Result-Code }
[ PPAC ]
[ Device-Id ]
[ Key-Id ] [ Key-Id ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.9 PANA-Reauth-Request (PRAR) 6.4.9 PANA-Reauth-Request (PRAR)
PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA. PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA.
PANA-Reauth-Request ::= < PANA-Header: 5, REQ > PANA-Reauth-Request ::= < PANA-Header: 5, REQ >
< Session-Id > < Session-Id >
< Device-Id > [ Device-Id ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.10 PANA-Reauth-Answer (PRAA) 6.4.10 PANA-Reauth-Answer (PRAA)
PANA-Reauth-Answer (PRAA) is sent in response to a PANA-Reauth-Answer (PRAA) is sent in response to a
PANA-Reauth-Request. PANA-Reauth-Request.
PANA-Reauth-Answer ::= < PANA-Header: 5 > PANA-Reauth-Answer ::= < PANA-Header: 5 >
< Session-Id > < Session-Id >
< Device-Id > [ Device-Id ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.11 PANA-Termination-Request (PTR) 6.4.11 PANA-Termination-Request (PTR)
PANA-Termination-Request (PTR) is sent either by the PaC or the PAA. PANA-Termination-Request (PTR) is sent either by the PaC or the PAA.
PANA-Termination-Request ::= < PANA-Header: 6, REQ > PANA-Termination-Request ::= < PANA-Header: 6, REQ >
< Session-Id > < Session-Id >
< Termination-Cause > < Termination-Cause >
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.12 PANA-Termination-Answer (PTA) 6.4.12 PANA-Termination-Answer (PTA)
PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in
response to PANA-Termination-Request. response to PANA-Termination-Request.
PANA-Termination-Answer ::= < PANA-Header: 6 > PANA-Termination-Answer ::= < PANA-Header: 6 >
< Session-Id > < Session-Id >
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.13 PANA-Error (PER) 6.4.13 PANA-Error (PER)
PANA-Error is sent either by the PaC or the PAA. PANA-Error is sent either by the PaC or the PAA.
PANA-Error ::= < PANA-Header: 7 > PANA-Error ::= < PANA-Header: 7 >
< Session-Id > < Session-Id >
< Result-Code > < Result-Code >
{ Failed-AVP } { Failed-AVP }
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.4 AVPs in PANA 6.4.14 PANA-FirstAuth-End-Request (PFER)
PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC.
PANA-FirstAuth-End-Request ::= < PANA-Header: 8, REQ [SEP] [NAP] >
< Session-Id >
< Device-Id >
{ EAP-Payload }
{ Result-Code }
[ Key-Id ]
* [ AVP ]
0*1 < MAC >
6.4.15 PANA-FirstAuth-End-Answer (PFEA)
PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in
response to a PANA-FirstAuth-End-Request message.
PANA-FirstAuth-End-Answer ::= < PANA-Header: 8, REQ [SEP] [NAP] >
< Session-Id >
< Device-Id >
[ Key-Id ]
* [ AVP ]
0*1 < MAC >
6.5 AVPs in PANA
Some of the used AVPs are defined in this document and some of them Some of the used AVPs are defined in this document and some of them
are defined in other documents like [RFC3588]. PANA proposes to use are defined in other documents like [RFC3588]. PANA proposes to use
the same name space with the Diameter spec. For temporary allocation, the same name space with [RFC3588]. For temporary allocation, PANA
PANA uses AVP type numbers starting from 1024. uses AVP type numbers starting from 1024.
9.4.1 MAC AVP 6.5.1 MAC AVP
The first octet (8 bits) of the MAC (Code 1024) AVP data contains the The first octet (8 bits) of the MAC (Code 1024) AVP data contains the
MAC algorithm type. Rest of the AVP data payload contains the MAC MAC algorithm type. Rest of the AVP data payload contains the MAC
encoded in network byte order. The Algorithm 8 bit name space is encoded in network byte order. The Algorithm 8 bit name space is
managed by IANA [ianaweb]. The AVP length varies depending on the managed by IANA [ianaweb]. The AVP length varies depending on the
used algorithm. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Skipping to change at page 37, 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.
9.4.2 Device-Id AVP 6.5.2 Device-Id AVP
The first octet (8 bits) of the Device-Id (Code 1025) AVP data
contains the device type. Rest of the AVP data payload contains the
device data. The content and format of data (including byte and bit
ordering) for L2_ADDRESS is expected to be specified in specific
documents that describe how IP operates over different link-layers.
For instance, [RFC2464].
RESERVED 0
IPV4_ADDRESS 1
IPV6_ADDRESS 2
L2_ADDRESS 3
For type 1 (IPv4 address), data size is 32 bits and for type 2 (IPv6
address), data size is 128 bits.
0 1 2 3 The Device-Id AVP (Code 1025) is of Address type [RFC3588]. IPv4 and
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 IPv6 addresses are encoded as specified in [RFC3588]. The content
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and format of data (including byte and bit ordering) for link-layer
| Type | Data... | addresses is expected to be specified in specific documents that
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ describe how IP operates over different link-layers. For instance,
[RFC2464]. Address families other than that are defined for
link-layer or IP addresses MUST NOT be used for this AVP.
9.4.3 Session-Id AVP 6.5.3 Session-Id AVP
Session-Id AVP (Code 1026) has an opaque data field, which is All messages pertaining to a specific PANA session MUST include a
assigned by the PAA. All messages pertaining to a specific PANA Session-Id AVP (Code 1026) which carries a PAA-assigned fix value
Session MUST include only one Session-Id AVP and the same value MUST throughout the lifetime of a session. When present, the Session-Id
be used throughout the lifetime of a session. When present, the SHOULD appear immediately following the PANA header.
Session-Id SHOULD appear immediately following the 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. information with accounting information. The PANA Session-Id AVP has
the same format as the Diameter Session-Id AVP [RFC3588].
The Session-Id AVP MAY use Diameter [RFC3588] message formatting. In
this case the AVP code is 263.
9.4.4 Cookie AVP 6.5.4 Cookie AVP
The Cookie AVP (Code 1027) is of type OctetString. The data is opaque The Cookie AVP (Code 1027) is of type OctetString. The data is
and the exact content is outside the scope of this protocol. opaque and the exact content is outside the scope of this protocol.
9.4.5 Protection-Capability AVP 6.5.5 Protection-Capability AVP
The Protection-Capability AVP (Code 1028) is of type Unsigned32. The The Protection-Capability AVP (Code 1028) is of type Unsigned32. The
AVP data is used as a collection of flags for different data AVP data indicates the cryptographic data protection capability
protection capability indications. Below is a list of specified data supported by the EPs. Below is a list of specified data protection
protection capabilities: capabilities:
0 UNKNOWN 0 L2_PROTECTION
1 L2_PROTECTION 1 IPSEC_PROTECTION
2 IPSEC_PROTECTION
9.4.6 Termination-Cause AVP 6.5.6 Termination-Cause AVP
The Termination-Cause AVP (Code 1029) is of type of type Enumerated, The Termination-Cause AVP (Code 1029) is of type of type Enumerated,
and is used to indicate the reason why a session was terminated on and is used to indicate the reason why a session was terminated on
the access device. The AVP data is used as a collection of flags The the access device. The AVP data is used as a collection of flags The
following Termination-Cause AVP defined in [RFC3588] are used for following Termination-Cause AVP defined in [RFC3588] are used for
PANA. PANA.
LOGOUT 1 (PaC -> PAA) LOGOUT 1 (PaC -> PAA)
The client initiated a disconnect The client initiated a disconnect
  Skipping to change at page 38, line 46:
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, such as the receipt of a administrative reasons, such as the receipt of a
Abort-Session-Request message. Abort-Session-Request message.
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.
9.4.7 Result-Code AVP 6.5.7 Result-Code AVP
The Result-Code AVP (AVP Code 1030) is of type Unsigned32 and The Result-Code AVP (AVP Code 1030) is of type Unsigned32 and
indicates whether an EAP authentication was completed successfully or indicates whether an EAP authentication was completed successfully or
whether an error occurred. Here are Result-Code AVP values taken whether an error occurred. Here are Result-Code AVP values taken from
from [RFC3588] and adapted for PANA. [RFC3588] and adapted for PANA.
9.4.7.1 Authentication Results Codes 6.5.7.1 Authentication Results Codes
These result code values inform the PaC about the EAP authentication These result code values inform the PaC about the authentication and
method success or failure. authorization result. The authentication result and authorization
result can be different as described below, but only one result that
corresponds to the one detected first is returned.
PANA_SUCCESS 2001 PANA_SUCCESS 2001
The EAP method authentication was successful (EAP-Success). Both the authentication and authorization processes are
successful.
PANA_AUTHENTICATION_REJECTED 4001 PANA_AUTHENTICATION_REJECTED 4001
The authentication process for the client failed (EAP-Failure). The authentication process failed. When this error is returned,
the authorization process also fails.
PANA_AUTHORIZATION_REJECTED 5003 PANA_AUTHORIZATION_REJECTED 5003
A request was received for which the client could not be The authorization process failed. This error could occur when
authorized. This error could occur if the service requested is authorization is rejected by a AAA proxy or rejected locally by a
not permitted to the client. PAA, even if the authentication procedure succeeds.
9.4.7.2 Protocol Error Result Codes 6.5.7.2 Protocol Error Result Codes
Protocol error result code values. Protocol error result code values.
PANA_MESSAGE_UNSUPPORTED 3001 PANA_MESSAGE_UNSUPPORTED 3001
Error code from PAA to PaC or from PaC to PAA. Message type not Error code from PAA to PaC or from PaC to PAA. Message type not
recognized or supported. recognized or supported.
PANA_UNABLE_TO_DELIVER 3002 PANA_UNABLE_TO_DELIVER 3002
  Skipping to change at page 40, line 30:
PANA_INVALID_AVP_VALUE 5004 PANA_INVALID_AVP_VALUE 5004
Error code from PAA to PaC or from PaC to PAA. The message Error code from PAA to PaC or from PaC to PAA. The message
contained an AVP with an invalid value in its data portion. A contained an AVP with an invalid value in its data portion. A
PANA message indicating this error MUST include the offending AVPs PANA message indicating this error MUST include the offending AVPs
within a Failed-AVP AVP. within a Failed-AVP AVP.
PANA_MISSING_AVP 5005 PANA_MISSING_AVP 5005
Error code from PAA to PaC or from PaC to PAA. The message did Error code from PAA to PaC or from PaC to PAA. The message did not
not contain an AVP that is required by the message type contain an AVP that is required by the message type definition.
definition. If this value is sent in the Result-Code AVP, a If this value is sent in the Result-Code AVP, a Failed-AVP AVP
Failed-AVP AVP SHOULD be included in the message. The Failed-AVP SHOULD be included in the message. The Failed-AVP AVP MUST
AVP MUST contain an example of the missing AVP complete with the contain an example of the missing AVP complete with the Vendor-Id
Vendor-Id if applicable. The value field of the missing AVP if applicable. The value field of the missing AVP should be of
should be of correct minimum length and contain zeroes. correct minimum length and contain zeroes.
PANA_RESOURCES_EXCEEDED 5006 PANA_RESOURCES_EXCEEDED 5006
Error code from PAA to PaC. A message was received that cannot be Error code from PAA to PaC. A message was received that cannot be
authorized because the client has already expended allowed authorized because the client has already expended allowed
resources. An example of this error condition is a client that is resources. An example of this error condition is a client that is
restricted to one PANA session and attempts to establish a second restricted to one PANA session and attempts to establish a second
session. session.
PANA_CONTRADICTING_AVPS 5007 PANA_CONTRADICTING_AVPS 5007
  Skipping to change at page 40, line 47:
PANA_RESOURCES_EXCEEDED 5006 PANA_RESOURCES_EXCEEDED 5006
Error code from PAA to PaC. A message was received that cannot be Error code from PAA to PaC. A message was received that cannot be
authorized because the client has already expended allowed authorized because the client has already expended allowed
resources. An example of this error condition is a client that is resources. An example of this error condition is a client that is
restricted to one PANA session and attempts to establish a second restricted to one PANA session and attempts to establish a second
session. session.
PANA_CONTRADICTING_AVPS 5007 PANA_CONTRADICTING_AVPS 5007
Error code from PAA to PaC. The PAA has detected AVPs in the Error code from PAA to PaC. The PAA has detected AVPs in the
message that contradicted each other, and is not willing to message that contradicted each other, and is not willing to
provide service to the client. One or more Failed-AVP AVPs MUST be provide service to the client. One or more Failed-AVP AVPs MUST
present, containing the AVPs that contradicted each other. be present, containing the AVPs that contradicted each other.
PANA_AVP_NOT_ALLOWED 5008 PANA_AVP_NOT_ALLOWED 5008
Error code from PAA to PaC or from PaC to PAA. A message was Error code from PAA to PaC or from PaC to PAA. A message was
received with an AVP that MUST NOT be present. The Failed-AVP AVP received with an AVP that MUST NOT be present. The Failed-AVP AVP
MUST be included and contain a copy of the offending AVP. MUST be included and contain a copy of the offending AVP.
PANA_AVP_OCCURS_TOO_MANY_TIMES 5009 PANA_AVP_OCCURS_TOO_MANY_TIMES 5009
Error code from PAA to PaC or from PaC to PAA. A message was Error code from PAA to PaC or from PaC to PAA. A message was
  Skipping to change at page 41, line 31:
Error code from PAA to PaC or from PaC to PAA. This error is Error code from PAA to PaC or from PaC to PAA. This error is
returned when a message was received, whose version number is returned when a message was received, whose version number is
unsupported. unsupported.
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
PANA-Bind-Request message without an EAP-Payload AVP. PANA-Error message.
PANA_INVALID_AVP_LENGTH 5014 PANA_INVALID_AVP_LENGTH 5014
Error code from PAA to PaC or from PaC to PAA. The message Error code from PAA to PaC or from PaC to PAA. The message
contained an AVP with an invalid length. The PANA-Error message contained an AVP with an invalid length. The PANA-Error message
indicating this error MUST include the offending AVPs within a indicating this error MUST include the offending AVPs within a
Failed-AVP AVP. Failed-AVP AVP.
PANA_INVALID_MESSAGE_LENGTH 5015 PANA_INVALID_MESSAGE_LENGTH 5015
  Skipping to change at page 42, line 5:
length. length.
PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016
Error code from PaC to PAA. This error is returned when the PaC Error code from PaC to PAA. This error is returned when the PaC
receives a PANA-Bind-Request is received with an receives a PANA-Bind-Request is received with an
Protection-Capability AVP and a valid MAC AVP but does not support Protection-Capability AVP and a valid MAC AVP but does not support
the protection capability specified in the Protection-Capability the protection capability specified in the Protection-Capability
AVP. AVP.
9.4.8 EAP-Payload AVP PANA_PPAC_CAPABILITY_UNSUPPORTED 5017
Error code from PaC to PAA. This error is returned in a
PANA-Bind-Answer message when there is no match between the list
of PPAC methods offered by the PAA and the ones available on the
PaC.
6.5.8 EAP-Payload AVP
The EAP-Payload AVP (AVP Code 1031) is of type OctetString and is The EAP-Payload AVP (AVP Code 1031) is of type OctetString and is
used to encapsulate the actual EAP packet that is being exchanged used to encapsulate the actual EAP packet that is being exchanged
between the EAP peer and the EAP authenticator. between the EAP peer and the EAP authenticator.
9.4.9 Session-Lifetime AVP 6.5.9 Session-Lifetime AVP
The Session-Lifetime AVP (Code 1032) data is of type Unsigned32. It The Session-Lifetime AVP (Code 1032) data is of type Unsigned32. It
contains the number of seconds remaining before the current session contains the number of seconds remaining before the current session
is considered expired. is considered expired.
9.4.10 Failed-AVP AVP 6.5.10 Failed-AVP AVP
The Failed-AVP AVP (AVP Code 1033) is of type Grouped and provides The Failed-AVP AVP (AVP Code 1033) is of type Grouped and provides
debugging information in cases where a request is rejected or not debugging information in cases where a request is rejected or not
fully processed due to erroneous information in a specific AVP. The fully processed due to erroneous information in a specific AVP. The
format of the Failed-AVP AVP is defined in [RFC3588]. format of the Failed-AVP AVP is defined in [RFC3588].
9.4.11 NAP-Information AVP 6.5.11 NAP-Information AVP
The NAP-Information AVP (AVP Code: 1034) is of type Grouped, and The NAP-Information AVP (AVP Code: 1034) is of type Grouped, and
contains zero or one Provider-Identifier AVP which carries the contains zero or one Provider-Identifier AVP which carries the
identifier of the NAP and one Provider-Name AVP which carries the identifier of the NAP and one Provider-Name AVP which carries the
name of the NAP. Its Data field has the following ABNF grammar: name of the NAP. Its Data field has the following ABNF grammar:
NAP-Information ::= < AVP Header: 1034 > NAP-Information ::= < AVP Header: 1034 >
0*1 { Provider-Identifier } 0*1 { Provider-Identifier }
{ Provider-Name } { Provider-Name }
* [ AVP ] * [ AVP ]
9.4.12 ISP-Information AVP 6.5.12 ISP-Information AVP
The ISP-Information AVP (AVP Code: 1035) is of type Grouped, and The ISP-Information AVP (AVP Code: 1035) is of type Grouped, and
contains zero or one Provider-Identifier AVP which carries the contains zero or one Provider-Identifier AVP which carries the
identifier of the ISP and one Provider-Name AVP which carries the identifier of the ISP and one Provider-Name AVP which carries the
name of the ISP. Its Data field has the following ABNF grammar: name of the ISP. Its Data field has the following ABNF grammar:
ISP-Information ::= < AVP Header: 1035 > ISP-Information ::= < AVP Header: 1035 >
0*1 { Provider-Identifier } 0*1 { Provider-Identifier }
{ Provider-Name } { Provider-Name }
* [ AVP ] * [ AVP ]
9.4.13 Provider-Identifier AVP 6.5.13 Provider-Identifier AVP
The Provider-Identifier AVP (AVP Code: 1036) is of type Unsigned32, The Provider-Identifier AVP (AVP Code: 1036) is of type Unsigned32,
and contains an IANA assigned "SMI Network Management Private and contains an IANA assigned "SMI Network Management Private
Enterprise Codes" [ianaweb] value, encoded in network byte order. Enterprise Codes" [ianaweb] value, encoded in network byte order.
9.4.14 Provider-Name AVP 6.5.14 Provider-Name AVP
The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and
contains the UTF8-encoded name of the provider. contains the UTF8-encoded name of the provider.
9.4.15 EP-Device-Id AVP 6.5.15 EP-Device-Id AVP
The EP-Device-Id AVP (AVP Code: 1038) contains the device identifier The EP-Device-Id AVP (AVP Code: 1038) contains the device identifier
of an EP. The payload format of the EP-Device-Id AVP is the same as of an EP. The payload format of the EP-Device-Id AVP is the same as
that of the Device-Id AVP (see See section Section 9.4.2). that of the Device-Id AVP (see See section Section 6.5.2).
9.4.16 Key-Id AVP 6.5.16 Key-Id AVP
The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an The Key-Id AVP (AVP Code: 1039) 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.
9.5 AVP Occurrence Table 6.5.17 Post-PANA-Address-Configuration (PPAC) AVP
The data field of PPAC AVP (Code 1040) is of type Unsigned32. The
AVP data is used to carry a set of flags which maps to various IP
address configuration methods. When sent by the PAA, the AVP MUST
have at least one of the flags set, and MAY have more than one set.
When sent by the PaC, only one of the flags MUST be set.
The format of the AVP data is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|D|A|T|I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPAC Flags
N (No configuration)
The PaC does not have to (if sent by PAA) or will not (if sent
by PaC) configure a new IP address after PANA.
D (DHCP)
The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP
[RFC2131][RFC3315] to configure a new IP address after PANA.
A (stateless autoconfiguration)
The PaC can/will use stateless IPv6 address autoconfiguration
[RFC2462] to configure a new IP address after PANA.
T (DHCP with IPsec tunnel mode)
The PaC can/will use [RFC3456] to configure a new IP address
after PANA.
I (IKEv2)
The PaC can/will use [I-D.ietf-ipsec-ikev2] to configure a new
IP address after PANA.
Reserved
These flag bits are reserved for future use, and MUST be set to
zero, and ignored by the receiver.
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
[I-D.ietf-pana-framework] for a detailed discussion on when these
methods can be used.
6.5.18 Nonce AVP
The Nonce AVP (Code 1041) is of type OctetString. The data contains
a randomly generated value in opaque format. The data length MUST be
between 8 and 256 bytes inclusive.
6.6 AVP Occurrence Table
The following tables lists the AVPs used in this document, and The following tables lists the AVPs used in this document, and
specifies in which PANA messages they MAY, or MAY NOT be present. specifies in which PANA messages they MAY, or MAY NOT be present.
The table uses the following symbols: The table uses the following symbols:
0 The AVP MUST NOT be present in the message. 0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the 0+ Zero or more instances of the AVP MAY be present in the
message. message.
  Skipping to change at page 44, line 4:
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 | | Message |
| Type | | Type |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
--------------------+-----+-----+-----+-----+-----+-----+-----+ --------------------+-----+-----+-----+-----+-----+-----+-----+
Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Session-Id | 0 | 0-1 | 1 | 1 | 1 | 1 | 0-1 |
Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 |
MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | MAC | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | Nonce | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 |
Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 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 | Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
ISP-Information | 0+ | 0-1 | 0-1 | 0 | 0 | 0 | 0 | ISP-Information | 0+ | 0-1 | 0 | 0 | 0 | 0 | 0 |
NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0 | 0 | 0 | 0 | 0 |
EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 |
--------------------+-----+-----+-----+-----+-----+-----+-----+ --------------------+-----+-----+-----+-----+-----+-----+-----+
+-------------------------------+ Figure 11: AVP Occurrence Table (1/2)
+---------------------------------------------+
| Message | | Message |
| Type | | Type |
+------+------+-----+-----+-----+ +------+------+-----+-----+-----+------+------+
Attribute Name | PRAR | PRAA | PTR | PTA | PER | Attribute Name | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA |
--------------------+------+------+-----+-----+-----+ --------------------+------+------+-----+-----+-----+------+------+
Result-Code | 0 | 0 | 0 | 0 | 1 | Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
Session-Id | 1 | 1 | 1 | 1 | 1 | Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Termination-Cause | 0 | 0 | 1 | 0 | 0 | Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | EAP-Payload | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
MAC | 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 |
Device-Id | 1+ | 1+ | 0 | 0 | 0 | Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Cookie | 0 | 0 | 0 | 0 | 0 | Device-Id | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0 | 0 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Session-Lifetime | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 1 | PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
ISP-Information | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
NAP-Information | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
EP-Device-Id | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
--------------------+------+------+-----+-----+-----+ EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0 | 0-1 | 0-1 |
--------------------+------+------+-----+-----+-----+------+------+
Figure 10: AVP Occurrence Table Figure 12: AVP Occurrence Table (2/2)
10. PANA Protocol Message Retransmissions 7. PANA Protocol Message Retransmissions
The PANA protocol provides retransmissions for all the message The PANA protocol provides retransmissions for all the message
exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request
carry EAP requests which are retransmitted by the EAP protocol messages carry EAP requests which are retransmitted by the EAP
entities when needed. The messages that need PANA-level protocol entities when needed. The messages that need PANA-level
retransmissions are listed below: retransmissions are listed below:
PANA-PAA-Discover (PDI) PANA-PAA-Discover (PDI)
PANA-Start-Answer (PSA) PANA-Start-Request (PSR)*
PANA-Start-Answer (PSA)**
PANA-Bind-Request (PBR) PANA-Bind-Request (PBR)
PANA-FirstAuth-End-Request (PFER)
PANA-Reauth-Request (PRAR) PANA-Reauth-Request (PRAR)
PANA-Termination-Request (PTR) PANA-Termination-Request (PTR)
*) PSR that carries a Cookie AVP is not retransmitted.
**) PSA that does not carry a Cookie AVP is not retransmitted.
The PDI and PSA messages are always sent by the PaC. PBR is sent by The PDI and PSA messages are always sent by the PaC. PBR is sent by
PAA. The last two messages, PRAR and PTR are sent either by PaC or PAA. The last two messages, PRAR and PTR are sent either by PaC or
PAA. PAA.
The rule is that the sender of the request message retransmits the The rule is that the sender of the request message retransmits the
request if the corresponding answer is not received in time. Answer request if the corresponding answer is not received in time. Answer
messages are sent as answers to the request messages, not based on a messages are sent as answers to the request messages, not based on a
timer. Exception to this rule is the PSA message. Because of the timer. Exception to this rule is the PSA message. Because of the
stateless nature of the PAA in the beginning PaC provides stateless nature of the PAA in the beginning PaC provides
retransmission also for the PSA message. PANA-Error messages MUST retransmission also for the PSA message. PANA-Error messages MUST
  Skipping to change at page 47, line 5:
once MRD seconds have elapsed since the client first transmitted the once MRD seconds have elapsed since the client first transmitted the
message. message.
If both MRC and MRD are non-zero, the message exchange fails whenever If both MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous two paragraphs are either of the conditions specified in the previous two paragraphs are
met. met.
If both MRC and MRD are zero, the client continues to transmit the If both MRC and MRD are zero, the client continues to transmit the
message until it receives a response. message until it receives a response.
10.1 Transmission and Retransmission Parameters 7.1 Transmission and Retransmission Parameters
This section presents a table of values used to describe the message This section presents a table of values used to describe the message
retransmission behavior of request and PANA-Start-Answer messages retransmission behavior of request and PANA-Start-Answer messages
marked with REQ_*. PANA-PAA-Discover message retransmission values marked with REQ_*. PANA-PAA-Discover message retransmission values
are marked with PDI_*. The table shows default values. are marked with PDI_*. The table shows default values.
Parameter Default Description Parameter Default Description
------------------------------------------------ ------------------------------------------------
PDI_IRT 1 sec Initial PDI timeout. PDI_IRT 1 sec Initial PDI timeout.
PDI_MRT 120 secs Max PDI timeout value. PDI_MRT 120 secs Max PDI timeout value.
  Skipping to change at page 48, line 5:
REQ_IRT 1 sec Initial Request timeout. REQ_IRT 1 sec Initial Request timeout.
REQ_MRT 30 secs Max Request timeout value. REQ_MRT 30 secs Max Request timeout value.
REQ_MRC 10 Max Request retry attempts. REQ_MRC 10 Max Request retry attempts.
REQ_MRD 0 Configurable. REQ_MRD 0 Configurable.
So for example the first RT for the PBR message is calculated using So for example the first RT for the PBR message is calculated using
REQ_IRT as the IRT: REQ_IRT as the IRT:
RT = REQ_IRT + RAND*REQ_IRT RT = REQ_IRT + RAND*REQ_IRT
11. Security Considerations 8. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
Diameter protocol, in accordance with BCP 26 [IANA]. The following
policies are used here with the meanings defined in BCP 26: "Private
Use", "First Come First Served", "Expert Review", "Specification
Required", "IETF Consensus", "Standards Action".
This section explains the criteria to be used by the IANA for
assignment of numbers within namespaces defined within this document.
For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. For Designated Expert with Specification
Required, the request is posted to the PANA WG mailing list (or, if
it has been disbanded, a successor designated by the Area Director)
for comment and review, and MUST include a pointer to a public
specification. Before a period of 30 days has passed, the Designated
Expert will either approve or deny the registration request and
publish a notice of the decision to the PANA WG mailing list or its
successor. A denial notice must be justified by an explanation and,
in the cases where it is possible, concrete suggestions on how the
request can be modified so as to become acceptable.
8.1 PANA UDP Port Number
TBD.
8.2 PANA Multicast Address
TBD.
8.3 PANA Header
8.3.1 Message Type
TBD.
8.3.2 Flags
TBD.
8.4 AVP Header
8.4.1 AVP Code
TBD.
8.4.2 Flags
TBD.
8.4.3 Vendor Id
TBD.
8.5 AVP Values
8.5.1 MAC AVP Values
TBD.
8.5.2 Device-Id AVP Values
TBD.
8.5.3 Protection-Capability AVP Values
TBD.
8.5.4 Result-Code AVP Values
TBD.
8.5.5 Termination-Cause AVP Values
TBD.
8.5.6 Provider-Identifier AVP Values
TBD.
8.5.7 Post-PANA-Address-Configuration AVP Values
TBD.
9. Security Considerations
The PANA protocol provides ordered delivery for EAP messages. If an The PANA protocol provides ordered delivery for EAP messages. If an
EAP method that provides session keys is used, a PANA SA is created. EAP method that provides session keys is used, a PANA SA is created.
The EAP Success/Failure message is one of the signaling messages The EAP Success/Failure message is one of the signaling messages
which is integrity protected with this PANA SA. The PANA protocol which is integrity protected with this PANA SA. The PANA protocol
does not provide security protection for the initial EAP message does not provide security protection for the initial EAP message
exchange. Integrity protection can only be provided after the PANA SA exchange. Integrity protection can only be provided after the PANA
has been established. Thus, PANA re-authentication, revocation and SA has been established. Thus, PANA re-authentication, revocation and
disconnect notifications can be authenticated, integrity and replay disconnect notifications can be authenticated, integrity and replay
protected. In certain environments (e.g. on a shared link) the EAP protected. In certain environments (e.g., on a shared link) the EAP
method selection is an important issue. method selection is an important issue.
The PANA framework described in this document covers the discussion The PANA framework described in this document covers the discussion
of different protocols which are of interest for a protocol between of different protocols which are of interest for a protocol between
the PaC and the PAA (typically referred as the PANA protocol). the PaC and the PAA (typically referred as the PANA protocol).
The PANA itself consists of a sequence of steps which are executed to The PANA itself consists of a sequence of steps which are executed to
complete the network access authentication procedure. Some of these complete the network access authentication procedure. Some of these
steps are optional. steps are optional.
  Skipping to change at page 48, line 38:
subsequently. subsequently.
a) Discovery message exchange a) Discovery message exchange
In general it is difficult to prevent a vulnerabilities of the In general it is difficult to prevent a vulnerabilities of the
discovery protocol since the initial discovery are unsecured. To discovery protocol since the initial discovery are unsecured. To
prevent very basic attacks an adversary should not be able to cause prevent very basic attacks an adversary should not be able to cause
state creation with discovery messages at the PAA. This is prevented state creation with discovery messages at the PAA. This is prevented
by re-using a cookie concept (see [RFC2522] which allows the by re-using a cookie concept (see [RFC2522] which allows the
responder to be stateless in the first message exchange. Because of responder to be stateless in the first message exchange. Because of
the architectural assumptions made in PANA (i.e. the PAA is the on the architectural assumptions made in PANA (i.e., the PAA is the on
the same link as the PaC) the return-routability concept does not the same link as the PaC) the return-routability concept does not
provide additional protection. Hence it is difficult to prevent this provide additional protection. Hence it is difficult to prevent this
threat entirely. Furthermore it is not possible to shift heavy threat entirely. Furthermore it is not possible to shift heavy
cryptographic operations to the PaC at the first few messages since cryptographic operations to the PaC at the first few messages since
the computational effort depends on the EAP method. The usage of the computational effort depends on the EAP method. The usage of
client-puzzles as introduced by [jb99] is under investigation. client-puzzles as introduced by [jb99] is under investigation.
Resistance against blind DoS attacks (i.e. attacks by off-path Resistance against blind DoS attacks (i.e., attacks by off-path
adversaries) is achieved with sequence numbers and cookies. adversaries) is achieved with sequence numbers and cookies.
Since PAA and PaC are supposed to be one IP hop away, a simple TTL Since PAA and PaC are supposed to be one IP hop away, a simple TTL
check can prevent off-link attacks. Furthermore, additional filtering check can prevent off-link attacks. Furthermore, additional
can be enabled on the EPs. An EP may be able to filter unauthorized filtering can be enabled on the EPs. An EP may be able to filter
PAA advertisements when they are received on the access side of the unauthorized PAA advertisements when they are received on the access
network where only PaCs are connected. side of the network where only PaCs are connected.
In networks where lower-layers are not secured prior to running PANA,
the capability discovery enabled through inclusion of
Protection-Capability and Post-PANA-Address-Configuration AVPs in
PANA-Start-Request message is susceptible to spoofing. Therefore,
usage of these AVPs during the discovery phase in such insecure
networks is NOT RECOMMENDED. The same AVPs are delivered via an
integrity-protected PANA-Bind-Request upon successful authentication.
b) EAP over PANA message exchange b) EAP over PANA message exchange
The EAP derived session key is used to create a PANA security The EAP derived session key is used to create a PANA security
association. Since the execution of an EAP method might require a association. Since the execution of an EAP method might require a
large number of roundtrips and no other session key is available it large number of roundtrips and no other session key is available it
is not possible to secure the EAP message exchange itself. Hence an is not possible to secure the EAP message exchange itself. Hence an
adversary can both eavesdrop the EAP messages and is also able to adversary can both eavesdrop the EAP messages and is also able to
inject arbitrary messages which might confuse both the EAP peer on inject arbitrary messages which might confuse both the EAP peer on
PaC and the EAP authenticator or authentication server on the PAA. PaC and the EAP authenticator or authentication server on the PAA.
The threats caused by this ability heavily depend on the EAP state The threats caused by this ability heavily depend on the EAP state
machine. Since especially the PAA is not allowed to discard packets machine. Since especially the PAA is not allowed to discard packets
and packets have to be stored or forwarded to an AAA infrastructure and packets have to be stored or forwarded to an AAA infrastructure
some risk of DoS attacks exists. some risk of DoS attacks exists.
Eavesdropping EAP packets might cause problems when (a) the EAP Eavesdropping EAP packets might cause problems when (a) the EAP
method is weak and enables dictionary or replay attacks or even method is weak and enables dictionary or replay attacks or even
allows an adversary to learn the long-term password directly. allows an adversary to learn the long-term password directly.
Furthermore, if the optional EAP Identity payload is used then it Furthermore, if the optional EAP Identity payload is used then it
allows the adversary to learn the identity of the PaC. In such a case allows the adversary to learn the identity of the PaC. In such a
a privacy problem is prevalent. case a privacy problem is prevalent.
To prevent these threats Section 6 suggests using proper EAP methods To prevent these threats, [I-D.ietf-pana-framework] suggests using
for particular environments. Depending on the usage environment an proper EAP methods for particular environments. Depending on the
EAP authentication has to be used for example which supports user usage environment an EAP authentication has to be used for example
identity confidentiality, protection against dictionary attacks and which supports user identity confidentiality, protection against
session key establishment. It is therefore the responsibility of the dictionary attacks and session key establishment. It is therefore
network operators and end users to choose the proper EAP method. the responsibility of the network operators and end users to choose
the proper EAP method.
PANA does not protect the EAP method exchange, but provides ordered PANA does not protect the EAP method exchange, but provides ordered
delivery with sequence numbers. Sequence numbers and cookies provide delivery with sequence numbers. Sequence numbers and cookies provide
resistance against blind DoS attacks. resistance against blind DoS attacks.
c) PANA SA establishment c) PANA SA establishment
Once the EAP message authentication is finished a fresh and unique Once the EAP message authentication is finished a fresh and unique
session key is available to the PaC and the PAA. This assumes that session key is available to the PaC and the PAA. This assumes that
the EAP method allows session key derivation and that the generated the EAP method allows session key derivation and that the generated
session key has a good quality. For further discussion about the session key has a good quality. For further discussion about the
importance of the session key generation refer to the next subsection importance of the session key generation refer to the next subsection
(d) about compound authentication. The session key available for the (d) about compound authentication. The session key available for the
PaC is established as part of the authentication and key exchange PaC is established as part of the authentication and key exchange
procedure of the selected EAP method. The PAA obtains the session key procedure of the selected EAP method. The PAA obtains the session
via the AAA infrastructure (if used). Security issues raised with key via the AAA infrastructure (if used). Security issues raised
this session key transport are described in [I-D.ietf-eap-keying]. with this session key transport are described in
[I-D.ietf-eap-keying].
The establishment of a PANA SA is required in environments where no The establishment of a PANA SA is required in environments where no
physical or link layer security is available. The PANA SA allows physical or link layer security is available. The PANA SA allows
subsequently exchanged messages to experience cryptographic subsequently exchanged messages to experience cryptographic
protection. For the current version of the document an integrity protection. For the current version of the document an integrity
object (MAC AVP) is defined which supports data-origin object (MAC AVP) is defined which supports data-origin
authentication, replay protection based on sequence numbers and authentication, replay protection based on sequence numbers and
integrity protection based on a keyed message digest. Confidentiality integrity protection based on a keyed message digest.
protection is not provided. The session keys used for this object Confidentiality protection is not provided. The session keys used for
have to be provided by the EAP method. For this version of the this object have to be provided by the EAP method. For this version
document it is assumed that no negotiation of algorithms and of the document it is assumed that no negotiation of algorithms and
parameters takes place. Instead HMAC-SHA1 is used by default. A parameters takes place. Instead HMAC-SHA1 is used by default. A
different algorithm may be chosen by default in a future version of different algorithm may be chosen by default in a future version of
the PANA protocol specification. The used algorithm is indicated in the PANA protocol specification. The used algorithm is indicated in
the header of the Integrity object. To select the security the header of the Integrity object. To select the security
association for signaling message protection the Session ID is association for signaling message protection the Session ID is
conveyed. The keyed message digest included in the Integrity object conveyed. The keyed message digest included in the Integrity object
will include all fields of the PANA signaling message including the will include all fields of the PANA signaling message including the
sequence number field of the packet. sequence number field of the packet.
The protection of subsequent signaling messages prevents an adversary The protection of subsequent signaling messages prevents an adversary
  Skipping to change at page 49, line 82:
from replaying messages and from modifying the content of the from replaying messages and from modifying the content of the
exchanged packets. This prevents subsequently described threats. exchanged packets. This prevents subsequently described threats.
If an entity (PAA or PaC) loses its state (especially the current If an entity (PAA or PaC) loses its state (especially the current
sequence number) then the entire PANA protocol has to be restarted. sequence number) then the entire PANA protocol has to be restarted.
No re-synchronization procedure is provided. No re-synchronization procedure is provided.
The lifetime of the PANA SA has to be bound to the AAA-authorized The lifetime of the PANA SA has to be bound to the AAA-authorized
session lifetime with an additional tolerance period. Unless PANA session lifetime with an additional tolerance period. Unless PANA
state is updated by executing another EAP authentication, PANA SA is state is updated by executing another EAP authentication, PANA SA is
removed when the current session expires. The lifetime of the PANA SA removed when the current session expires. The lifetime of the PANA
has to be bound to the AAA-authorized session lifetime with an SA has to be bound to the AAA-authorized session lifetime with an
additional tolerance period. Unless PANA state is updated by additional tolerance period. Unless PANA state is updated by
executing another EAP authentication, PANA SA is removed when the executing another EAP authentication, PANA SA is removed when the
current session expires. current session expires.
d) Enabling weak legacy authentication methods in insecure networks d) Enabling weak legacy authentication methods in insecure networks
Some of the authentication methods are not strong enough to be used Some of the authentication methods are not strong enough to be used
in insecure networks where attackers can easily eavesdrop and spoof in insecure networks where attackers can easily eavesdrop and spoof
on the link. They may not be able to produce much needed keying on the link. They may not be able to produce much needed keying
material either. An example would be using EAP-MD5 over wireless material either. An example would be using EAP-MD5 over wireless
links. Use of such legacy methods can be enabled by carrying them links. Use of such legacy methods can be enabled by carrying them
over a secure channel. There are EAP methods which are specifically over a secure channel. There are EAP methods which are specifically
designed for this purpose, such as EAP-TTLS designed for this purpose, such as EAP-TTLS
[I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or [I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or
EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP
tunneling methods which can carry the legacy methods. PANA does not tunneling methods which can carry the legacy methods. PANA does not
  Skipping to change at page 49, line 100:
Some of the authentication methods are not strong enough to be used Some of the authentication methods are not strong enough to be used
in insecure networks where attackers can easily eavesdrop and spoof in insecure networks where attackers can easily eavesdrop and spoof
on the link. They may not be able to produce much needed keying on the link. They may not be able to produce much needed keying
material either. An example would be using EAP-MD5 over wireless material either. An example would be using EAP-MD5 over wireless
links. Use of such legacy methods can be enabled by carrying them links. Use of such legacy methods can be enabled by carrying them
over a secure channel. There are EAP methods which are specifically over a secure channel. There are EAP methods which are specifically
designed for this purpose, such as EAP-TTLS designed for this purpose, such as EAP-TTLS
[I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or [I-D.ietf-pppext-eap-ttls],PEAP [I-D.josefsson-pppext-eap-tls-eap] or
EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP EAP-IKEv2 [I-D.tschofenig-eap-ikev2]. PANA can carry these EAP
tunneling methods which can carry the legacy methods. PANA does not tunneling methods which can carry the legacy methods. PANA does not
do anything special for this case. The EAP tunneling method will have do anything special for this case. The EAP tunneling method will
to produce keying material for PANA SA when needed. There are certain have to produce keying material for PANA SA when needed. There are
MitM vulnerabilities with tunneling EAP methods [mitm]. Solving these certain MitM vulnerabilities with tunneling EAP methods [mitm].
problems is outside the scope of PANA. The compound authentication Solving these problems is outside the scope of PANA. The compound
problem described in [I-D.puthenkulam-eap-binding] is likely to be authentication problem described in [I-D.puthenkulam-eap-binding] is
solved in EAP itself rather than in PANA. likely to be solved in EAP itself rather than in PANA.
e) Device Identifier exchange e) Device Identifier exchange
As part of the authorization procedure a Device Identifier has to be As part of the authorization procedure a Device Identifier has to be
installed at the EP by the PAA. The PaC provides the Device installed at the EP by the PAA. The PaC provides the Device
Identifier information to the PAA secured with the PANA SA. Section Identifier information to the PAA secured with the PANA SA. Section
6.2.4 of [I-D.ietf-pana-threats-eval] describes a threat where an 6.2.4 of [I-D.ietf-pana-threats-eval] describes a threat where an
adversary modifies the Device Identifier to gain unauthorized access adversary modifies the Device Identifier to gain unauthorized access
to the network. to the network.
The installation of the Device Identifier at the EP (independently The installation of the Device Identifier at the EP (independently
whether the EP is co-located with the PAA or not) has to be whether the EP is co-located with the PAA or not) has to be
accomplished in a secure manner. These threats are, however, not part accomplished in a secure manner. These threats are, however, not
of the PANA protocol itself since the protocol is not PANA specific. part of the PANA protocol itself since the protocol is not PANA
specific.
f) Triggering a data protection protocol f) Triggering a data protection protocol
Recent activities in the EAP working group try to create a common Recent activities in the EAP working group try to create a common
framework for key derivation which is described in framework for key derivation which is described in
[I-D.ietf-eap-keying]. This framework is also relevant for PANA in [I-D.ietf-eap-keying]. This framework is also relevant for PANA in
various ways. First, a PANA security association needs to be created. various ways. First, a PANA security association needs to be
Additionally it might be necessary to trigger a protocol which allows created. Additionally it might be necessary to trigger a protocol
link layer and network layer data protection to be established. As an which allows link layer and network layer data protection to be
example see Section 1 of [I-D.ietf-eap-keying] with [802.11i] and established. As an example see Section 1 of [I-D.ietf-eap-keying]
[802.11] as an example. Furthermore, a derived session key might help with [802.11i] and [802.11] as an example. Furthermore, a derived
to create the pre-requisites for network-layer protection (for session key might help to create the pre-requisites for network-layer
example IPsec [I-D.ietf-pana-ipsec]). protection (for example IPsec [I-D.ietf-pana-ipsec]).
As motivated in Section 6.4 of [I-D.ietf-pana-threats-eval] it might As motivated in Section 6.4 of [I-D.ietf-pana-threats-eval] it might
be necessary to establish either a link layer or a network layer be necessary to establish either a link layer or a network layer
protection to prevent certain thefts in certain scenarios. protection to prevent certain thefts in certain scenarios.
Threats specific to the establishment of a link layer or a network Threats specific to the establishment of a link layer or a network
layer security association are outside the scope of PANA. The layer security association are outside the scope of PANA. The
interested reader should refer to the relevant working groups such as interested reader should refer to the relevant working groups such as
IPsec or Midcom. IPsec or Midcom.
g) Liveness test g) Liveness test
Network access authentication is done for a very specific purpose and Network access authentication is done for a very specific purpose and
often charging procedures are involved which allow restricting often charging procedures are involved which allow restricting
network resource usage based on some policies. In mobile environments network resource usage based on some policies. In mobile
it is always possible that an end host suddenly disconnects without environments it is always possible that an end host suddenly
transmitting a disconnect message. Operators are generally motivated disconnects without transmitting a disconnect message. Operators are
to detect a disconnected end host as soon as possible in order to generally motivated to detect a disconnected end host as soon as
release resources (i.e., garbage collection). The PAA can remove possible in order to release resources (i.e., garbage collection).
per-session state information including installed security The PAA can remove per-session state information including installed
association, packet filters, etc. security association, packet filters, etc.
Different procedures can be used for disconnect indication. PANA Different procedures can be used for disconnect indication. PANA
cannot assume link-layer disconnect indication. Hence this cannot assume link-layer disconnect indication. Hence this
functionality has to be provided at a higher layer. With this version functionality has to be provided at a higher layer. With this
of the draft we suggest to apply the soft-state principle found at version of the draft we suggest to apply the soft-state principle
other protocols (such as RSVP). Soft-state means that session state found at other protocols (such as RSVP). Soft-state means that
is kept alive as long as refresh messages refresh the state. If no session state is kept alive as long as refresh messages refresh the
new refresh messages are provided then the state automatically times state. If no new refresh messages are provided then the state
out and resources are released. This process includes stopping automatically times out and resources are released. This process
accounting procedures. includes stopping accounting procedures.
A PANA session is associated with a session lifetime. The session is A PANA session is associated with a session lifetime. The session is
terminated unless it is refreshed by a new round of EAP terminated unless it is refreshed by a new round of EAP
authentication before it expires. Therefore, at the latest a authentication before it expires. Therefore, at the latest a
disconnected client can be detected when its lifetime expires. A disconnected client can be detected when its lifetime expires. A
disconnect may also be detected earlier by using PANA disconnect may also be detected earlier by using PANA
reauthentication messages. A request message can be generated by reauthentication messages. A request message can be generated by
either PaC or PAA at any time and the peer must respond with an either PaC or PAA at any time and the peer must respond with an
answer message. A successful round-trip of this exchange is a simple answer message. A successful round-trip of this exchange is a simple
verification that the peer is alive. This test can be engaged when verification that the peer is alive. This test can be engaged when
there is a possibility that the peer might have disconnected (e.g., there is a possibility that the peer might have disconnected (e.g.,
after discontinuation of data traffic). Periodic use of this exchange after discontinuation of data traffic). Periodic use of this
as a keep-alive requires additional care as it might result in exchange as a keep-alive requires additional care as it might result
congestion and hence false alarms. This exchange is cryptographically in congestion and hence false alarms. This exchange is
protected when PANA SA is available in order to prevent threats cryptographically protected when PANA SA is available in order to
associated with the abuse of this functionality. prevent threats associated with the abuse of this functionality.
h) Tear-Down message h) Tear-Down message
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. This message causes state removal, a to transmit a tear-down message. This message causes state removal,
stop of the accounting procedure and removes the installed packet a stop of the accounting procedure and removes the installed packet
filters. filters.
It is obvious that such a message must be protected to prevent an It is obvious that such a message must be protected to prevent an
adversary from deleting state information and thereby causing denial adversary from deleting state information and thereby causing denial
of service attacks. of service attacks.
12. Open Issues i) Mobility optimization
A list of open issues is maintained at [1].
The remaining issues for -01 version of draft are: None.
The remaining issues for -02 version of draft are: None. The mobility optimization described in Section 4.9 involves the
previous PAA providing a AAA-Key to the current PAA of the PaC.
There are security risks stemming from potential compromise of PAAs.
Compromise of the current PAA does not yield compromise of the
previous PAA, as AAA-Key cannot be computed from a compromised
AAA-Key-new. But a compromised previous PAA along with the
intercepted nonce values leads to the compromise of AAA-Key-new.
Operators should be aware of the potential risk of using this
optimization. An operator can reduce the risk exposure by forcing
the PaC to perform an EAP-based authentication immediately after the
optimized PANA execution.
The remaining issues for -xx version of draft are: 28, 52, 53, 54, 10. Open Issues and Change History
55, 56, 57, 58 and 59.
13. Change History A list of open issues is maintained at [2].
Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11. Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11.
Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21, Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21,
22, 23, 24, 25, 26, 30, 31, 32 and 33. 22, 23, 24, 25, 26, 30, 31, 32 and 33.
Issues incorporated in PANA-03 February 2004: 2, 16, 34, 35, 36, 38, Issues incorporated in PANA-03 February 2004: 2, 16, 34, 35, 36, 38,
39, 40, 42, 43, 44, 50, 51 and 60. 39, 40, 42, 43, 44, 50, 51 and 60.
14. Acknowledgments Issues incorporated in PANA-04 May 2004: 28, 52, 53, 56, 57, 58, 59,
61, 62, 63, 64, 65, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80 and 83.
We would like to thank all members of the PANA working group for 11. Acknowledgments
their comments to this document.
We would like to thank Jari Arkko, Mohan Parthasarathy, Julien
Bournelle, Rafael Marin Lopez and all members of the PANA working
group for their valuable comments to this document.
Normative References 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
2131, March 1997.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[I-D.ietf-eap-rfc2284bis] [I-D.ietf-eap-rfc2284bis]
Blunk, L., "Extensible Authentication Protocol (EAP)", Blunk, L., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-07 (work in progress), December draft-ietf-eap-rfc2284bis-09 (work in progress), February
2003. 2004.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999. Protocol", RFC 2716, October 1999.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D. 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. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
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 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "EAP Key Management Framework", Aboba, B., "EAP Key Management Framework",
draft-ietf-eap-keying-01 (work in progress), October 2003. draft-ietf-eap-keying-01 (work in progress), October 2003.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Informative References Informative References
[I-D.ietf-pana-requirements] [I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements", Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-07 (work in progress), June draft-ietf-pana-requirements-07 (work in progress), June
2003. 2003.
[I-D.ietf-aaa-eap] [I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-03 (work in progress), October 2003. draft-ietf-aaa-eap-05 (work in progress), April 2004.
[I-D.puthenkulam-eap-binding] [I-D.puthenkulam-eap-binding]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in Problem", draft-puthenkulam-eap-binding-04 (work in
progress), October 2003. progress), October 2003.
[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-usage-scenarios] [I-D.ietf-pana-usage-scenarios]
  Skipping to change at page 49, line 290:
PANA", draft-ietf-pana-usage-scenarios-06 (work in PANA", draft-ietf-pana-usage-scenarios-06 (work in
progress), April 2003. progress), April 2003.
[I-D.ietf-pana-threats-eval] [I-D.ietf-pana-threats-eval]
Parthasarathy, M., "PANA Threat Analysis and security Parthasarathy, M., "PANA Threat Analysis and security
requirements", draft-ietf-pana-threats-eval-04 (work in requirements", draft-ietf-pana-threats-eval-04 (work in
progress), May 2003. progress), May 2003.
[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-01 (work in progress), Control", draft-ietf-pana-ipsec-03 (work in progress), May
January 2004. 2004.
[I-D.ietf-pana-framework]
Jayaraman, P., "PANA Framework",
draft-ietf-pana-framework-00 (work in progress), May 2004.
[I-D.ietf-pana-snmp]
Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in
progress), April 2004.
[I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Experimental Handoff Extension
to RADIUS", draft-irtf-aaaarch-handoff-04 (work in
progress), November 2003.
[I-D.ietf-eap-statemachine]
Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator",
draft-ietf-eap-statemachine-03 (work in progress), March
2004.
[I-D.ietf-seamoby-ctp] [I-D.ietf-seamoby-ctp]
Loughney, J., "Context Transfer Protocol", Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-08 (work in progress), January draft-ietf-seamoby-ctp-08 (work in progress), January
2004. 2004.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-13 (work in progress), March 2004.
[I-D.josefsson-pppext-eap-tls-eap] [I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D. and G. Zorn, Josefsson, S., Palekar, A., Simon, D. and G. Zorn,
"Protected EAP Protocol (PEAP)", "Protected EAP Protocol (PEAP)",
draft-josefsson-pppext-eap-tls-eap-07 (work in progress), draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
October 2003. October 2003.
[I-D.ietf-pppext-eap-ttls] [I-D.ietf-pppext-eap-ttls]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)", Authentication Protocol (EAP-TTLS)",
draft-ietf-pppext-eap-ttls-03 (work in progress), August draft-ietf-pppext-eap-ttls-04 (work in progress), April
2003. 2004.
[I-D.tschofenig-eap-ikev2] [I-D.tschofenig-eap-ikev2]
Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method
(EAP-IKEv2)", draft-tschofenig-eap-ikev2-02 (work in (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in
progress), October 2003. progress), February 2004.
[ianaweb] IANA, "Number assignment", http://www.iana.org. [ianaweb] IANA, "Number assignment", http://www.iana.org.
[jb99] Juels, A. and J. Brainard, "Client Puzzles: A [jb99] Juels, A. and J. Brainard, "Client Puzzles: A
Cryptographic Defense Against Connection Depletion Cryptographic Defense Against Connection Depletion
Attacks", Proceedings of NDSS '99 (Networks and Attacks", Proceedings of NDSS '99 (Networks and
Distributed Security Systems), pages 151-165, 1999. Distributed Security Systems), pages 151-165, 1999.
[mitm] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-middle in [mitm] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-middle in
tunnelled authentication", In the Proceedings of the 11th tunnelled authentication", In the Proceedings of the 11th
International Workshop on Security Protocols, Cambridge, International Workshop on Security Protocols, Cambridge,
UK, April 2003. UK, April 2003.
[802.11i] Institute of Electrical and Electronics Engineers, "Draft [802.11i] Institute of Electrical and Electronics Engineers, "Draft
supplement to standard for telecommunications and supplement to standard for telecommunications and
information exchange between systems - lan/man specific information exchange between systems - lan/man specific
requirements - part 11: Wireless medium access control requirements - part 11: Wireless medium access control
(mac) and physical layer (phy) specifications: (mac) and physical layer (phy) specifications:
Specification for enhanced security", IEEE 802.11i/D7.0, Specification for enhanced security", IEEE 802.11i/D10.0,
2003. 2004.
[802.11] Institute of Electrical and Electronics Engineers, [802.11] Institute of Electrical and Electronics Engineers,
"Information technology - telecommunications and "Information technology - telecommunications and
information exchange between systems - local and information exchange between systems - local and
metropolitan area networks - specific requirements part metropolitan area networks - specific requirements part
11: Wireless lan medium access control (mac) and physical 11: Wireless lan medium access control (mac) and physical
layer (phy) specifications", IEEE Standard 802.11, layer (phy) specifications", IEEE Standard 802.11,
1999(R2003). 1999(R2003).
URIs URIs
[1] <http://danforsberg.info:8080/pana-issues/> [1] <http://www.toshiba.com/tari/pana/sequence-number.txt>
[2] <http://danforsberg.info:8080/pana-issues/>
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 Information Systems, Inc. Toshiba America Research, Inc.
9740 Irvine Blvd. 1 Telcordia Drive
Irvine, CA 92619-1697 Piscataway, NJ 08854
USA USA
Phone: +1 973 829 5174 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
DoCoMo USA Labs Samsung Advanced Institute of Technology
181 Metro Drive, Suite 300 75 West Plumeria Drive
San Jose, CA 95110 San Jose, CA 95134
USA USA
Phone: +1 408 451 4743 Phone: +1 408 544 5656
EMail: alper@docomolabs-usa.com EMail: alper.yegin@samsung.com
Appendix A. Adding sequence number to PANA for carrying EAP
Appendix A.1 Why is sequence number needed for PANA to carry EAP?
EAP [I-D.ietf-eap-rfc2284bis] requires underlying transports to
provide ordered-delivery of messages. If an underlying transport
does not satisfy the ordering requirement, the following situation
could happen:
EAP Peer EAP Authenticator
--------------------------------------------
1. (got req 1) <------- Request ID=1
2. Response ID=1 ---+
| (timeout)
3. | +-- Request ID=1
| |
+-|--> (got resp 1)
4. (got req 2) <----|-- Request ID=2
|
5. Response ID=2 -----|--> (got resp 2)
|
6. (got req 1) <----+
7. Response ID=1 --------> [discarded due to unexpected ID]
Figure 11: Undesirable scenario
In Figure 11, the second EAP Request message with Identifier=1
arrives at the EAP peer after the third EAP Request message with
Identifier=2. As a result, the EAP peer accepts the second EAP
Request as a new EAP Request while it is just an old EAP Request that
was already responded and the authentication might be totally messed
up.
This problem occurs due to the fact that EAP doesn't recognize
duplicate packets in the scope of one EAP protocol run, but only in
the scope of current and previous packet (i.e., request and response
message matching). When EAP is running over PPP or IEEE 802 links,
this is not a problem, because those link-layers have the ordering
invariant characteristic.
On the other hand, the PANA design has chosen UDP as its transport.
Given that UDP does not provide ordered delivery of packets and PANA
does not assume any specific link-layer technology to carry EAP, PANA
messages need to have a sequence number.
In the following text we describe two possible approaches for
sequence number handling in PANA. The first one makes use of a
single sequence number whereas the latter utilizes two. Finally a
comparison between the two approaches is provided. The method
described in Appendix A.3.1 (i.e., the dual sequence number with
orderly-delivery method) is suggested as the preferred method for
PANA transport.
Appendix A.2 Single sequence number approach
This section discusses several methods based on using a single
sequence number for providing orderly message delivery. Sequence
number handling for all methods discussed in Appendix A.2 must comply
to the following rules:
Rule 1: The sequence number starts from initial sequence number (ISN)
and is monotonically increased by 1. The arithmetic defined
in [RFC1982] is used for sequence number operation.
Rule 2: When a PAA sends an EAP message passed from EAP layer to a
PaC, a new sequence number is placed in the message,
regardless of whether it is sent as a result of a
retransmission at the EAP layer or not.
Note: It might be possible to define other mechanisms for sequence
number handling if it can be assumed that a PAA detects EAP
retransmissions. However, such an assumption heavily depends on EAP
implementation details in particular on EAP APIs, thus it was decided
not to use such an assumption.
Appendix A.2.1 Single sequence number with EAP retransmission method
Again, the following rules must hold:
Rule 3: Use EAP layer retransmission for retransmitting EAP messages
(based on a timer expiration).
Rule 4: When the PaC receives a message from the PAA, it checks the
sequence number and discards the message if the sequence
number is not greater than that of the last accepted message.
Rule 5: When the PAA receives a message from the PaC, it checks the
sequence number and discards the message if the sequence
number does not match a pending request message.
PaC PAA Seq# Message
--------------------------------------------
1. <------- (x) PANA-Auth-Request[EAP Req ID=1]
2. ---+ (x) PANA-Auth-Answer[EAP Res ID=1]
| (retransmission timeout at EAP-layer)
3. | +-- (x+1) PANA-Auth-Request[EAP Req ID=1]
| |
+-|--> (discarded due to Rule 5)
| (retransmission timeout at EAP-layer)
4. <----|-- (x+2) PANA-Auth-Request[EAP Req ID=1]
|
5. -----|--> (x+2) PANA-Auth-Answer[EAP Res ID=1]
|
6. <----+ (discarded due to Rule 4)
7. <------- (x+3) PANA-Auth-Request[EAP Req ID=2]
.
.
Figure 12: Example for Single sequence number with EAP retransmission
This method is vulnerable to a blind DoS attack on the sequence
number since the PaC will accept quite a wide range of sequence
numbers. For example, if an attacker blindly sends a bogus message
to a legitimate PaC with a randomly chosen sequence number, it will
be accepted by the PaC with 50% probability, and once this happens,
all messages sent from the communicating PAA will be discarded as
long as they have a sequence number smaller than the accepted value.
The problem of this method leads to a requirement for PaC to have a
narrow range of acceptable sequence numbers to make the blind DoS
attack difficult. Note that the DoS attack cannot be prevented if the
attacker is on the same IP link as PaC and able to eavesdrop the PANA
conversation. However, the attacker needs to put itself in
promiscuous mode and thus spend more resources to eavesdrop and
launch the attack (in other words, non-blind DoS attack is still
possible as long as sequence numbers are unprotected.)
Appendix A.2.2 Single sequence number with PANA-layer retransmission
method
The next method is still based on using a single sequence number but
the PANA-layer takes the responsibility of retransmission. The
method uses the following rules in addition to the common rules
described in Appendix A.2.
Rule 3: Use PANA-layer retransmission for retransmitting both EAP and
non-EAP messages (based on a timer expiration). EAP layer
retransmission is turned off. Retransmission based on timer
occurs both on PaC and PAA side, but not on both sides
simultaneously. PAA does retransmission at least for
PANA_Termination and PANA_Reauth messages, otherwise PaC
takes care of retransmission.
Rule 4: When the PaC receives a message from the PAA, it accepts the
message if the sequence number is equal to that of the last
accepted message + 1. If the sequence number is equal to
that of the last accepted message, the PaC retransmits the
last transmitted message. Otherwise, it silently discards
the message.
Rule 5: When the PAA receives a message from the PaC, it accepts the
message if the sequence number is equal to that of the last
transmitted message. If the receiving sequence number is
equal to that of the last transmitted message - 1, the PAA
retransmits the last transmitted message and discard the
received message. Otherwise, it silently discards the
message.
Rule 6: The PaC retransmits the last transmitted EAP Response until a
new EAP Request message or an EAP Success/Failure message is
received and accepted.
Rule 7: PAA must keep the copy of the last transmitted message and
must be able to retransmit it until either a valid message is
received and accepted by the PAA or a timer expires. The
timer is used if no new message will be sent from the PaC.
PaC PAA Seq# Message
--------------------------------------------
1. <-------- (x) PANA-Auth-Request[EAP Req ID=1]
2. ---+ (x) PANA-Auth-Answer[EAP Resp ID=1]
| (retransmission timeout at PaC)
3. ---|----> (x) PANA-Auth-Answer[EAP Resp ID=1]
4. | +--- (x+1) PANA-Auth-Request[EAP Req ID=2]
| |
+-|--> (duplicate detected)
5. <----|--- (x+1) PANA-Auth-Request[EAP Req ID=2]
|
6. -----|--> (x+1) PANA-Auth-Answer[EAP Resp ID=2]
|
<----|--- (x+2) PANA-Auth-Request[EAP Req ID=3]
7. -----|--> (x+2) PANA-Auth-Answer[EAP Resp ID=3]
<----+ (discarded by PaC)
(retransmission timeout at PaC)
8. --------> (x+2) PANA-Auth-Answer[EAP Resp ID=3]
9. lost<---- (x+3) PANA-Auth-Request[EAP Succ ID=3]
(retransmission timeout at PaC)
10.---->lost (x+2) PANA-Auth-Answer[EAP Resp ID=3]
(retransmission timeout at PaC)
11.--------> (x+2) PANA-Auth-Answer[EAP Resp ID=3]
12.<-------- (x+3) PANA-Bind-Request[EAP Succ ID=3]
(retransmission timer stopped at PaC)
(deletion timeout at PAA)
(message (x+3) deleted at PAA)
13.lost<---- (x+4) PANA-Termination-Request
(retransmission timeout at PAA)
14.<-------- (x+4) PANA-Termination-Request
15.---->lost (x+4) PANA-Termination-Answer
(retransmission timeout at PAA)
16.<-------- (x+4) PANA-Termination-Request
17.--------> (x+4) PANA-Termination-Answer
(retransmission timer stopped at PAA)
Figure 13: Example for Single sequence number with PANA-layer
retransmission
This method has an advantage of eliminating EAP layer retransmission
by providing reliability at the PANA layer. Retransmission at the EAP
layer has a problem with determining an appropriate retransmission
timer value, which occurs when the lower-layer is unreliable. In
this case an EAP authenticator cannot distinguish between (i) EAP
Request or EAP Response message loss (in this case the retransmission
timer should be calculated based on network characteristics) and (ii)
long latency for EAP Response generation due to e.g., user input etc.
(in this case the retransmission timer should be calculated based on
user or application characteristics). In general, the retransmission
timer for case (ii) is longer than that for case (i). If case (i)
happens while the retransmission timer is calculated based on user or
application characteristics, then it might frustrate an end user
since the completion of the authentication procedure takes
unnecessarily long. If case (ii) happens while the retransmission
timer is calculated based on network characteristics (i.e., RTT),
then unnecessarily traffic is generated by retransmission. Note that
in this method a PaC still cannot distinguish case (i) and case (iii)
the EAP authenticator or a backend authentication server is taking
time to generate an EAP Request.
A problem of this method is that it is based on the assumption that
EAP authenticator does not send a new EAP message until an EAP
Response to the outstanding EAP Request is received. However, this
assumption does not hold at least EAP Success/Failure message which
does not need the outstanding EAP Request to be responded before
sending the EAP Success/Failure message. This would require
timer-based retransmission not only at PaC side but also at PAA side.
Another problem occurs when a new EAP message overrides the
outstanding EAP Request, the PaC cannot assume any more that the
sequence number of the next message to be accepted is the last
accepted message + 1. So the PaC needs to accept a range of sequence
numbers, instead of a single sequence number. These two additional
things would increase the complexity of this method.
Appendix A.3 Dual sequence number approach
Based on the analysis of previous schemes, it is recognized that two
sequence numbers are needed anyway, one for each direction. Two
different methods are proposed based on this approach. Both methods
have the following rules in common.
Rule 1: A PANA packet carries two sequence numbers: transmitted
sequence number (tseq) and received sequence number (rseq).
tseq starts from initial sequence number (ISN) and is
monotonically increased by 1. The arithmetic defined in
[RFC1982] is used for sequence number operation. It is
assumed that the two sequence numbers have the same length
for simplicity.
Rule 2: When PAA or PAC sends a new message, a new sequence number is
placed on the tseq field of message. Every transmitted
message is given a new sequence number.
Rule 3: When a message is sent from PaC or PAA, rseq is copied from
the tseq field of the last accepted message.
Rule 4: For messages which experience a PANA layer retransmission,