draft-ietf-pana-pana-15.txt   draft-ietf-pana-pana-16.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: November 4, 2007 Toshiba Expires: December 14, 2007 Toshiba
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
A. Yegin A. Yegin
Samsung Samsung
May 3, 2007 June 12, 2007
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-15 draft-ietf-pana-pana-16
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 November 4, 2007. This Internet-Draft will expire on December 14, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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
skipping to change at page 18, line 38 skipping to change at page 18, line 38
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, session identifier, etc. flags, session identifier, etc.
o The message type is one of the expected types in the current o The message type is one of the expected types in the current
state. Specifically the following messages are unexpected and state. Specifically the following messages are unexpected and
invalid: invalid:
* In the authentication and authorization phase and the * In the authentication and authorization phase:
re-authentication phase:
+ PANA-Client-Initiation after completion of the initial + PANA-Client-Initiation after completion of the initial
PANA-Auth-Request and PANA-Auth-Answer exchange. PANA-Auth-Request and PANA-Auth-Answer exchange.
+ Re-authentication request. + Re-authentication request.
+ The last PANA-Auth-Request as well as ping request before + The last PANA-Auth-Request as well as ping request before
completion of the initial PANA-Auth-Request and completion of the initial PANA-Auth-Request and
PANA-Auth-Answer exchange. PANA-Auth-Answer exchange.
skipping to change at page 26, line 16 skipping to change at page 26, line 16
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' the sub-type (i.e., request or answer) is identified via the 'R'
(Request) bit in the Message Flags field of the PANA message header. (Request) bit in the Message Flags field of the PANA message header.
Every PANA message MUST contain a message type in its header's Every PANA message MUST contain a message type in its header's
Message Type field, which is used to determine the action that is to Message Type field, which is used to determine the action that is to
be taken for a particular message. Figure 3 lists all PANA messages be taken for a particular message. Figure 3 lists all PANA messages
defined in this document: defined in this document:
Message-Name Abbrev. ID PaC<->PAA Ref. Message Name Abbrev. Message PaC<->PAA Ref.
---------------------------------------------------------- Type
----------------------------------------------------------------
PANA-Client-Initiation PCI 1 --------> 7.1 PANA-Client-Initiation PCI 1 --------> 7.1
PANA-Auth-Request PAR 2 <-------> 7.2 PANA-Auth-Request PAR 2 <-------> 7.2
PANA-Auth-Answer PAN 2 <-------> 7.3 PANA-Auth-Answer PAN 2 <-------> 7.3
PANA-Termination-Request PTR 3 <-------> 7.4 PANA-Termination-Request PTR 3 <-------> 7.4
PANA-Termination-Answer PTA 3 <-------> 7.5 PANA-Termination-Answer PTA 3 <-------> 7.5
PANA-Notification-Request PNR 4 <-------> 7.6 PANA-Notification-Request PNR 4 <-------> 7.6
PANA-Notification-Answer PNA 4 <-------> 7.7 PANA-Notification-Answer PNA 4 <-------> 7.7
----------------------------------------------------------- ----------------------------------------------------------------
Figure 3: Table of PANA Messages Figure 3: Table of PANA Messages
Every PANA message defined MUST include a corresponding ABNF Every PANA message defined MUST include a corresponding ABNF
[RFC2234] specification, which is used to define the AVPs that MUST [RFC2234] specification, which is used to define the AVPs that MUST
or MAY be present. The following format is used in the definition: or MAY be present. The following format is used in the definition:
message-def = Message-Name "::=" PANA-message message-def = Message-Name "::=" PANA-message
message-name = PANA-name message-name = PANA-name
skipping to change at page 37, line 30 skipping to change at page 37, line 30
Required, the request is posted to the PANA WG mailing list (or, if Required, the request is posted to the PANA WG mailing list (or, if
it has been disbanded, a successor designated by the Area Director) it has been disbanded, a successor designated by the Area Director)
for comment and review, and MUST include a pointer to a public for comment and review, and MUST include a pointer to a public
specification. Before a period of 30 days has passed, the Designated specification. Before a period of 30 days has passed, the Designated
Expert will either approve or deny the registration request and Expert will either approve or deny the registration request and
publish a notice of the decision to the PANA WG mailing list or its publish a notice of the decision to the PANA WG mailing list or its
successor. A denial notice must be justified by an explanation and, successor. A denial notice must be justified by an explanation and,
in the cases where it is possible, concrete suggestions on how the in the cases where it is possible, concrete suggestions on how the
request can be modified so as to become acceptable. request can be modified so as to become acceptable.
An IANA registry for PANA needs to be created by IANA.
10.1. PANA UDP Port Number 10.1. PANA UDP Port Number
PANA uses one well-known UDP port number Section 6.1), which needs to PANA uses one well-known UDP port number Section 6.1), which needs to
be assigned by the IANA. be assigned by the IANA.
10.2. PANA Message Header 10.2. PANA Message Header
As defined in Section 6.2, the PANA message header contains two As defined in Section 6.2, the PANA message header contains three
fields that requires IANA namespace management; the Version, Message fields that requires IANA namespace management; the Version, Message
Type and Flags fields. Type and Flags fields.
10.2.1. Version 10.2.1. Version
The Version namespace is used to identify PANA versions. The Version The Version namespace is used to identify PANA versions. The Version
values are assigned by Standards Action [IANA]. This document values are assigned by Standards Action [IANA]. This document
defines the Version 1. defines the Version 1.
10.2.2. Message Type 10.2.2. Message Type
The Message Type namespace is used to identify PANA messages. Values The Message Type namespace is used to identify PANA messages. Values
0-65,519 are for permanent, standard message types, allocated by IETF 0-65,519 are for permanent, standard message types, allocated by IETF
Consensus [IANA]. This document defines the Message Types 1-4. See Consensus [IANA]. This document defines the Message Types 1-4. The
Section 7.1 through Section 7.7 for the assignment of the namespace same Message Type is used for both the request and the answer
in this specification. messages, except for type 1. The Request bit distinguishes requests
from answers. See Section 7 for the assignment of the namespace in
this specification.
The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are
reserved for experimental messages. As these codes are only for reserved for experimental messages. As these codes are only for
experimental and testing purposes, no guarantee is made for experimental and testing purposes, no guarantee is made for
interoperability between the communicating PaC and PAA using interoperability between the communicating PaC and PAA using
experimental commands, as outlined in [IANA-EXP]. experimental commands, as outlined in [IANA-EXP].
10.2.3. Flags 10.2.3. Flags
There are 16 bits in the Flags field of the PANA message header. There are 16 bits in the Flags field of the PANA message header.
This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A') and 4 This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A') and 4
('P'). The remaining bits MUST only be assigned via a Standards ('P') in Section 6.2. The remaining bits MUST only be assigned via a
Action [IANA]. Standards Action [IANA].
10.3. AVP Header 10.3. AVP Header
As defined in Section 6.3, the AVP header contains three fields that As defined in Section 6.3, the AVP header contains three fields that
requires IANA namespace management; the AVP Code, AVP Flags and requires IANA namespace management; the AVP Code, AVP Flags and
Vendor-Id fields where only the AVP Code and AVP Flags create new Vendor-Id fields where only the AVP Code and AVP Flags create new
namespaces. namespaces.
10.3.1. AVP Code 10.3.1. AVP Code
The 16-bit AVP Code namespace is used to identify attributes. There The 16-bit AVP Code namespace is used to identify attributes. There
are multiple namespaces. Vendors can have their own AVP Codes are multiple namespaces. Vendors can have their own AVP Codes
namespace which will be identified by their Vendor-ID (also known as namespace which will be identified by their Vendor-ID (also known as
Enterprise-Number) and they control the assignments of their Enterprise-Number) and they control the assignments of their
vendor-specific AVP codes within their own namespace. The absence of vendor-specific AVP codes within their own namespace. The absence of
a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace. a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace.
The AVP Codes and sometimes also possible values in an AVP are The AVP Codes and sometimes also possible values in an AVP are
controlled and maintained by IANA. controlled and maintained by IANA.
AVP Code 0 is not used. This document defines the AVP Codes 1-10. AVP Code 0 is not used. This document defines the AVP Codes 1-8.
See Section 8.1 through Section 8.8 for the assignment of the See Section 8.1 through Section 8.8 for the assignment of the
namespace in this specification. namespace in this specification.
AVPs may be allocated following Designated Expert with Specification AVPs may be allocated following Designated Expert with Specification
Required [IANA] or Standards Action. AVPs with 'M' bit set MUST be Required [IANA] or Standards Action. AVPs with 'M' bit set MUST be
allocated by Standards Action. allocated by Standards Action.
Note that PANA defines a mechanism for Vendor-Specific AVPs, where Note that PANA defines a mechanism for Vendor-Specific AVPs, where
the Vendor-Id field in the AVP header is set to a non-zero value. the Vendor-Id field in the AVP header is set to a non-zero value.
Vendor-Specific AVPs codes are for Private Use and should be Vendor-Specific AVPs codes are for Private Use and should be
skipping to change at page 46, line 27 skipping to change at page 46, line 27
progress), February 2007. 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-08 (work in progress), May 2007.
August 2006.
[I-D.ietf-pana-snmp] [I-D.ietf-pana-snmp]
Mghazli, Y., "SNMP usage for PAA-EP interface", Mghazli, Y., "SNMP usage for PAA-EP interface",
draft-ietf-pana-snmp-06 (work in progress), June 2006. draft-ietf-pana-snmp-06 (work in progress), June 2006.
[ianaweb] IANA, "Number assignment", http://www.iana.org. [ianaweb] IANA, "Number assignment", http://www.iana.org.
[IANA-EXP] [IANA-EXP]
Narten, T., "Assigning Experimental and Testing Numbers Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
skipping to change at page 48, line 9 skipping to change at page 48, line 9
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Alper E. Yegin Alper E. Yegin
Samsung Advanced Institute of Technology Samsung Advanced Institute of Technology
Istanbul, Istanbul,
Turkey Turkey
Phone: +90 538 719 0181 Phone: +90 533 348 2402
Email: alper01.yegin@partner.samsung.com Email: alper.yegin@yegin.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). 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
 End of changes. 14 change blocks. 
20 lines changed or deleted 23 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/