draft-ietf-pana-pana-02.txt   draft-ietf-pana-pana-03.txt 
PANA Working Group D. Forsberg PANA Working Group D. Forsberg
Internet-Draft Nokia Internet-Draft Nokia
Expires: April 23, 2004 Y. Ohba Expires: August 9, 2004 Y. Ohba
Toshiba Toshiba
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
A. Yegin A. Yegin
DoCoMo USA Labs DoCoMo USA Labs
October 24, 2003 February 9, 2004
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-02 draft-ietf-pana-pana-03
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 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 April 23, 2004. This Internet-Draft will expire on August 9, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). 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 . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . 9
4.1 Common Processing Rules . . . . . . . . . . . . . . . . . 8 4.1 Common Processing Rules . . . . . . . . . . . . . . . . . 9
4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 8 4.1.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . 8 4.1.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . 10
4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 10
4.1.4 Sequence Number and Retransmission . . . . . . . . . . . . 9 4.1.4 Sequence Number and Retransmission . . . . . . . . . . . . 10
4.1.5 PANA Security Association . . . . . . . . . . . . . . . . 10 4.1.5 PANA Security Association . . . . . . . . . . . . . . . . 11
4.1.6 Message Authentication Code . . . . . . . . . . . . . . . 11 4.1.6 Message Authentication Code . . . . . . . . . . . . . . . 12
4.1.7 Message Validity Check . . . . . . . . . . . . . . . . . . 11 4.1.7 Message Validity Check . . . . . . . . . . . . . . . . . . 13
4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 4.1.8 Error Handling . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 12 4.2 Discovery and Initial Handshake Phase . . . . . . . . . . 14
4.3 Authentication Phase when PANA-PAA-Discover is sent by 4.3 Authentication Phase . . . . . . . . . . . . . . . . . . . 17
EP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 19
4.4 Re-authentication . . . . . . . . . . . . . . . . . . . . 17 4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 20
4.5 Termination Phase . . . . . . . . . . . . . . . . . . . . 18 4.6 Illustration of a Complete Message Sequence . . . . . . . 21
4.6 Illustration of a Complete Message Sequence . . . . . . . 18 4.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 22
4.7 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 20 4.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 22
4.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 20 4.9 Mobility Handling . . . . . . . . . . . . . . . . . . . . 23
4.9 Mobility Handling . . . . . . . . . . . . . . . . . . . . 21 4.10 Event Notification . . . . . . . . . . . . . . . . . . . . 24
4.10 Event Notification . . . . . . . . . . . . . . . . . . . . 22 4.11 Support for Separate EP . . . . . . . . . . . . . . . . . 24
4.11 PaC Implications . . . . . . . . . . . . . . . . . . . . . 22 5. PANA Security Association Establishment . . . . . . . . . 25
4.12 PAA Implications . . . . . . . . . . . . . . . . . . . . . 22 6. Authentication Method Choice . . . . . . . . . . . . . . . 26
5. PANA Security Association Establishment . . . . . . . . . 23 7. Filter Rule Installation . . . . . . . . . . . . . . . . . 27
6. Authentication Method Choice . . . . . . . . . . . . . . . 24 8. Data Traffic Protection . . . . . . . . . . . . . . . . . 28
7. Filter Rule Installation . . . . . . . . . . . . . . . . . 25 9. Message Formats . . . . . . . . . . . . . . . . . . . . . 29
8. Data Traffic Protection . . . . . . . . . . . . . . . . . 26 9.1 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 29
9. Message Formats . . . . . . . . . . . . . . . . . . . . . 27 9.2 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 27 9.3 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 32
9.2 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 28 9.3.1 Message Specifications . . . . . . . . . . . . . . . . . . 33
9.3 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 30 9.3.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 33
9.3.1 Message Specifications . . . . . . . . . . . . . . . . . . 31 9.3.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 33
9.3.2 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . . . 31 9.3.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 33
9.3.3 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 31 9.3.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 34
9.3.4 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 31 9.3.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 34
9.3.5 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 32 9.3.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 34
9.3.6 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 32 9.3.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 35
9.3.7 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 32 9.3.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 35
9.3.8 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 33 9.3.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 35
9.3.9 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . . 33 9.3.11 PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 35
9.3.10 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . . . 33 9.3.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 36
9.3.11 PANA-Termination-Request (PTR) . . . . . . . . . . . . . . 33 9.3.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . . . . 36
9.3.12 PANA-Termination-Answer (PTA) . . . . . . . . . . . . . . 34 9.4 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 36
9.3.13 PANA-Error (PER) . . . . . . . . . . . . . . . . . . . . . 34 9.4.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.4 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 34 9.4.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 37
9.4.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.4.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 37
9.4.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . . . 35 9.4.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 38
9.4.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . . . 35 9.4.5 Protection-Capability AVP . . . . . . . . . . . . . . . . 38
9.4.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . . 35 9.4.6 Termination-Cause AVP . . . . . . . . . . . . . . . . . . 38
9.4.5 Protection-Capability AVP . . . . . . . . . . . . . . . . 36 9.4.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 38
9.4.6 Termination-Cause AVP . . . . . . . . . . . . . . . . . . 36 9.4.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 42
9.4.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 36 9.4.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 42
9.4.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . . . 39 9.4.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 42
9.4.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . . . 39 9.4.11 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 42
9.4.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . . 39 9.4.12 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 42
9.4.11 NAP-Information AVP . . . . . . . . . . . . . . . . . . . 40 9.4.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . . 42
9.4.12 ISP-Information AVP . . . . . . . . . . . . . . . . . . . 40 9.4.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 43
9.4.13 Provider-Identifier AVP . . . . . . . . . . . . . . . . . 40 9.4.15 EP-Device-Id AVP . . . . . . . . . . . . . . . . . . . . . 43
9.4.14 Provider-Name AVP . . . . . . . . . . . . . . . . . . . . 40 9.4.16 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . . 43
9.5 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 40 9.5 AVP Occurrence Table . . . . . . . . . . . . . . . . . . . 43
10. PANA Protocol Message Retransmissions . . . . . . . . . . 43 10. PANA Protocol Message Retransmissions . . . . . . . . . . 45
10.1 Transmission and Retransmission Parameters . . . . . . . . 45 10.1 Transmission and Retransmission Parameters . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . 48
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 52 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 53
13. Change History . . . . . . . . . . . . . . . . . . . . . . 53 13. Change History . . . . . . . . . . . . . . . . . . . . . . 54
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 54 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 55
Normative References . . . . . . . . . . . . . . . . . . . 55 Normative References . . . . . . . . . . . . . . . . . . . 56
Informative References . . . . . . . . . . . . . . . . . . 58 Informative References . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 59
A. Adding sequence number to PANA for carrying EAP . . . . . 61 A. Adding sequence number to PANA for carrying EAP . . . . . 61
A.1 Why is sequence number needed for PANA to carry EAP? . . . 61 A.1 Why is sequence number needed for PANA to carry EAP? . . . 61
A.2 Single sequence number approach . . . . . . . . . . . . . 62 A.2 Single sequence number approach . . . . . . . . . . . . . 62
A.2.1 Single sequence number with EAP retransmission method . . 62 A.2.1 Single sequence number with EAP retransmission method . . 62
A.2.2 Single sequence number with PANA-layer retransmission A.2.2 Single sequence number with PANA-layer retransmission
method . . . . . . . . . . . . . . . . . . . . . . . . . . 63 method . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.3 Dual sequence number approach . . . . . . . . . . . . . . 66 A.3 Dual sequence number approach . . . . . . . . . . . . . . 66
A.3.1 Dual sequence number with orderly-delivery method . . . . 66 A.3.1 Dual sequence number with orderly-delivery method . . . . 66
A.3.2 Dual sequence number with reliable-delivery method . . . . 68 A.3.2 Dual sequence number with reliable-delivery method . . . . 68
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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.
Currently there is no standard network-layer solution for Currently there is no standard network-layer solution for
authenticating clients for network access. authenticating clients for network access.
[I-D.ietf-pana-usage-scenarios] describes the problem statement that [I-D.ietf-pana-usage-scenarios] describes the problem statement that
led to the development of PANA. led to the development of PANA.
Scope of this working group is identified as designing a link-layer Scope of this work is identified as designing a link-layer agnostic
agnostic transport for network access authentication methods. PANA transport for network access authentication methods. The Extensible
Working Group has identified EAP [RFC2284] as the payload for this Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] provides such
protocol and carrier for authentication methods. In other words, PANA authentication methods. In other words, PANA will carry EAP which
will carry EAP which can carry various authentication methods. By can carry various authentication methods. By the virtue of enabling
the virtue of enabling transport of EAP above IP, any authentication transport of EAP above IP, any authentication method that can be
method that can be carried as an EAP method is made available to PANA carried as an EAP method is made available to PANA and hence to any
and hence to any link-layer technology. There is a clear division of link-layer technology. There is a clear division of labor between
labor between PANA, EAP and EAP methods. PANA, EAP and EAP methods.
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 is discussed threats for network-layer access authentication protocol are
in [I-D.ietf-pana-threats-eval] draft. These two drafts have been discussed in [I-D.ietf-pana-threats-eval] draft. These two drafts
essential in defining the requirements [I-D.ietf-pana-requirements] have been essential in defining the requirements
on the PANA protocol. Note that some of these requirements are [I-D.ietf-pana-requirements] on the PANA protocol. Note that some of
imposed by the chosen payload, EAP [RFC2284]. these requirements are imposed by the chosen payload, EAP
[I-D.ietf-eap-rfc2284bis].
This Internet-Draft makes an attempt for defining the PANA protocol 1.1 Specification of Requirements
based on the other drafts discussed above. Special care has been
given to ensure the currently stated scope is observed and to keep In this document, several words are used to signify the requirements
the protocol as simple as possible. The current state of this draft of the specification. These words are often capitalized. The key
is not complete, but it should be regarded as a work in progress. words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
The authors made effort to capture the common understanding developed "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
within the working group as much as possible. The design choices are to be interpreted as described in [RFC2119].
being made in this draft should not be considered as cast in stone.
2. Terminology 2. Terminology
This section describes some terms introduced in this document: This section describes some terms introduced in this document:
PANA Session: PANA Session:
PANA session is defined as the exchange of messages between the PANA session is defined as the exchange of messages between the
PANA Client (PaC) and the PANA Authentication Agent (PAA) to PANA Client (PaC) and the PANA Authentication Agent (PAA) to
authenticate a user (PaC) for network access. If the authenticate a user (PaC) for network access. If the
authentication is unsuccessful, the session is terminated. The authentication is unsuccessful, the session is terminated. The
session is considered as active until there is a disconnect session is considered as active until there is a disconnect
indication by the PaC or the PAA terminates it. indication by the PaC or the PAA terminates it. A distinct PANA
session is associated with a pair of device identifiers of PaC and
PAA. For example, if the PaC has two interfaces connected to the
same IP link with different IP addresses and IP address is used as
a device identifier, a distinct PANA session will be created per
interface if both interfaces addresses need to be authorized for
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 The representation of the trust relation between the PaC and the
PAA that is created at the end of the authentication phase. This PAA that is created at the end of the authentication phase. This
security association includes the device identifier of the peer, security association includes the device identifier of the peer,
and a shared key when available. and a shared key when available.
The definition of the terms PANA Client (PaC), PANA Authentication PANA Client (PaC):
Agent (PAA), Enforcement Point (EP) and Device Identifier (DI) can be
found in [I-D.ietf-pana-requirements]. The client side of the protocol that resides in the host device
which is responsible for providing the credentials to prove its
identity for network access authorization.
Device Identifier (DI):
The identifier used by the network as a handle to control and
police the network access of a client. Depending on the access
technology, this identifier might contain any of IP address,
link-layer address, switch port number, etc. of a connected
device.
PANA Authentication Agent (PAA):
The access network side entity of the protocol whose
responsibility is to verify the credentials provided by a PANA
client and grant network access service to the device associated
with the client and identified by a DI.
Enforcement Point (EP):
A node on the access network where per-packet enforcement policies
(i.e., filters) are applied on the inbound and outbound traffic of
client devices. Information such as DI and (optionally)
cryptographic keys are provided by PAA per client for constructing
filters on the EP.
Network Access Provider (NAP):
A service provider that provides physical and link-layer
connectivity to an access network it manages.
AAA-Key:
A key derived by the EAP peer and EAP server and transported to
the authenticator [I-D.ietf-eap-keying].
3. Protocol Overview 3. Protocol Overview
The PANA protocol involves two functional entities namely the PaC and The PANA protocol involves two functional entities namely the PaC and
the PAA. The EP, mentioned in the context with PANA, is a logical the PAA. The protocol resides above the transport layer and the
entity. There is, however, the option that the EP is not physically details are explained in Section 4.
co-located with the PAA. In case that the PAA and the EP are
co-located only an API is required for intercommunication instead of
a separate protocol. In the case where the PAA is separated from the
EP, a separate protocol will be used between the PAA and the EP for
managing access control. The protocol and messaging between the PAA
and EP for access authorization is outside the scope of this draft
and will be dealt separately.
The PANA protocol (PaC<->PAA) resides above the transport layer and
the details are explained in Section 4. Although this document
describes the interaction with a number of entities and with other
protocol which enable network access authentication; the PANA
protocol itself is executed between the PaC and the PAA.
The placement of the entities used in PANA largely depends on a The placement of the entities used in PANA largely depends on a
certain architecture. The PAA may optionally interact with a AAA certain architecture. The PAA may optionally interact with a AAA
backend to authenticate the user (PaC). And in the case where the PAA backend to authenticate the user (PaC). The EP, mentioned in the
and EP are co-located, the intercommunication may not require a context with PANA, is a logical entity. There is, however, the option
separate protocol. Figure 1 illustrates the interactions in a that the EP is not physically co-located with the PAA. In case that
simplified manner: the PAA and the EP are co-located only an API is required for
intercommunication instead of a separate protocol. In the case where
the PAA is separated from the EP, a separate protocol will be used
between the PAA and the EP for managing access control. The protocol
and messaging between the PAA and EP for access authorization is
outside the scope of this draft and will be dealt separately. Figure
1 illustrates the interactions in a simplified manner:
PaC EP PAA AAA PaC EP PAA AAA
--- --- --- --- --- --- --- ---
PAA Discovery PAA Discovery
<---------------------o------------> (1) <---------------------o------------> (1)
PANA Authentication AAA interaction PANA Authentication AAA interaction
<----------------------------------><------------> (2) <----------------------------------><------------> (2)
Authorization Authorization
<------------- (3) <------------- (3)
Figure 1: PANA Framework Figure 1: PANA Framework
The details of each of these aspects of the protocol are described in PANA supports authentication of a PaC using various EAP methods. The
Section 4 of this document. PANA supports authentication of a PaC EAP method used depends on the level of security required for the EAP
using various EAP methods. The EAP method used depends on the level messaging itself. PANA does not secure the data traffic itself.
of security required for the EAP messaging itself. PANA does not However, EAP methods that enable key exchange may allow other
secure the data traffic itself. However, EAP methods that enable key protocols to be bootstrapped for securing the data traffic
exchange may allow other protocols to be bootstrapped for securing [I-D.ietf-pana-ipsec].
the data traffic [I-D.ietf-pana-ipsec].
From a state machine aspect, PANA protocol consists of three phases From a state machine aspect, PANA protocol consists of three phases
1. Discovery and initial handshake phase 1. Discovery and initial handshake phase
2. Authentication phase 2. Authentication phase
3. Termination phase 3. Termination phase
In the first phase, an IP address of PAA is discovered and a PANA In the first phase, an IP address of PAA is discovered and a PANA
session is established between PaC and PAA. EAP messages are session is established between PaC and PAA. EAP messages are
exchanged and a PANA SA is established in the second phase. The exchanged and a PANA SA is established in the second phase. The
established PANA session as well as a PANA SA is deleted in the third established PANA session as well as a PANA SA is deleted in the third
skipping to change at page 8, line 28 skipping to change at page 9, line 28
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 EAP AVP: contains an EAP PDU. o EAP AVP: contains an EAP PDU.
o MAC AVP: contains a Message Authentication Code that protects a o MAC AVP: contains a Message Authentication Code that protects a
PANA message PDU. PANA message PDU.
o Termination-Cause AVP: contains the reason of session termination. o Termination-Cause AVP: contains the reason of session termination.
o Result-Code AVP: contains information about the protocol execution o Result-Code AVP: contains information about the protocol execution
results. results.
o Session-Id AVP: contains the session identifier value. o Session-Id AVP: contains the session identifier value.
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.
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 MAY use unspecified IP address for communicating with unicast. PaC MUST NOT use unspecified IP address for communicating
PAA. with 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
skipping to change at page 10, line 8 skipping to change at page 11, line 13
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 10 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 Master Session Key (MSK) authentication succeeds with a creation of a AAA-Key. A PANA SA is
[I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA not created when the PANA authentication fails or no AAA-Key is
authentication fails or no MSK is produced by any EAP authentication produced by any EAP authentication method. In the case where two EAP
method. In the case where two EAP authentications are performed in a authentications are performed in a sequence in a single PANA
sequence in a single PANA authentication, it is possible that two authentication, it is possible that two AAA-Keys are derived. If this
MSKs are derived. If this happens, the PANA SA MUST be bound to the happens, the PANA SA MUST be bound to the AAA-Key derived from the
MSK derived from the first EAP authentication. When a new MSK is first EAP authentication. When a new AAA-Key is derived as a result
derived as a result of EAP-based re-authentication, any key derived of EAP-based re-authentication, any key derived from the old AAA-Key
from the old MSK MUST be updated to a new one that is derived from MUST be updated to a new one that is derived from the new AAA-Key.
the new MSK. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP
MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at
the end of the authentication phase which resulted in deriving a new
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.
The PANA-Bind-Answer message sent in response to a PANA-Bind-Request
with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key
identifier carried in the request. PANA-Bind-Request and
PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP
whose value is computed by using the new AAA-Key. Although the
specification does not mandate a particular method for calculation of
Key-Id AVP value, a simple method is to use monotonically increasing
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:
* Session-Id * Session-Id
* Device-Id of PaC * Device-Id of PaC
* Device-Id of PAA * Device-Id of PAA
* List of device identifiers of EPs
* Initial tseq of PaC (ISN_pac) * Initial tseq of PaC (ISN_pac)
* Initial tseq of PAA (ISN_paa) * Initial tseq of PAA (ISN_paa)
* Last transmitted tseq value * Last transmitted tseq value
* Last received rseq value * Last received rseq value
* Last transmitted message payload * Last transmitted message payload
* Retransmission interval * Retransmission interval
* Session lifetime * Session lifetime
* Protection-Capability * Protection-Capability
* PANA SA attributes: * PANA SA attributes:
+ MSK + AAA-Key
+ 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 and
derived from the MSK in the following way: derived from the AAA-Key in the following way:
PANA_MAC_KEY = The first N-bit of PANA_MAC_KEY = The first N bits of
HMAC_SHA1(MSK, 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=128 for HMAC-MD5 and N=160 for HMAC-SHA1. use, i.e., N=160 for HMAC-SHA1.
The length of MSK MUST be N-bit or longer. See Section 4.1.6 for the The length of AAA-Key MUST be N bits or longer. See Section 4.1.6
detailed usage of the PANA_MAC_Key. 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 = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU)
where PANA_PDU is the PANA message including the PANA header, with where PANA_PDU is the PANA message including the PANA header, with
the MAC AVP value field first initialized to 0. the MAC AVP value field first initialized to 0. PANA_MAC_PRF
represents the pseudo random function corresponding to the MAC
algorithm specified in the MAC AVP. In this version of draft,
PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same
algorithm to calculate a MAC AVP they originate and receive. The
algorithm is determined by the PAA when a PANA-Bind-Request with a
MAC AVP is sent. When the PaC does not support the MAC algorithm
specified in the PANA-Bind-Request message, it MUST silently discard
the message. The PAA MUST NOT change the MAC algorithm throughout
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 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.
skipping to change at page 12, line 50 skipping to change at page 14, line 32
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 well-
known link local multicast address (TBD) and UDP port (TBD). The known link local multicast address (TBD) and UDP port (TBD). PANA
source address is set to the unspecified IP address if the PaC has PAA discovery assumes that PaC and PAA are one hop away from each
not configured an address yet. PANA PAA discovery assumes that PaC other. If PaC knows the IP address of the PAA (some
and PAA are one hop away from each other. If PaC knows the IP address pre-configuration), it MAY unicast the PANA discovery message to that
of the PAA (some pre-configuration), it MAY unicast the PANA address. PAA SHOULD answer to the PANA-PAA-Discover message with a
discovery message to that address. PAA SHOULD answer to the PANA-Start-Request message.
PANA-PAA-Discover message with a 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. The destination address may be PANA-Start-Request message.
unspecified IP address, but the L2 destination would be a unicast
address (something for the implementations to deal with).
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 that sent
the first response. the first 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 should detect this and send
an unsolicited PANA-Start-Request message to PaC. EP is the node that an unsolicited PANA-Start-Request message to PaC. EP is the node that
can detect such activity. If EP and PAA are co-located, then an can detect such activity. If EP and PAA are co-located, then an
skipping to change at page 13, line 35 skipping to change at page 15, line 15
module on the same host can prompt PAA to start PANA. In case they 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. are separate, there needs to be an explicit message to prompt PAA.
Upon detecting the need to authenticate a client, EP can send a 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 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 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 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 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 secure, the PANA-PAA-Discover message sent from the EP to the PAA
MUST be protected by using, e.g., IPsec. MUST be protected by using, e.g., IPsec.
A PANA-Start-Request message contains a cookie carried in a Cookie A PANA-Start-Request message MAY carry a Cookie AVP that contains a
AVP in the payload, respectively. The rseq field of the header is cookie. The rseq field of the header is set to zero (0). The tseq
set to zero (0). The tseq field of the header contains the initial field of the header contains the initial sequence number. The cookie
sequence number. The cookie is used for preventing the PAA from is used for preventing the PAA from resource consumption DoS attacks
resource consumption DoS attacks by blind attackers. The cookie is by blind attackers. The cookie is computed in such a way that it does
computed in such a way that it does not require any per-session state not require any per-session state maintenance on the PAA in order to
maintenance on the PAA in order to verify the cookie returned in a verify the cookie returned in a PANA-Start-Answer message. The exact
PANA-Start-Answer message. The exact algorithms and syntax used for algorithms and syntax used for generating cookies does not affect
generating cookies does not affect interoperability and hence is not interoperability and hence is not specified here. An example
specified here. An example algorithm is described below. algorithm is described below.
Cookie = Cookie =
<secret-version> | HMAC_SHA1( <Device-Id of PaC> | <secret> ) <secret-version> | HMAC_SHA1( <Device-Id of PaC> | <secret> )
where <secret> is a randomly generated secret known only to the PAA, where <secret> is a randomly generated secret known only to the PAA,
<secret-version> is an index used for choosing the secret for <secret-version> is an index used for choosing the secret for
generating the cookie and '|' indicates concatenation. The 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.
skipping to change at page 14, line 37 skipping to change at page 16, line 17
based on EAP identifier. based on EAP identifier.
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 In this case, PaC can also indicate its choice of ISP by including
its ISP-Information AVP in the PANA-Start-Answer message. AAA its ISP-Information AVP in the PANA-Start-Answer message. AAA
routing for NAP authentication will be based on the NAP. AAA routing routing for NAP authentication will be based on the NAP. AAA routing
for ISP authentication will be based on the ISP choice if an for ISP authentication will be based on the ISP choice if an
ISP-Information AVP is specified in the PANA-Start-Answer message, ISP-Information AVP is specified in the PANA-Start-Answer message,
otherwise it will be based on EAP identifier." otherwise it will be based on EAP identifier. If the S-flag of the
received PANA-Start-Request message is set and the S-flag of the
corresponding PANA-Start-Answer message is not set, only one EAP
authentication occurs without distinction between NAP and ISP
authentications. In this case, PaC can still indicate its choice of
ISP by including its ISP-Information AVP in the PANA-Start-Answer
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 MUST NOT be carried in the PANA-Start-Request
message in order for the PAA to be stateless.
When a Cookie-AVP is not carried in a PANA-Start-Request message, the
PAA does not need to be stateless. In this case, the initial EAP
Request message MAY be carried in the PANA-Start-Request message.
If the initial EAP Request message is carried in the
PANA-Start-Request message, an EAP Response message MUST be carried
in the PANA-Start-Answer message returned to the PAA.
In any case, PANA MUST NOT generate an EAP message on behalf of EAP
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 is never retransmitted. A
PANA-Start-Answer message is retransmitted based on timer in the same PANA-Start-Answer message is retransmitted based on timer in the same
manner as other messages retransmitted at PANA-layer. manner as other messages retransmitted at PANA-layer.
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
PANA-Start-Request message while the PaC sends a PANA-PAA-Discover
message. To resolve the race condition, the PAA SHOULD silently
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
PaC.
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(x,y)[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
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] ------> PANA-PAA-Discover(0,0)[Device-Id]
<------------ 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 Phase Figure 3: Example Sequence for Discovery and Initial Handshake when
when PANA-PAA-Discover is sent by PaC PANA-PAA-Discover is sent by EP
4.3 Authentication Phase when PANA-PAA-Discover is sent by EP 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. All EAP messages except for EAP Success/Failure
messages are carried in the PANA-Auth-Request/PANA-Auth-Answer messages are carried in the PANA-Auth-Request/PANA-Auth-Answer
messages. When an EAP Success/Failure message is sent from a PAA, messages. When an EAP Success/Failure message is sent from a PAA,
the message is carried in the PANA-Bind-Request message. The PANA- the message is carried in the PANA-Bind-Request message. The PANA-
Bind-Request message is acknowledged with a PANA-Bind-Answer. It is Bind-Request message is acknowledged with a PANA-Bind-Answer. It is
possible to carry multiple EAP sequences in a single PANA session. possible to carry multiple EAP sequences in a single PANA session.
When PaC and PAA negotiated during the discovery and initial When PaC and PAA negotiated during the discovery and initial
skipping to change at page 16, line 45 skipping to change at page 19, line 9
Protection-Capability AVP will be used to provide per-packet Protection-Capability AVP will be used to provide per-packet
protection for data traffic. protection for data traffic.
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 Appendix A.
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., MAC]
-----> PANA-Bind-Answer(y+3,x+3) -----> PANA-Bind-Answer(y+3,x+3)
[Device-Id, Protection-Cap., MAC] [Device-Id, Protection-Cap., MAC]
Figure 4: Example Sequence in Authentication Phase Figure 4: Example Sequence in Authentication Phase
skipping to change at page 20, line 26 skipping to change at page 22, line 34
Either an IP address or a link-layer address SHOULD be used as device Either an IP address or a link-layer address SHOULD be used as device
ID at any time. It is assumed that PAA knows the security mechanisms ID at any time. It is assumed that PAA knows the security mechanisms
being provided or required on the access network (e.g., based on being provided or required on the access network (e.g., based on
physical security, link-layer ciphers enabled before or after PANA, physical security, link-layer ciphers enabled before or after PANA,
or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the
choice of access control, PAA SHOULD provide its IP address as device choice of access control, PAA SHOULD provide its IP address as device
ID, and expect the PaC to provide its IP address in return. In all ID, and expect the PaC to provide its IP address in return. In all
other cases, link-layer addresses can be provided from both sides. other cases, link-layer addresses can be provided from both sides.
When IPsec-based access control is used but the PaC is using an
unspecified IP address in the authentication phase, the device ID
reported by the PaC MUST be either 0.0.0.0 or 0::0. This device ID
MUST be recorded as a temporary one by the PAA until the PaC obtains
a valid one and informs the PAA. Eventually PaC MUST obtain an IP
address, possibly by relying on the newly-created PANA session
[I-D.tschofenig-pana-bootstrap-rfc3118], in order to gain full access
to the network. PaC MUST update the device identifier registered on
the PAA from unspecified to the valid IP address by initiating a
PANA-Reauth-Request/PANA-Reauth-Answer exchange in which the IP
address of the PaC is contained in the Device-Id AVP.
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.
skipping to change at page 21, line 21 skipping to change at page 23, line 18
technologies. PANA peer can use PANA-Reauth-Request message to verify technologies. PANA peer can use PANA-Reauth-Request message to verify
the disconnection before taking an action. 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
single PANA session, it is possible that different authorization
lifetime values are associated with the two authentications. In this
case, the smaller authorization lifetime value MUST be used for
calculating the PANA Session-Lifetime value. As a result, when
EAP-based re-authentication occurs, both NAP and ISP authentications
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 When a PaC wants to resume an ongoing PANA session after connecting
to another link in the same access network, it MAY send the unexpired to another link in the same access network, it MAY send the unexpired
PANA session identifier in its PANA-Start-Answer message. In the PANA session identifier in its PANA-Start-Answer message. In the
absence of a Session-Id AVP in this message, PAA MUST assume this is absence of a Session-Id AVP in this message, PAA MUST assume this is
a fresh session and continue its normal execution. a fresh session and continue its normal execution.
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 fast re-authentication, it
skipping to change at page 22, line 6 skipping to change at page 24, line 11
authentication and create a fresh PANA session from scratch. authentication and create a fresh PANA session from scratch.
In case the new PAA retrieves the on-going PANA session attributes In case the new PAA retrieves the on-going PANA session attributes
from the previous PAA, the PANA session continues with a PANA-Reauth from the previous PAA, the PANA session continues with a PANA-Reauth
exchange. The MAC AVP contained in the PANA-Reauth messages MUST be exchange. The MAC AVP contained in the PANA-Reauth messages MUST be
generated and verified by using the retrieved PANA SA attributes. generated and verified by using the retrieved PANA SA attributes.
This exchange MUST also include Session-Id AVP that contains the This exchange MUST also include Session-Id AVP that contains the
newly assigned session identifier, and Device-Id AVP. A new PANA newly assigned session identifier, and Device-Id AVP. A new PANA
session is created upon successful completion of this exchange. This session is created upon successful completion of this exchange. This
session inherits only the session lifetime, protection capability, session inherits only the session lifetime, protection capability,
and MSK attributes from the previous session. Other attributes are and AAA-Key attributes from the previous session. Other attributes
generated based on the PANA exchanges on the new link. While MSK are generated based on the PANA exchanges on the new link. While
stays the same, a new PANA_MAC_Key is computed using the new 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. parameters. Subsequent MAC-AVPs are processed using this new PANA SA.
4.10 Event Notification 4.10 Event Notification
Upon detecting the need to authenticate a client, EP can send a Upon detecting the need to authenticate a client, EP can send a
trigger message to the PAA on behalf of the PaC. This can be one of trigger message to the PAA on behalf of the PaC. This can be one of
the messages provided by the PAA-to-EP protocol, or, in the absence 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 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 message MUST carry the device identifier of the PaC. So that, the PAA
can send the unsolicited PANA-Start-Request message directly to the can send the unsolicited PANA-Start-Request message directly to the
PaC. If the link between the EP and PAA is not physically secured, PaC. If the link between the EP and PAA is not physically secured,
this message sent from EP to PAA MUST be cryptographically protected this message sent from EP to PAA MUST be cryptographically protected
(e.g., by using IPsec). (e.g., by using IPsec).
4.11 PaC Implications 4.11 Support for Separate EP
o PaC state machine. [TBD]
4.12 PAA Implications PANA allows PAA and EP to be separate entities. In this case, if
data traffic protection needs to be initiated after successful PANA
authentication phase, PaC needs to know the device identifier of
EP(s) so that it is able to establish a security association with
each EP to protect data traffic.
o PAA state machine. [TBD] To this end, when a Protection-Capability AVP with either
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
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,
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)
MUST also be included in the PANA-Bind-Request.
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
skipping to change at page 23, line 28 skipping to change at page 25, line 28
authorized legitimate client. Both of these requirements necessitate authorized legitimate client. Both of these requirements necessitate
generation of a security association between the PaC and the PAA at generation of a security association between the PaC and the PAA at
the end of the authentication. This can only be done when the the end of the authentication. This can only be done when the
authentication method used can generate cryptographic keys. Use of authentication method used can generate cryptographic keys. Use of
secret keys can prevent attacks which would otherwise be very easy to secret keys can prevent attacks which would otherwise be very easy to
launch by eavesdropping on and spoofing traffic over an insecure 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 [RFC2284] is an example method is EAP-TLS [RFC2716], whereas EAP-MD5
of a method that cannot create such keying material. The choice of [I-D.ietf-eap-rfc2284bis] is an example of a method that cannot
EAP method becomes important, as already discussed in the next create such keying material. The choice of EAP method becomes
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 will be discussed in
Section 7 and Section 8. Section 7 and Section 8.
6. Authentication Method Choice 6. Authentication Method Choice
skipping to change at page 24, line 25 skipping to change at page 26, line 25
The authentication method choice is a function of the underlying The authentication method choice is a function of the underlying
security of the network (e.g., physically secured, shared link, security of the network (e.g., physically secured, shared link,
etc.). It is the responsibility of the user and the network operator etc.). It is the responsibility of the user and the network operator
to pick the right method for authentication. PANA carries EAP to pick the right method for authentication. PANA carries EAP
regardless of the EAP method used. It is outside the scope of PANA to regardless of the EAP method used. It is outside the scope of PANA to
mandate, recommend, or limit use of any authentication methods. PANA mandate, recommend, or limit use of any authentication methods. PANA
cannot increase the strength of a weak authentication method to make cannot increase the strength of a weak authentication method to make
it suitable for an insecure environment. There are some EAP- based it suitable for an insecure environment. There are some EAP- based
approaches to achieve this goal (see approaches to achieve this goal (see
[I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls],[I-D.tschofenig-eap-ikev2] [I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls],
). PANA can carry these EAP encapsulating methods but it does not [I-D.tschofenig-eap-ikev2]). PANA can carry these EAP encapsulating
concern itself with how they achieve protection for the weak methods methods but it does not concern itself with how they achieve
(i.e., their EAP method payloads). protection for the weak methods (i.e., their EAP method payloads).
7. Filter Rule Installation 7. Filter Rule Installation
PANA protocol provides client authentication and authorization PANA protocol provides client authentication and authorization
functionality for securing network access. The other component of a functionality for securing network access. The other component of a
complete solution is the access control which ensures that only complete solution is the access control which ensures that only
authenticated and authorized clients can gain access to the network. authenticated and authorized clients can gain access to the network.
PANA enables access control by identifying legitimate clients and PANA enables access control by identifying legitimate clients and
generating filtering information for access control mechanisms. generating filtering information for access control mechanisms.
Getting this filtering information to the EPs (Enforcement Points) Getting this filtering information to the EPs (Enforcement Points)
skipping to change at page 26, line 32 skipping to change at page 28, line 32
Network-layer ciphering, i.e., IPsec, can be used when data traffic Network-layer ciphering, i.e., IPsec, can be used when data traffic
protection is required but link-layer ciphering capability is not protection is required but link-layer ciphering capability is not
available. Note that a simple shared secret generated by an EAP available. Note that a simple shared secret generated by an EAP
method is not readily usable by IPsec for authentication and method is not readily usable by IPsec for authentication and
encryption of IP packets. Fresh and unique session key derived from encryption of IP packets. Fresh and unique session key derived from
the EAP method is still insufficient to produce an IPsec SA since the EAP method is still insufficient to produce an IPsec SA since
both traffic selectors and other IPsec SA parameters are missing. both traffic selectors and other IPsec SA parameters are missing.
The shared secret can be used in conjunction with a key management The shared secret can be used in conjunction with a key management
protocol like IKE [RFC2409] to turn a simple shared secret into the protocol like IKE [RFC2409] to turn a simple shared secret into the
required IPsec SA. The details of this mechanism is outside the scope required IPsec SA. The details of such mechanisms are outside the
of PANA protocol [I-D.ietf-pana-ipsec], PANA provides bootstrapping scope of this document and can be found in [I-D.ietf-pana-ipsec].
functionality for such a mechanism by carrying EAP methods that can
generate initial keying material.
Using network-layer ciphers should be regarded as a substitute for Using network-layer ciphers should be regarded as a substitute for
link-layer ciphers when the latter is not available. IKE involves link-layer ciphers when the latter is not available. IKE involves
several message exchanges which can incur additional delay in getting several message exchanges which can incur additional delay and header
basic IP connectivity for a mobile device. Such a latency is overhead in getting basic IP connectivity for a mobile device. Such a
inevitable when there is no other alternative and this level of latency is inevitable when there is no other alternative and this
protection is required. Network-layer ciphering can also be used in level of protection is required. Network-layer ciphering can also be
addition to link-layer ciphering if the added benefits outweigh its used in addition to link-layer ciphering if the added benefits
cost to the user and the network. outweigh its cost to the user and the network.
9. Message Formats 9. Message Formats
This section defines message formats for PANA protocol. This section defines message formats for PANA protocol.
9.1 PANA Header 9.1 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.
skipping to change at page 28, line 11 skipping to change at page 30, line 11
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 an
answer. 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 authentication 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 authentication for NAP and ISP.
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
skipping to change at page 31, line 29 skipping to change at page 33, line 29
9.3.2 PANA-PAA-Discover (PDI) 9.3.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 (0).
If the EP detects a new PaC and sends the PANA-PAA-Discover to the If the EP detects a new PaC and sends the PANA-PAA-Discover to the
PAA, it MUST include the Device-Id of the PaC. 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 < Device-Id >
0*1 < Session-Id >
* [ AVP ] * [ AVP ]
9.3.3 PANA-Start-Request (PSR) 9.3.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 ]
[ NAP-Information ] [ NAP-Information ]
* [ ISP-Information ] * [ ISP-Information ]
* [ AVP ] * [ AVP ]
9.3.4 PANA-Start-Answer (PSA) 9.3.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] >
[ Cookie ] [ Cookie ]
[ EAP-Payload ]
[ ISP-Information ] [ ISP-Information ]
* [ AVP ] * [ AVP ]
9.3.5 PANA-Auth-Request (PAR) 9.3.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 >
< Session-Id > < Session-Id >
< EAP-Payload > < EAP-Payload >
0*1 [ NAP-Information ] 0*1 [ NAP-Information ]
0*1 [ ISP-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) 9.3.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 >
< Session-Id > < Session-Id >
< EAP-Payload > < EAP-Payload >
* [ AVP ] * [ AVP ]
skipping to change at page 32, line 48 skipping to change at page 35, line 5
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 >
< Session-Id > < Session-Id >
< Device-Id > < Device-Id >
{ EAP-Payload } { EAP-Payload }
{ Result-Code } { Result-Code }
[ Session-Lifetime ] [ Session-Lifetime ]
[ Protection-Capability ] [ Protection-Capability ]
[ Key-Id ]
* [ EP-Device-Id ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.8 PANA-Bind-Answer (PBA) 9.3.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 >
< Session-Id > < Session-Id >
< Device-Id > < Device-Id >
[ Key-Id ]
* [ AVP ] * [ AVP ]
0*1 < MAC > 0*1 < MAC >
9.3.9 PANA-Reauth-Request (PRAR) 9.3.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 >
skipping to change at page 34, line 45 skipping to change at page 37, line 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | MAC... | Algorithm | MAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm Algorithm
1 HMAC-MD5 (16 bytes) 1 HMAC-SHA1 (20 bytes)
2 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 9.4.2 Device-Id AVP
The first octet (8 bits) of the Device-Id (Code 1025) AVP data 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 contains the device type. Rest of the AVP data payload contains the
device data. The content and format of data (including byte and bit device data. The content and format of data (including byte and bit
ordering) for L2_ADDRESS is expected to be specified in specific ordering) for L2_ADDRESS is expected to be specified in specific
skipping to change at page 39, line 19 skipping to change at page 41, line 25
permitted in the message definition. The Failed-AVP AVP MUST be permitted in the message definition. The Failed-AVP AVP MUST be
included and contain a copy of the first instance of the offending included and contain a copy of the first instance of the offending
AVP that exceeded the maximum number of occurrences. AVP that exceeded the maximum number of occurrences.
PANA_UNSUPPORTED_VERSION 5011 PANA_UNSUPPORTED_VERSION 5011
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
This error is returned when a request is rejected for unspecified
reasons. For example, when an EAP authentication fails at an EAP
pass-through authenticator without passing an EAP-Failure message
to the PAA, a Result-Code AVP with this error code is carried in
PANA-Bind-Request message without an EAP-Payload AVP.
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
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 is received with an invalid message returned when a message is received with an invalid message
length. length.
PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016
Error code from PaC to PAA. This error is returned when the PaC
receives a PANA-Bind-Request is received with an
Protection-Capability AVP and a valid MAC AVP but does not support
the protection capability specified in the Protection-Capability
AVP.
9.4.8 EAP-Payload AVP 9.4.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 9.4.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
skipping to change at page 40, line 40 skipping to change at page 43, line 12
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 9.4.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
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
that of the Device-Id AVP (see See section Section 9.4.2).
9.4.16 Key-Id AVP
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
MUST be unique within the PANA session.
9.5 AVP Occurrence Table 9.5 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
skipping to change at page 41, line 24 skipping to change at page 44, line 5
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 | 0 | 0 |
Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | Session-Id | 0 | 0 | 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 | 0 | 1 | 1 | 1 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 |
MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 |
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 | 0 | 0 | 0 | 0-1 | 0 | 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-1 | 0 | 0 | 0 | 0 |
NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0-1 | 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 |
--------------------+-----+-----+-----+-----+-----+-----+-----+ --------------------+-----+-----+-----+-----+-----+-----+-----+
+-------------------------------+ +-------------------------------+
| Message | | Message |
| Type | | Type |
+------+------+-----+-----+-----+ +------+------+-----+-----+-----+
Attribute Name | PRAR | PRAA | PTR | PTA | PER | Attribute Name | PRAR | PRAA | PTR | PTA | PER |
--------------------+------+------+-----+-----+-----+ --------------------+------+------+-----+-----+-----+
Result-Code | 0 | 0 | 0 | 0 | 1 | Result-Code | 0 | 0 | 0 | 0 | 1 |
Session-Id | 1 | 1 | 1 | 1 | 1 | Session-Id | 1 | 1 | 1 | 1 | 1 |
Termination-Cause | 0 | 0 | 1 | 0 | 0 | Termination-Cause | 0 | 0 | 1 | 0 | 0 |
EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 |
MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 |
Device-Id | 1+ | 1+ | 0 | 0 | 0 | Device-Id | 1+ | 1+ | 0 | 0 | 0 |
Cookie | 0 | 0 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 |
Session-Lifetime | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 1 | Failed-AVP | 0 | 0 | 0 | 0 | 1 |
ISP-Information | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0 | 0 | 0 | 0 | 0 |
NAP-Information | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 |
EP-Device-Id | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0 |
--------------------+------+------+-----+-----+-----+ --------------------+------+------+-----+-----+-----+
Figure 10: AVP Occurrence Table Figure 10: AVP Occurrence Table
10. PANA Protocol Message Retransmissions 10. 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 messages
carry EAP requests which are retransmitted by the EAP protocol carry EAP requests which are retransmitted by the EAP protocol
entities when needed. The messages that need PANA-level entities when needed. The messages that need PANA-level
skipping to change at page 47, line 48 skipping to change at page 49, line 48
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 key
via the AAA infrastructure (if used). Draft via the AAA infrastructure (if used). Security issues raised with
[I-D.ietf-aaa-diameter-cms-sec] describes how a session key is this session key transport are described in [I-D.ietf-eap-keying].
securely carried (i.e. CMS protected) between AAA servers. Security
issues raised with this session key transport are described in
[I-D.walker-aaa-key-distribution].
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. Confidentiality
protection is not provided. The session keys used for this object protection is not provided. The session keys used for this object
have to be provided by the EAP method. For this version of the have to be provided by the EAP method. For this version of the
document it is assumed that no negotiation of algorithms and 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 such as HMAC-MD5 might be used as an option. The different algorithm may be chosen by default in a future version of
used algorithm is indicated in the header of the Integrity object. To the PANA protocol specification. The used algorithm is indicated in
select the security association for signaling message protection the the header of the Integrity object. To select the security
Session ID is conveyed. The keyed message digest included in the association for signaling message protection the Session ID is
Integrity object will include all fields of the PANA signaling conveyed. The keyed message digest included in the Integrity object
message including the sequence number field of the packet. will include all fields of the PANA signaling message including the
sequence number field of the packet.
The protection of subsequent signaling messages prevents an adversary The protection of subsequent signaling messages prevents an adversary
from acting as a man-in-the-middle adversary, from injecting packets, from acting as a man-in-the-middle adversary, from injecting packets,
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.
skipping to change at page 49, line 13 skipping to change at page 49, line 107
[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 have
to produce keying material for PANA SA when needed. There are certain to produce keying material for PANA SA when needed. There are certain
MitM vulnerabilities with tunneling EAP methods [mitm]. Solving these MitM vulnerabilities with tunneling EAP methods [mitm]. Solving these
problems is outside the scope of PANA. The compound authentication problems is outside the scope of PANA. The compound authentication
problem described in [I-D.puthenkulam-eap-binding] is likely to be problem described in [I-D.puthenkulam-eap-binding] is likely to be
solved in EAP itself rather than in PANA. solved in EAP itself rather than in PANA.
e) Preventing downgrading attacks e) Device Identifier exchange
EAP supports a number of different EAP methods for authentication and
therefore it might be required to agree on a specific mechanism. An
unprotected negotiation mechanism is supported in EAP and a secure
negotiation procedure for the GSS-API methods. The support of the
GSS-API as an EAP method is described in [I-D.aboba-pppext-eapgss]. A
protected negotiation is supported by the GSS-API with RFC 2478
[RFC2478]. If desired, such a protection can also be offered by PANA
by repeating the list of supported EAP methods protected with the
PANA SA. This type of protection is similar to the protected
negotiation described in [RFC3329].
This issue requires further investigation especially since the EAP
protocol is executed between different endpoints than the PANA
protocol.
f) 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 part
of the PANA protocol itself since the protocol is not PANA specific. of the PANA protocol itself since the protocol is not PANA specific.
g) 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.aboba-pppext-key-problem]. This framework is also relevant for [I-D.ietf-eap-keying]. This framework is also relevant for PANA in
PANA in various ways. First, a PANA security association needs to be various ways. First, a PANA security association needs to be created.
created. Additionally it might be necessary to trigger a protocol Additionally it might be necessary to trigger a protocol which allows
which allows link layer and network layer data protection to be link layer and network layer data protection to be established. As an
established. As an example see Section 1 of example see Section 1 of [I-D.ietf-eap-keying] with [802.11i] and
[I-D.aboba-pppext-key-problem] with [802.11i] and [802.11] as an [802.11] as an example. Furthermore, a derived session key might help
example. Furthermore, a derived session key might help to create the to create the pre-requisites for network-layer protection (for
pre-requisites for network-layer protection (for example IPsec example IPsec [I-D.ietf-pana-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.
h) 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 mobility network resource usage based on some policies. In mobile environments
environments it is always possible that an end host suddenly it is always possible that an end host suddenly disconnects without
disconnects without transmitting a disconnect message. Operators are transmitting a disconnect message. Operators are generally motivated
generally motivated to detect a disconnected end host as soon as to detect a disconnected end host as soon as possible in order to
possible in order to release resources (i.e., garbage collection). release resources (i.e., garbage collection). The PAA can remove
The PAA can remove per-session state information including installed per-session state information including installed security
security association, packet filters, etc. 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 version
of the draft we suggest to apply the soft-state principle found at of the draft we suggest to apply the soft-state principle found at
other protocols (such as RSVP). Soft-state means that session state other protocols (such as RSVP). Soft-state means that session state
is kept alive as long as refresh messages refresh the state. If no is kept alive as long as refresh messages refresh the state. If no
new refresh messages are provided then the state automatically times new refresh messages are provided then the state automatically times
out and resources are released. This process includes stopping out and resources are released. This process includes stopping
accounting procedures. accounting procedures.
skipping to change at page 49, line 105 skipping to change at page 49, line 181
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 exchange
as a keep-alive requires additional care as it might result in as a keep-alive requires additional care as it might result in
congestion and hence false alarms. This exchange is cryptographically congestion and hence false alarms. This exchange is cryptographically
protected when PANA SA is available in order to prevent threats protected when PANA SA is available in order to prevent threats
associated with the abuse of this functionality. associated with the abuse of this functionality.
i) 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, a
stop of the accounting procedure and removes the installed packet 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 12. Open Issues
A list of open issues is maintained at [1]. A list of open issues is maintained at [1].
The remaining issues for -01 version of draft are: None. The remaining issues for -01 version of draft are: None.
The remaining issues for -xx version of draft are: 2, 12, 16, 28, 29, The remaining issues for -02 version of draft are: None.
34, 35, 36 and 37.
The remaining issues for -xx version of draft are: 28, 52, 53, 54,
55, 56, 57, 58 and 59.
13. Change History 13. Change History
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,
39, 40, 42, 43, 44, 50, 51 and 60.
14. Acknowledgments 14. Acknowledgments
We would like to thank all members of the PANA working group for We would like to thank all members of the PANA working group for
their comments to this document. their comments to this document.
Normative References Normative References
[I-D.ietf-pana-usage-scenarios] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Ohba, Y., "Problem Statement and Usage Scenarios for Requirement Levels", BCP 14, RFC 2119, March 1997.
PANA", draft-ietf-pana-usage-scenarios-06 (work in
progress), April 2003.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[I-D.ietf-pana-threats-eval]
Parthasarathy, M., "PANA Threat Analysis and security
requirements", draft-ietf-pana-threats-eval-04 (work in
progress), May 2003.
[I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-07 (work in progress), June
2003.
[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-06 (work in progress), September draft-ietf-eap-rfc2284bis-07 (work in progress), December
2003.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA enabling IPsec based Access
Control", draft-ietf-pana-ipsec-00 (work in progress),
October 2003.
[I-D.tschofenig-pana-bootstrap-rfc3118]
Tschofenig, H., "Bootstrapping RFC3118 Delayed
authentication using PANA",
draft-tschofenig-pana-bootstrap-rfc3118-00 (work in
progress), June 2003.
[I-D.ietf-seamoby-ctp]
Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-04 (work in progress), October
2003. 2003.
[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.
[I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D. and G. Zorn,
"Protected EAP Protocol (PEAP)",
draft-josefsson-pppext-eap-tls-eap-06 (work in progress),
March 2003.
[I-D.ietf-pppext-eap-ttls]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)",
draft-ietf-pppext-eap-ttls-03 (work in progress), August
2003.
[I-D.tschofenig-eap-ikev2]
Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method
(EAP-IKEv2)", draft-tschofenig-eap-ikev2-01 (work in
progress), July 2003.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (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.
[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.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-02 (work in progress), July 2003.
[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.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [I-D.ietf-eap-keying]
Protocol", RFC 2522, March 1999. Aboba, B., "EAP Key Management Framework",
draft-ietf-eap-keying-01 (work in progress), October 2003.
[I-D.ietf-aaa-diameter-cms-sec] Informative References
Calhoun, P., Farrell, S. and W. Bulley, "Diameter CMS
Security Application", draft-ietf-aaa-diameter-cms-sec-04
(work in progress), March 2002.
[I-D.walker-aaa-key-distribution] [I-D.ietf-pana-requirements]
Housley, R., Walker, J. and N. Cam-Winget, "AAA Key Yegin, A. and Y. Ohba, "Protocol for Carrying
Distribution", draft-walker-aaa-key-distribution-00 (work Authentication for Network Access (PANA)Requirements",
in progress), April 2002. draft-ietf-pana-requirements-07 (work in progress), June
2003.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-03 (work in progress), October 2003.
[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-03 (work in Problem", draft-puthenkulam-eap-binding-04 (work in
progress), July 2003. progress), October 2003.
[I-D.aboba-pppext-eapgss] [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Aboba, B. and D. Simon, "EAP GSS Authentication Protocol", Protocol", RFC 2522, March 1999.
draft-aboba-pppext-eapgss-12 (work in progress), April
2002.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API [I-D.ietf-pana-usage-scenarios]
Negotiation Mechanism", RFC 2478, December 1998. Ohba, Y., "Problem Statement and Usage Scenarios for
PANA", draft-ietf-pana-usage-scenarios-06 (work in
progress), April 2003.
[RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T. [I-D.ietf-pana-threats-eval]
Haukka, "Security Mechanism Agreement for the Session Parthasarathy, M., "PANA Threat Analysis and security
Initiation Protocol (SIP)", RFC 3329, January 2003. requirements", draft-ietf-pana-threats-eval-04 (work in
progress), May 2003.
[I-D.aboba-pppext-key-problem] [I-D.ietf-pana-ipsec]
Aboba, B. and D. Simon, "EAP Key Management Framework", Parthasarathy, M., "PANA enabling IPsec based Access
draft-aboba-pppext-key-problem-07 (work in progress), Control", draft-ietf-pana-ipsec-01 (work in progress),
August 2003. January 2004.
Informative References [I-D.ietf-seamoby-ctp]
Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-08 (work in progress), January
2004.
[I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D. and G. Zorn,
"Protected EAP Protocol (PEAP)",
draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
October 2003.
[I-D.ietf-pppext-eap-ttls]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)",
draft-ietf-pppext-eap-ttls-03 (work in progress), August
2003.
[I-D.tschofenig-eap-ikev2]
Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method
(EAP-IKEv2)", draft-tschofenig-eap-ikev2-02 (work in
progress), October 2003.
[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/D6.0, Specification for enhanced security", IEEE 802.11i/D7.0,
2003. 2003.
[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, 1997. layer (phy) specifications", IEEE Standard 802.11,
1999(R2003).
URIs URIs
[1] <http://danforsberg.info:8080/pana-issues/> [1] <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
skipping to change at page 70, line 29 skipping to change at page 70, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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