draft-ietf-pana-pana-13.txt   draft-ietf-pana-pana-14.txt 
PANA Working Group D. Forsberg PANA Working Group D. Forsberg
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track Y. Ohba (Ed.) Intended status: Standards Track Y. Ohba (Ed.)
Expires: June 9, 2007 Toshiba Expires: September 4, 2007 Toshiba
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
A. Yegin A. Yegin
Samsung Samsung
December 6, 2006 March 3, 2007
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-13 draft-ietf-pana-pana-14
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 9, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the Protocol for Carrying Authentication for This document defines the Protocol for Carrying Authentication for
Network Access (PANA), a network-layer transport for Extensible Network Access (PANA), a network-layer 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 protocol specification between clients and access networks. PANA protocol specification
covers the client-to-network access authentication part of an overall covers the client-to-network access authentication part of an overall
secure network access framework, which additionally includes other secure network access framework, which additionally includes other
protocols and mechanisms for service provisioning, access control as protocols and mechanisms for service provisioning, access control as
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Specification of Requirements . . . . . . . . . . . . . . 5 1.1. Specification of Requirements . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10
4.2. High-Level Attribute-Value Pair Description . . . . . . . 10 4.2. High-Level Attribute-Value Pair Description . . . . . . . 10
4.3. Handshake Phase . . . . . . . . . . . . . . . . . . . . . 10 4.3. Handshake Phase . . . . . . . . . . . . . . . . . . . . . 10
4.4. Authentication and Authorization Phase . . . . . . . . . . 12 4.4. Authentication and Authorization Phase . . . . . . . . . . 12
4.5. Access Phase . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Access Phase . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Re-authentication Phase . . . . . . . . . . . . . . . . . 14 4.6. Re-authentication Phase . . . . . . . . . . . . . . . . . 15
4.7. Termination Phase . . . . . . . . . . . . . . . . . . . . 16 4.7. Termination Phase . . . . . . . . . . . . . . . . . . . . 16
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 17 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Sequence Number and Retransmission . . . . . . . . . . . . 17 5.2. Sequence Number and Retransmission . . . . . . . . . . . . 17
5.3. PANA Security Association . . . . . . . . . . . . . . . . 18 5.3. PANA Security Association . . . . . . . . . . . . . . . . 18
5.4. Message Authentication . . . . . . . . . . . . . . . . . . 19 5.4. Message Authentication . . . . . . . . . . . . . . . . . . 19
5.5. Message Validity Check . . . . . . . . . . . . . . . . . . 20 5.5. Message Validity Check . . . . . . . . . . . . . . . . . . 20
5.6. PaC Updating its IP Address . . . . . . . . . . . . . . . 21 5.6. PaC Updating its IP Address . . . . . . . . . . . . . . . 21
5.7. Session Lifetime . . . . . . . . . . . . . . . . . . . . . 21 5.7. Session Lifetime . . . . . . . . . . . . . . . . . . . . . 21
5.8. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22 5.8. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22
6. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 24 6.1. IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 24
6.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 24 6.2. PANA Message Header . . . . . . . . . . . . . . . . . . . 24
6.3. AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3. AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 26
7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . . 29 7. PANA Messages . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. PANA-Client-Initiation (PCI) . . . . . . . . . . . . . . . 31 7.1. PANA-Client-Initiation (PCI) . . . . . . . . . . . . . . . 31
7.2. PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 31 7.2. PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . . 31
7.3. PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 31 7.3. PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . . . 31
7.4. PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 32 7.4. PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . . . 32
7.5. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 32 7.5. PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . . 32
7.6. PANA-Reauth-Request (PRR) . . . . . . . . . . . . . . . . 32 7.6. PANA-Reauth-Request (PRR) . . . . . . . . . . . . . . . . 32
7.7. PANA-Reauth-Answer (PRA) . . . . . . . . . . . . . . . . . 32 7.7. PANA-Reauth-Answer (PRA) . . . . . . . . . . . . . . . . . 32
7.8. PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 32 7.8. PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . . . 32
7.9. PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 33 7.9. PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . . 33
skipping to change at page 3, line 48 skipping to change at page 3, line 48
10.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . . 48 10.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . . 48
10.4.2. Termination-Cause AVP Values . . . . . . . . . . . . . 48 10.4.2. Termination-Cause AVP Values . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11.1. General Security Measures . . . . . . . . . . . . . . . . 49 11.1. General Security Measures . . . . . . . . . . . . . . . . 49
11.2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 50 11.2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 50
11.3. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 51 11.3. EAP Methods . . . . . . . . . . . . . . . . . . . . . . . 51
11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 51 11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 51
11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 51 11.5. Per-packet Ciphering . . . . . . . . . . . . . . . . . . . 51
11.6. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 52 11.6. PAA-to-EP Communication . . . . . . . . . . . . . . . . . 52
11.7. Liveness Test . . . . . . . . . . . . . . . . . . . . . . 52 11.7. Liveness Test . . . . . . . . . . . . . . . . . . . . . . 52
11.8. IP Address Spoofing . . . . . . . . . . . . . . . . . . . 52 11.8. Early Termination of a Session . . . . . . . . . . . . . . 52
11.9. Early Termination of a Session . . . . . . . . . . . . . . 52 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . . 55 13.2. Informative References . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 59
1. Introduction 1. Introduction
Providing secure network access service requires access control based Providing secure network access service requires access control based
on the authentication and authorization of the clients and the access on the authentication and authorization of the clients and the access
networks. Client-to-network authentication provides parameters that networks. Client-to-network authentication provides parameters that
are needed to police the traffic flow through the enforcement points. are needed to police the traffic flow through the enforcement points.
A protocol is needed to carry authentication methods between the A protocol is needed to carry authentication methods between the
client and the access network. client and the access network.
skipping to change at page 9, line 34 skipping to change at page 9, line 34
// Termination phase // Termination phase
-----> PANA-Termination-Request -----> PANA-Termination-Request
<----- PANA-Termination-Answer <----- PANA-Termination-Answer
Figure 1: Illustration of PANA messages in a session Figure 1: Illustration of PANA messages in a session
Note that depending on the environment and deployment the protocol Note that depending on the environment and deployment the protocol
flow depicted in Figure 1 can be abbreviated (An unsolicited flow depicted in Figure 1 can be abbreviated (An unsolicited
PANA-Start-Request message can be sent without PANA-Start-Request message can be sent without
PANA-Client-Initiation, EAP responses can be piggybacked on the PANA-Client-Initiation, EAP responses can be piggybacked on the
PANA-Auth-Answers, and PANA-Ping and PANA-Termination usage is PANA-Auth-Answers, and PANA-Ping and PANA-Termination messages are
optional). optional to use).
Cryptographic protection of messages between the PaC and PAA is Cryptographic protection of messages between the PaC and PAA is
possible as soon as EAP in conjunction with the EAP method exports a possible as soon as EAP in conjunction with the EAP method exports a
shared key. That shared key is used to create a PANA SA. The PANA shared key. That shared key is used to create a PANA SA. The PANA
SA helps generate per-message authentication codes that provide SA helps generate per-message authentication codes that provide
integrity protection and authentication. integrity protection and authentication.
Throughout the lifetime of a session, various problems found with the Throughout the lifetime of a session, various problems found with the
incoming messages can generate a PANA error message sent in response. incoming messages can generate a PANA error message sent in response.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
A session identifier for the session is assigned by the PAA in the A session identifier for the session is assigned by the PAA in the
handshake phase and carried in the PANA-Start-Request message. The handshake phase and carried in the PANA-Start-Request message. The
same session identifier MUST be carried in the subsequent messages same session identifier MUST be carried in the subsequent messages
exchanged between the PAA and PaC throughout the session. exchanged between the PAA and PaC throughout the session.
When the PaC receives a PANA-Start-Request message from a PAA, it When the PaC receives a PANA-Start-Request message from a PAA, it
responds with a PANA-Start-Answer message if it wishes to enter the responds with a PANA-Start-Answer message if it wishes to enter the
authentication and authorization phase. authentication and authorization phase.
The PAA MAY limit the rate it processes incoming The PAA SHOULD limit the rate it processes incoming
PANA-Client-Initiation messages. PANA-Client-Initiation messages in order not to subject itself to
denial-of service attacks. Details of rate limiting are outside the
scope of this specification.
An Algorithm AVP MAY be included in the PANA-Start-Request in order An Algorithm AVP MAY be included in the PANA-Start-Request in order
to indicate required and available capabilities for the network to indicate required and available capabilities for the network
access. This AVP MAY be used by the PaC for assessing the capability access. This AVP MAY be used by the PaC for assessing the capability
match even before the authentication takes place. Since this AVP is match even before the authentication takes place. Since this AVP is
provided during the insecure handshake phase, there are certain provided during the insecure handshake phase, there are certain
security risks involved in using the provided information. See security risks involved in using the provided information. See
Section 11 for further discussion on this. Section 11 for further discussion on this.
The initial EAP Request message MAY be carried by the The initial EAP Request message MAY be carried by the
PANA-Start-Request message (as oppose to by a later PANA-Auth-Request PANA-Start-Request message (as opposed to by a later
message) in order to reduce the number of round-trips. If the PANA-Auth-Request message) in order to reduce the number of
initial EAP Request message is carried in the PANA-Start-Request round-trips. If the initial EAP Request message is carried in the
message, an EAP Response message MUST be carried in the PANA-Start-Request message, an EAP Response message MUST be carried
PANA-Start-Answer message returned to the PAA. in the PANA-Start-Answer message returned to the PAA.
In order to prevent potential DoS attacks, the PAA MAY refrain from In order to prevent potential DoS attacks, the PAA SHOULD refrain
timeout-based retransmission of the PANA-Start-Request message in from timeout-based retransmission of the PANA-Start-Request message
response to a PaC-initiated handshake. For this reason, the PaC MUST in response to a PaC-initiated handshake. For this reason, the PaC
retransmit the PANA-Client-Initiation message until it enters the MUST retransmit the PANA-Client-Initiation message until it enters
authentication and authorization phase by receiving the first the authentication and authorization phase by receiving the first
PANA-Auth-Request message from the PAA. PANA-Auth-Request message from the PAA.
It is possible that both the PAA and the PaC initiate the handshake It is possible that both the PAA and the PaC initiate the handshake
procedure at the same time, i.e., the PAA sends a PANA-Start-Request procedure at the same time, i.e., the PAA sends a PANA-Start-Request
message while the PaC sends a PANA-Client-Initiation message. To message while the PaC sends a PANA-Client-Initiation message. To
resolve the race condition, the PAA SHOULD silently discard the resolve the race condition, the PAA SHOULD silently discard the
PANA-Client-Initiation message received from the PaC after it has PANA-Client-Initiation message received from the PaC after it has
sent a PANA-Start-Request message. sent a PANA-Start-Request message. The PAA uses the source IP
address and the source port number of the PANA-Client-Initiation
message to identify the PaC in the handshake phase.
Figure 2 shows an example sequence for PaC-initiated handshake. Figure 2 shows an example sequence for PaC-initiated handshake.
PaC PAA Message(sequence number)[AVPs] PaC PAA Message(sequence number)[AVPs]
------------------------------------------------------ ------------------------------------------------------
-----> PANA-Client-Initiation(0) -----> PANA-Client-Initiation(0)
<----- PANA-Start-Request(x) <----- PANA-Start-Request(x)
-----> PANA-Start-Answer(x) -----> PANA-Start-Answer(x)
(continued to the authentication and (continued to the authentication and
authorization phase) authorization phase)
Figure 2: Example sequence for PaC-initiated handshake phase Figure 2: Example sequence for PaC-initiated handshake phase
4.4. Authentication and Authorization Phase 4.4. Authentication and Authorization Phase
The main task of the authentication and authorization phase is to The main task of the authentication and authorization phase is to
carry EAP messages between the PaC and the PAA. EAP Request and carry EAP messages between the PaC and the PAA. EAP Request and
Response messages are carried in PANA-Auth-Request messages. Response messages are carried in PANA-Auth-Request messages.
PANA-Auth-Answer messages are simply used to acknowledge receipt of PANA-Auth-Answer messages are simply used to acknowledge receipt of
the requests. As an optimization, a PANA-Auth-Answer message MAY the requests. As an optimization, a PANA-Auth-Answer message MAY
include the EAP Response message. This optimization MAY not be used include the EAP Response message. This optimization SHOULD NOT be
when it takes time to generate the EAP Response message (due to, used when it takes time to generate the EAP Response message (due to,
e.g., intervention of human input), in which case returning an e.g., intervention of human input), in which case returning an
PANA-Auth-Answer message without piggybacking an EAP Response message PANA-Auth-Answer message without piggybacking an EAP Response message
can avoid unnecessary retransmission of the PANA-Auth-Request can avoid unnecessary retransmission of the PANA-Auth-Request
message. Another optimization allows optionally carrying the first message. Another optimization allows optionally carrying the first
EAP Request/Response message in PANA-Start-Request/Answer message as EAP Request/Response message in PANA-Start-Request/Answer message as
described in Section 4.3. described in Section 4.3.
A Nonce AVP MUST be included in the first PANA-Auth-Request and A Nonce AVP MUST be included in the first PANA-Auth-Request and
PANA-Auth-Answer messages. PANA-Auth-Answer messages.
skipping to change at page 13, line 34 skipping to change at page 13, line 37
the authentication and authorization phase and the keys are the authentication and authorization phase and the keys are
successfully derived, the PANA message that carries the EAP Success successfully derived, the PANA message that carries the EAP Success
message (i.e., a PANA-Bind-Request message) MUST contain a Key-Id AVP message (i.e., a PANA-Bind-Request message) MUST contain a Key-Id AVP
and an AUTH AVP, and an Algorithm AVP for the first derivation of and an AUTH AVP, and an Algorithm AVP for the first derivation of
keys in the session, and any subsequent message MUST contain an AUTH keys in the session, and any subsequent message MUST contain an AUTH
AVP. An Algorithm AVP MUST NOT be contained in a PANA-Bind-Request AVP. An Algorithm AVP MUST NOT be contained in a PANA-Bind-Request
message after the first derivation of keys in the session. message after the first derivation of keys in the session.
EAP authentication can fail at a pass-through authenticator without EAP authentication can fail at a pass-through authenticator without
sending an EAP Failure message [RFC4137]. When this occurs, the PAA sending an EAP Failure message [RFC4137]. When this occurs, the PAA
SHOULD send a PANA-Error-Request message to the PaC with using SHOULD silently terminate the session, expecting that a session
PANA_UNABLE_TO_COMPLY result code. The PaC MUST NOT change its state timeout on the PaC will clean up the state on the PaC.
unless the error message is secured by PANA or lower-layer. In any
case, a more appropriate way is to rely on a timeout on the PaC.
There is a case where EAP authentication succeeds with producing an There is a case where EAP authentication succeeds with producing an
EAP Success message but network access authorization fails due to, EAP Success message but network access authorization fails due to,
e.g., authorization rejected by a AAA or authorization locally e.g., authorization rejected by a AAA or authorization locally
rejected by the PAA. When this occurs, the PAA MUST send a rejected by the PAA. When this occurs, the PAA MUST send a
PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If
an MSK is established between the PaC and the PAA by the time when an MSK is established between the PaC and the PAA by the time when
the EAP Success message is generated by the EAP server (this is the the EAP Success message is generated by the EAP server (this is the
case when the EAP method provides protected success indication), the case when the EAP method provides protected success indication), the
PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected
skipping to change at page 14, line 24 skipping to change at page 14, line 25
the communicating peer whenever they need to make sure the the communicating peer whenever they need to make sure the
availability of the session on the peer and expect the peer to return availability of the session on the peer and expect the peer to return
a PANA-Ping-Answer message. Both PANA-Ping-Request and a PANA-Ping-Answer message. Both PANA-Ping-Request and
PANA-Ping-Answer messages MUST be protected with an AUTH AVP when a PANA-Ping-Answer messages MUST be protected with an AUTH AVP when a
PANA SA is available. PANA SA is available.
Implementations MUST limit the rate of performing this test. The PaC Implementations MUST limit the rate of performing this test. The PaC
and the PAA can handle rate limitation on their own, they do not have and the PAA can handle rate limitation on their own, they do not have
to perform any coordination with each other. There is no negotiation to perform any coordination with each other. There is no negotiation
of timers for this purpose. Additionally, an implementation MAY of timers for this purpose. Additionally, an implementation MAY
rate-limit processing the incoming PANA-Ping-Requests. rate-limit processing the incoming PANA-Ping-Requests. It should be
noted that if a PAA or PaC which considers its connectivity lost
after a relatively small number of unresponsive pings coupled with a
peer that is aggressively rate-limiting the PANA-Ping messages,
false-positives could result. Care should be taken when
rate-limiting PANA-Ping messages to periodically respond, and a PAA
or PaC should not rely on PANA-Ping messages to quickly determine
loss of connectivity.
Figure 4 and Figure 5 show liveness tests as they are initiated by Figure 4 and Figure 5 show liveness tests as they are initiated by
the PaC and the PAA respectively. the PaC and the PAA respectively.
PaC PAA Message(sequence number)[AVPs] PaC PAA Message(sequence number)[AVPs]
------------------------------------------------------ ------------------------------------------------------
-----> PANA-Ping-Request(q)[AUTH] -----> PANA-Ping-Request(q)[AUTH]
<----- PANA-Ping-Answer(q)[AUTH] <----- PANA-Ping-Answer(q)[AUTH]
Figure 4: Example sequence for PaC-initiated liveness test Figure 4: Example sequence for PaC-initiated liveness test
skipping to change at page 15, line 26 skipping to change at page 15, line 35
to packet re-ordering or a race condition between the PaC and PAA to packet re-ordering or a race condition between the PaC and PAA
when they both attempt to engage in re-authentication. The PaC MUST when they both attempt to engage in re-authentication. The PaC MUST
keep discarding the received PANA-Auth-Requests until it receives the keep discarding the received PANA-Auth-Requests until it receives the
answer to its request. answer to its request.
When the PAA initiates re-authentication, it sends a When the PAA initiates re-authentication, it sends a
PANA-Auth-Request message containing the session identifier for the PANA-Auth-Request message containing the session identifier for the
PaC to enter the re-authentication phase. The PAA SHOULD initiate PaC to enter the re-authentication phase. The PAA SHOULD initiate
EAP re-authentication before the current session lifetime expires. EAP re-authentication before the current session lifetime expires.
Re-authentication of an on-going PANA session MUST maintain the Re-authentication of an on-going PANA session MUST NOT reset the
existing sequence numbers. sequence numbers.
For any re-authentication, if there is an established PANA SA, For any re-authentication, if there is an established PANA SA,
PANA-Reauth-Request, PANA-Reauth-Answer, PANA-Auth-Request and PANA-Reauth-Request, PANA-Reauth-Answer, PANA-Auth-Request and
PANA-Auth-Answer messages MUST be protected by adding an AUTH AVP to PANA-Auth-Answer messages MUST be protected by adding an AUTH AVP to
each message. each message.
PaC PAA Message(sequence number)[AVPs] PaC PAA Message(sequence number)[AVPs]
------------------------------------------------------ ------------------------------------------------------
-----> PANA-Reauth-Request(q)[AUTH] -----> PANA-Reauth-Request(q)[AUTH]
<----- PANA-Reauth-Answer(q)[AUTH] <----- PANA-Reauth-Answer(q)[AUTH]
skipping to change at page 17, line 51 skipping to change at page 17, line 51
PANA request messages are retransmitted based on a timer until a PANA request messages are retransmitted based on a timer until a
response is received (in which case the retransmission timer is response is received (in which case the retransmission timer is
stopped) or the number of retransmission reaches the maximum value stopped) or the number of retransmission reaches the maximum value
(in which case the PANA session MUST be deleted immediately). (in which case the PANA session MUST be deleted immediately).
The retransmission timers SHOULD be calculated as described in The retransmission timers SHOULD be calculated as described in
Section 9 unless a given deployment chooses to use its own Section 9 unless a given deployment chooses to use its own
retransmission timers optimized for the underlying link-layer retransmission timers optimized for the underlying link-layer
characteristics. characteristics.
The PaC and PAA MUST respond to duplicate requests as long as the Unless dropped due to rate limiting, the PaC and PAA MUST respond to
responding rate does not exceed a certain threshold value. The last all duplicate request messages received. The last transmitted answer
transmitted answer MAY be cached in case it is not received by the MAY be cached in case it is not received by the peer and that
peer and that generates a retransmission of the last request. When generates a retransmission of the last request. When available, the
available, the cached answer can be used instead of fully processing cached answer can be used instead of fully processing the
the retransmitted request and forming a new answer from scratch. retransmitted request and forming a new answer from scratch.
5.3. PANA Security Association 5.3. 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 an MSK. A PANA SA is not authentication succeeds with a creation of an MSK. A PANA SA is not
created when the PANA authentication fails or no MSK is produced by created when the PANA authentication fails or no MSK is produced by
any EAP authentication method. When a new MSK is derived in the PANA any EAP authentication method. When a new MSK is derived in the PANA
re-authentication phase, any key derived from the old MSK MUST be re-authentication phase, any key derived from the old MSK MUST be
updated to a new one that is derived from the new MSK. In order to updated to a new one that is derived from the new MSK. In order to
distinguish the new MSK from old ones, one Key-Id AVP MUST be carried distinguish the new MSK from old ones, one Key-Id AVP MUST be carried
skipping to change at page 22, line 48 skipping to change at page 22, line 48
when a badly formed PANA message is received or in case of other when a badly formed PANA message is received or in case of other
errors. The receiver of this request MUST respond with a errors. The receiver of this request MUST respond with a
PANA-Error-Answer message. PANA-Error-Answer message.
An adversary might craft erroneous PANA messages to launch a Denial An adversary might craft erroneous PANA messages to launch a Denial
of Service attack. Unless the PaC or the PAA performs a of Service attack. Unless the PaC or the PAA performs a
rate-limitation of the generated PANA-Error-Request messages it may rate-limitation of the generated PANA-Error-Request messages it may
be overburdened by responding to bogus messages. Note that a be overburdened by responding to bogus messages. Note that a
PANA-Error-Answer message that is sent in response to a PANA-Error-Answer message that is sent in response to a
PANA-Error-Request message does not require either the PaC or the PAA PANA-Error-Request message does not require either the PaC or the PAA
to create a state. to create a PANA protocol state.
If an error message is sent unprotected (i.e., without using an AUTH If an error message is sent unprotected (i.e., without using an AUTH
AVP) then the error message MUST be processed such that the receiver AVP) then the error message MUST be processed such that the receiver
does not change its state. does not change its PANA protocol state.
6. Header Format 6. Message Format
This section defines message formats for PANA protocol. This section defines message formats for PANA protocol.
6.1. IP and UDP Headers 6.1. IP and UDP Headers
Any PANA message is unicast between the PaC and the PAA. Any PANA message is unicast between the PaC and the PAA.
When the PANA message is sent in response to a request, the UDP When the PANA message is sent in response to a request, the UDP
source and destination ports of the response message MUST be copied source and destination ports of the response message MUST be copied
from the destination and source ports of the request message, from the destination and source ports of the request message,
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Sequence Number Sequence Number
This field contains contains a 32 bit sequence number. This field contains contains a 32 bit sequence number.
AVPs AVPs
AVPs are a method of encapsulating information relevant to the AVPs are a method of encapsulating information relevant to the
PANA message. See section Section 6.3 for more information on PANA message. See section Section 6.3 for more information on
AVPs. AVPs.
6.3. AVP Header 6.3. AVP Format
Each AVP of type OctetString MUST be padded to align on a 32-bit Each AVP of type OctetString MUST be padded to align on a 32-bit
boundary, while other AVP types align naturally. A number of boundary, while other AVP types align naturally. A number of
zero-valued bytes are added to the end of the AVP Data field till a zero-valued bytes are added to the end of the AVP Value field till a
word boundary is reached. The length of the padding is not reflected word boundary is reached. The length of the padding is not reflected
in the AVP Length field [RFC3588]. in the AVP Length field [RFC3588].
The fields in the AVP header are sent in network byte order. The The fields in the AVP are sent in network byte order. The AVP format
format of the header is: is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Flags | | AVP Code | AVP Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved | | AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id (opt) | | Vendor-Id (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... | Value ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
AVP Code AVP Code
The AVP Code, together with the optional Vendor ID field, The AVP Code, together with the optional Vendor ID field,
identifies attribute that follows. If the V-bit is not set, the identifies attribute that follows. If the V-bit is not set, the
Vendor ID is not present and the AVP Code refers to an IETF Vendor ID is not present and the AVP Code refers to an IETF
attribute. attribute.
AVP Flags AVP Flags
skipping to change at page 27, line 30 skipping to change at page 27, line 30
simply ignore the AVP. simply ignore the AVP.
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.
AVP Length AVP Length
The AVP Length field is two octets, and indicates the number of The AVP Length field is two octets, and indicates the number of
octets in this AVP including the AVP Code, AVP Length, AVP Flags, octets in the Value field. The length of the AVP Code, AVP
and the AVP data. Length, AVP Flags, Reserved and Vendor-Id fields are not counted
in the AVP Length value.
Reserved Reserved
This two-octet field is reserved for future use, and MUST be set This two-octet field is reserved for future use, and MUST be set
to zero, and ignored by the receiver. to zero, and ignored by the receiver.
Vendor-Id Vendor-Id
The Vendor-Id field is present if the 'V' bit is set in the AVP The Vendor-Id field is present if the 'V' bit is set in the AVP
Flags field. The optional four-octet Vendor-Id field contains the Flags field. The optional four-octet Vendor-Id field contains the
IANA assigned "SMI Network Management Private Enterprise Codes" IANA assigned "SMI Network Management Private Enterprise Codes"
[ianaweb] value, encoded in network byte order. Any vendor [ianaweb] value, encoded in network byte order. Any vendor
wishing to implement a vendor-specific PANA AVP MUST use their own wishing to implement a vendor-specific PANA AVP MUST use their own
Vendor-Id along with their privately managed AVP address space, Vendor-Id along with their privately managed AVP address space,
guaranteeing that they will not collide with any other vendor's guaranteeing that they will not collide with any other vendor's
vendor-specific AVP(s), nor with future IETF applications. vendor-specific AVP(s), nor with future IETF applications.
Data Value
The Data field is zero or more octets and contains information The Value field is zero or more octets and contains information
specific to the Attribute. The format and length of the Data specific to the Attribute. The format of the Value field is
field is determined by the AVP Code and AVP Length fields. determined by the AVP Code and Vendor-Id fields. The length of
the Value field is determined by the AVP Length field.
Unless otherwise noted, AVPs defined in this document will have the Unless otherwise noted, AVPs defined in this document will have the
following default AVP Flags field settings: The 'M' bit MUST be set. following default AVP Flags field settings: The 'M' bit MUST be set.
The 'V' bit MUST NOT be set. The 'V' bit MUST NOT be set.
7. PANA Messages 7. PANA Messages
Each Request/Answer message pair is assigned a Sequence Number, and Each Request/Answer message pair is assigned a Sequence Number, and
the sub-type (i.e., request or answer) is identified via the 'R' bit the sub-type (i.e., request or answer) is identified via the 'R' bit
in the Message Flags field of the PANA message header. in the Message Flags field of the PANA message header.
skipping to change at page 36, line 7 skipping to change at page 36, line 7
The PANA-Update-Answer (PUA) message is sent by the PAA (PaC) to the The PANA-Update-Answer (PUA) message is sent by the PAA (PaC) to the
PaC (PAA) in response to a PANA-Update-Request from the PaC (PAA). PaC (PAA) in response to a PANA-Update-Request from the PaC (PAA).
PANA-Update-Answer ::= < PANA-Header: 9 > PANA-Update-Answer ::= < PANA-Header: 9 >
* [ AVP ] * [ AVP ]
0*1 < AUTH > 0*1 < AUTH >
8. AVPs in PANA 8. AVPs in PANA
This document uses AVP Data Format such as 'OctetString' and This document uses AVP Value Format such as 'OctetString' and
'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions 'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions
of these data formats are not repeated in this document. of these data formats are not repeated in this document.
The following tables lists the AVPs used in this document, and The following tables lists the AVPs used in this document, and
specifies in which PANA messages they MAY, or MAY NOT be present. specifies in which PANA messages they MAY, or MAY NOT be present.
The table uses the following symbols: The table uses the following symbols:
0 The AVP MUST NOT be present in the message. 0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the 0+ Zero or more instances of the AVP MAY be present in the
message. message.
0-1 Zero or one instance of the AVP MAY be present in the message. 0-1 Zero or one instance of the AVP MAY be present in the message.
It is considered an error if there are more than one instance It is considered an error if there are more than one instance
of the AVP. of the AVP.
1 One instance of the AVP MUST be present in the message. 1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the
message.
+-------------------------------------------+ +-------------------------------------------+
| Message Type | | Message Type |
+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |PCI|PSR|PSA|PAR|PAN|PRR|PRA|PBR|PBA|PPR|PPA| Attribute Name |PCI|PSR|PSA|PAR|PAN|PRR|PRA|PBR|PBA|PPR|PPA|
----------------------+---+---+---+---+---+---+---+---+---+---+---+ ----------------------+---+---+---+---+---+---+---+---+---+---+---+
Algorithm | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | Algorithm | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 |
AUTH | 0 | 0 | 0 |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1| AUTH | 0 | 0 | 0 |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 | EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Failed-Message-Header | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-Message-Header | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
skipping to change at page 44, line 42 skipping to change at page 44, line 42
This section presents a table of values used to describe the message This section presents a table of values used to describe the message
retransmission behavior of PANA requests that are retransmitted retransmission behavior of PANA requests that are retransmitted
(REQ_*) and PANA-Client-Initiation message (PCI_*). The table shows (REQ_*) and PANA-Client-Initiation message (PCI_*). The table shows
default values. default values.
Parameter Default Description Parameter Default Description
------------------------------------------------ ------------------------------------------------
PCI_IRT 1 sec Initial PCI timeout. PCI_IRT 1 sec Initial PCI timeout.
PCI_MRT 120 secs Max PCI timeout value. PCI_MRT 120 secs Max PCI timeout value.
PCI_MRC 0 Configurable. PCI_MRC 0 Max PCI retransmission attempts.
PCI_MRD 0 Configurable. PCI_MRD 0 Max PCI retransmission duration.
REQ_IRT 1 sec Initial Request timeout. REQ_IRT 1 sec Initial Request timeout.
REQ_MRT 30 secs Max Request timeout value. REQ_MRT 30 secs Max Request timeout value.
REQ_MRC 10 Max Request retry attempts. REQ_MRC 10 Max Request retransmission attempts.
REQ_MRD 0 Configurable. REQ_MRD 0 Max Request retransmission duration.
So for example the first RT for the PBR message is calculated using So for example the first RT for the PBR message is calculated using
REQ_IRT as the IRT: REQ_IRT as the IRT:
RT = REQ_IRT + RAND*REQ_IRT RT = REQ_IRT + RAND*REQ_IRT
10. IANA Considerations 10. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the PANA Authority (IANA) regarding registration of values related to the PANA
skipping to change at page 49, line 8 skipping to change at page 49, line 8
As defined in Section 8.10, the Termination-Cause AVP (AVP Code 10) As defined in Section 8.10, the Termination-Cause AVP (AVP Code 10)
defines the values 1, 4 and 8. defines the values 1, 4 and 8.
All remaining values are available for assignment via IETF Consensus All remaining values are available for assignment via IETF Consensus
[IANA]. [IANA].
11. Security Considerations 11. Security Considerations
The PANA protocol defines a UDP-based EAP encapsulation that runs The PANA protocol defines a UDP-based EAP encapsulation that runs
between two IP-enabled nodes on the same IP link. Various security between two IP-enabled nodes. Various security threats that are
threats that are relevant to a protocol of this nature are outlined relevant to a protocol of this nature are outlined in [RFC4016].
in [RFC4016]. Security considerations stemming from the use of EAP Security considerations stemming from the use of EAP and EAP methods
and EAP methods are discussed in [RFC3748] [I-D.ietf-eap-keying]. are discussed in [RFC3748] [I-D.ietf-eap-keying]. This section
This section provides a discussion on the security-related issues provides a discussion on the security-related issues that are related
that are related to PANA framework and protocol design. to PANA framework and protocol design.
An important element in assessing security of PANA design and An important element in assessing security of PANA design and
deployment in a network is the presence of lower-layer (physical and deployment in a network is the presence of lower-layer (physical and
link-layer) security. In the context of this document, lower-layers link-layer) security. In the context of this document, lower-layers
are said to be secure if they can prevent eavesdropping and spoofing are said to be secure if they can prevent eavesdropping and spoofing
of packets. Examples of such networks are physically-secured DSL of packets. Examples of such networks are physically-secured DSL
networks and 3GPP2 networks with cryptographically-secured cdma2000 networks and 3GPP2 networks with cryptographically-secured cdma2000
link-layer. In these examples, the lower-layer security is enabled link-layer. In these examples, the lower-layer security is enabled
even before running the first PANA-based authentication. In the even before running the first PANA-based authentication. In the
absence of such a pre-established secure channel, one needs to be absence of such a pre-established secure channel, one needs to be
skipping to change at page 49, line 38 skipping to change at page 49, line 38
PANA provides multiple mechanisms to secure a PANA session. PANA provides multiple mechanisms to secure a PANA session.
PANA messages carry sequence numbers, which are monotonically PANA messages carry sequence numbers, which are monotonically
incremented by 1 with every new request message. These numbers are incremented by 1 with every new request message. These numbers are
randomly initialized at the beginning of the session, and verified randomly initialized at the beginning of the session, and verified
against expected numbers upon receipt. A message whose sequence against expected numbers upon receipt. A message whose sequence
number is different than the expected one is silently discarded. In number is different than the expected one is silently discarded. In
addition to accomplishing orderly delivery of EAP messages and addition to accomplishing orderly delivery of EAP messages and
duplicate elimination, this scheme also helps prevent an adversary duplicate elimination, this scheme also helps prevent an adversary
spoof messages to disturb ongoing PANA and EAP sessions unless it can spoofing messages to disturb ongoing PANA and EAP sessions unless it
also eavesdrop to synchronize on the expected sequence number. can also eavesdrop to synchronize on the expected sequence number.
Furthermore, impact of replay attacks is reduced as any stale message Furthermore, impact of replay attacks is reduced as any stale message
(i.e., a request or answer with an unexpected sequence number) and (i.e., a request or answer with an unexpected sequence number and/or
any duplicate answer are immediately discarded, and a duplicate a session identifier for a non-existing session) and any duplicate
request can trigger transmission of the cached answer (i.e., no need answer are immediately discarded, and a duplicate request can trigger
to process the request and generate a new answer). transmission of the cached answer (i.e., no need to process the
request and generate a new answer).
The PANA framework defines EP which is ideally located on a network The PANA framework defines EP which is ideally located on a network
device that can filter traffic from the PaCs before the traffic device that can filter traffic from the PaCs before the traffic
enters the Internet/intranet. A set of filters can be used to enters the Internet/intranet. A set of filters can be used to
discard unauthorized packets, such as a PANA-Start-Request message discard unauthorized packets, such as a PANA-Start-Request message
that is received from the segment of the access network where only that is received from the segment of the access network where only
the PaCs are supposed to be connected. the PaCs are supposed to be connected.
The protocol also provides authentication and integrity protection to The protocol also provides authentication and integrity protection to
PANA messages when the used EAP method can generate cryptographic PANA messages when the used EAP method can generate cryptographic
skipping to change at page 52, line 40 skipping to change at page 52, line 40
This exchange is cryptographically protected when a PANA SA is This exchange is cryptographically protected when a PANA SA is
available in order to prevent threats associated with the abuse of available in order to prevent threats associated with the abuse of
this functionality. this functionality.
Any valid PANA answer message received in response to a recently sent Any valid PANA answer message received in response to a recently sent
request message can be taken as an indication of peer's liveness. request message can be taken as an indication of peer's liveness.
The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a The PaC or PAA MAY forgo sending an explicit PANA-Ping-Request if a
recent exchange has already confirmed that the peer is alive. recent exchange has already confirmed that the peer is alive.
11.8. IP Address Spoofing 11.8. Early Termination of a Session
PANA does not provide any means to prove ownership of the IP address
presented by the PaC. Hence, an authorized PaC can launch a redirect
attack by spoofing a victim's IP address. This problem and its
solution are outside the scope of PANA.
11.9. Early Termination of a Session
The PANA protocol supports the ability for both the PaC and the PAA The PANA protocol supports the ability for both the PaC and the PAA
to transmit a tear-down message before the session lifetime expires. to transmit a tear-down message before the session lifetime expires.
This message causes state removal, a stop of the accounting procedure This message causes state removal, a stop of the accounting procedure
and removes the installed per-PaC state on the EP(s). This message and removes the installed per-PaC state on the EP(s). This message
is cryptographically protected when PANA SA is present. is cryptographically protected when PANA SA is present.
12. Acknowledgments 12. Acknowledgments
We would like to thank Mark Townsley, Jari Arkko, Mohan We would like to thank Mark Townsley, Jari Arkko, Mohan
skipping to change at page 55, line 35 skipping to change at page 54, line 35
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
Security Association Management Protocol", RFC 4595, Security Association Management Protocol", RFC 4595,
July 2006. July 2006.
[I-D.ietf-dhc-paa-option] [I-D.ietf-dhc-paa-option]
Morand, L., "DHCP options for PANA Authentication Agents", Morand, L., "DHCP options for PANA Authentication Agents",
draft-ietf-dhc-paa-option-04 (work in progress), draft-ietf-dhc-paa-option-05 (work in progress),
September 2006. December 2006.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
13.2. Informative References 13.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
skipping to change at page 56, line 16 skipping to change at page 55, line 16
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol "State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137, August 2005. (EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-15 (work in Management Framework", draft-ietf-eap-keying-18 (work in
progress), October 2006. progress), February 2007.
[I-D.ietf-pana-ipsec] [I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA Enabling IPsec based Access Parthasarathy, M., "PANA Enabling IPsec based Access
Control", draft-ietf-pana-ipsec-07 (work in progress), Control", draft-ietf-pana-ipsec-07 (work in progress),
July 2005. July 2005.
[I-D.ietf-pana-framework] [I-D.ietf-pana-framework]
Jayaraman, P., "Protocol for Carrying Authentication for Jayaraman, P., "Protocol for Carrying Authentication for
Network Access (PANA) Framework", Network Access (PANA) Framework",
draft-ietf-pana-framework-07 (work in progress), draft-ietf-pana-framework-07 (work in progress),
skipping to change at page 59, line 7 skipping to change at page 58, line 7
Alper E. Yegin Alper E. Yegin
Samsung Advanced Institute of Technology Samsung Advanced Institute of Technology
Istanbul, Istanbul,
Turkey Turkey
Phone: +90 538 719 0181 Phone: +90 538 719 0181
Email: alper01.yegin@partner.samsung.com Email: alper01.yegin@partner.samsung.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 41 change blocks. 
97 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/