Technical Summary
This document defines the Protocol for Carrying Authentication for
Network Access (PANA), a network-layer transport for Extensible
Authentication Protocol (EAP) to enable network access authentication
between clients and access networks. In EAP terms, PANA is a UDP-
based EAP lower layer that runs between the EAP peer and the EAP
authenticator.
Working Group Summary
This working group has had an uphill battle since inception, and has
persevered through it all. In May 2006, during IETF Last Call, there
was a rather significant backlash against the documents, with
constructive comments boiling down mostly to questions of scope
and level of complexity in the protocol for the task at hand. The WG
has since hunkered down and rewritten the specs over the last year,
with improved results. The documents have been through a second
round of IETF Last Call, pointing this out in the process. A summary
of changes can be found here:
http://panasec.org/docs/listof-changes.txt
A second balloting by the IESG and third IETF last call was
performed in Sept 2007.
Protocol Quality
The protocol was reviewed in depth by Mark Townsley and Jari Arkko after
the first IETF Last Call. The protocol has improved markedly in terms of
overall complexity.
Note to RFC Editor
In Section 4.1 of pana-pana, the original paragraph reads:
The PaC may need to reconfigure IP address after successful
authentication and authorization phase to obtain an IP address that
is usable for exchanging data traffic through EP. In this case, the
PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request
messages in the authentication and authorization phase to indicate
the PaC the need for IP address reconfiguration. How IP address
reconfiguration is performed is outside the scope of this document.
Change that to (by adding a reference):
For reasons described in Section 3 of [I-D.ietf-pana-framework], the
PaC
may need to reconfigure IP address after successful
authentication and authorization phase to obtain an IP address that
is usable for exchanging data traffic through EP. In this case, the
PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request
messages in the authentication and authorization phase to indicate
the PaC the need for IP address reconfiguration. How IP address
reconfiguration is performed is outside the scope of this document.
Similarly, in Section 5.6 of pana-pana, the original paragraph reads:
A PaC's IP address used for PANA can change in certain situations,
e.g., when IP address reconfiguration is needed for the PaC to obtain
an IP address after successful PANA authentication (see Section 4.1)
or when the PaC moves from one IP link to another within the same
PAA's realm. In order to maintain the PANA session, the PAA needs to
be notified about the change of PaC address.
Change that to:
A PaC's IP address used for PANA can change in certain situations,
e.g., when IP address reconfiguration is needed for the PaC to obtain
an IP address after successful PANA authentication (see Section 3
of [I-D.ietf-pana-framework])
or when the PaC moves from one IP link to another within the same
PAA's realm. In order to maintain the PANA session, the PAA needs to
be notified about the change of PaC address.
Based on concerns about the reserved value "0" please make the following
changes:
From:
10.2.1. Message Type
The Message Type namespace is used to identify PANA messages. The
range of values 0 - 65,519 are for permanent, standard message types,
allocated by IETF Consensus [IANA]. This document defines the range
of values 1 - 4. The same Message Type is used for both the request
and the answer messages, except for type 1. The Request bit
distinguishes requests from answers. See Section 7 for the
assignment of the namespace in this specification.
to:
10.2.1. Message Type
The Message Type namespace is used to identify PANA messages.
Message Type 0 is not used and not assigned by IANA. The
range of values 1 - 65,519 are for permanent, standard message types,
allocated by IETF Consensus [IANA]. This document defines the range
of values 1 - 4. The same Message Type is used for both the request
and the answer messages, except for type 1. The Request bit
distinguishes requests from answers. See Section 7 for the
assignment of the namespace in this specification.
For the same reason, the 2nd paragraph of Section
10.3.1 should be revised from:
AVP Code 0 is not used. This document defines the AVP Codes 1-9.
See Section 8.1 through Section 8.9 for the assignment of the
namespace in this specification.
to:
AVP Code 0 is not used and not assigned by IANA. This document
defines the AVP Codes 1-9.
See Section 8.1 through Section 8.9 for the assignment of the
namespace in this specification.
IANA Note
Please note RFC Editor's note above on allocation of reserved value "0"