2.3.11 Protocol for carrying Authentication for Network Access (pana)

Last Modified: 2003-08-26

Chair(s):
Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper@docomolabs-usa.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: pana@research.telcordia.com
To Subscribe: pana-request@research.telcordia.com
In Body: (un)subscribe
Archive: ftp://ftp.research.telcordia.com/pub/Group.archive/pana/archive
Description of Working Group:
In some scenarios, an IP-based device is required to authenticate
itself to the network prior to being authorized to use it. This
authentication usually requires a protocol that can support various
authentication methods, dynamic service provider selection, and
roaming clients. In the absence of such an authentication protocol on
most of the link-layers, architectures have resorted to filling the gap
by using a number of inadequate methods. For example, inserting an
additional layer between link-layer and network-layer mostly for client
authentication purpose (e.g., PPPoE), overloading another network-layer
protocol to achieve this goal (e.g., Mobile IPv4 with Registration-
required flag), and even defining application-layer ad-hoc
authentication mechanisms (e.g., http redirects with web-based login).
In these and other cases, a network-layer authentication protocol may
provide a cleaner solution to the authentication problem.

The goal of PANA is to define a protocol that allows clients to
authenticate themselves to the access network using IP protocols. Such
a protocol would allow a client to interact with a site's back-end AAA
infrastructure to gain access without needing to understand the
particular AAA infrastructure protocols that are in use at the
site. It would also allow such interactions to take place without a
link-layer specific mechanism. PANA would be applicable to both
multi-access and point-to-point links. It would provide support for
various authentication methods, dynamic service provider selection,
and roaming clients.

Mobile IPv4 developed its own protocols for performing PANA-like
functions (e.g., MN-FA interaction). Mobile IPv6 does not have the
equivalent of a Foreign Agent (FA) that would allow the access/visited
network to authenticate the MN before allowing access. The PANA
authentication agent (PAA) can perform the authentication function
attributed to the FA in Mobile IPv4, in Mobile IPv6 networks.

The WG will work with the assumption that a PANA client (PaC) is
already
configured with an IP address before using PANA. This IP address will
provide limited reachability to the PaC until it is authenticated with
the PAA. Upon successful authentication, PaC is granted broader network
access possibly by either a new IP address assignment, or by
enforcement
points changing filtering rules for the same IP address.

PANA will neither define any new authentication protocol nor define key
distribution, key agreement or key derivation protocols. It is believed
that PANA will be able to meet its goals if it is able to carry EAP
payloads. Note, however, that EAP may need to be extended in order for
PANA to meet the need for all of its intended usages. Such extensions
are outside the scope of the PANA WG.

PANA will develop an IP-based protocol that allows a device to
authenticate itself with the network (and to a PAA in particular) in
order to be granted network access. For simplicity, it is assumed that
the PAA is attached to the same link as the device (i.e., no
intermediary IP routers). The PAA itself may interface with other AAA
backend infrastructures for authenticating and authorizing the service
being requested by the host, but such interactions are transparent to
the PaC.

The PAA does not necessarily act as an enforcement point (EP) to
prevent unauthorized access or usage of the network. When a PaC
succesfully authenticates itself to the PAA, EP(s) (e.g., access
routers) will need to be suitably notified. This WG will identify a
(preferably existing) protocol solution that allows the PAA to deliver
the authorization information to one or more EPs when the PAA is
separated from EPs. A single PAA may serve many access routers. The WG
will also propose a solution of how the PaC discovers the IP address of
PAA for sending the authentication request.

The PANA WG will deliver 

- A mechanism for the PAC to discover the PAA on the link.

- The PANA protocol itself, capable of carrying multiple authentication
    methods (e.g. using EAP)

- Select or define a protocol to carry authorization information
between
    the PAA and the EPs.
Goals and Milestones:
Done  Submit usage scenarios and applicability statement to the IESG
Done  Submit security threat analysis to the IESG
Done  Submit protocol requirements to the IESG
Dec 03  Submit IPsec-based access control to the IESG
Dec 03  Submit protocol specification to the IESG
Jan 04  Submit interaction of PANA with 802.1x and PPP document to the IESG
Apr 04  Submit MIB for PANA to the IESG
Internet-Drafts:
  • - draft-ietf-pana-usage-scenarios-06.txt
  • - draft-ietf-pana-requirements-07.txt
  • - draft-ietf-pana-threats-eval-04.txt
  • - draft-ietf-pana-pana-01.txt
    • No Request For Comments

    Current Meeting Report

     
    quicker.Protocol for Carrying Authentication for Network Access (PANA) WG 
Meeting MinutesSession: Monday, July 14 at 1300-1500Chairs:  Basavaraj Patil 
<Basavaraj.Patil@nokia.com>         Alper Yegin <alper@docomolabs-usa.com>Note Takers: Jayshree Bharatia, Paulo PagliusiTopic 1. Draft Status
----------------------------------------
---------------------------------Short discussion on the current document status was given by the AlperYegin.-  draft-ietf-pana-usage-scenarios-06.txt   WG last call completed on March 11, 2003. Draft is sent to ADs for IESG 
consideration.-  draft-ietf-pana-requirements-07.txt   WG last call completed on June 12, 2003. Draft is sent to ADs for IESG 
consideration.-  draft-ietf-pana-threats-eval-04.txt   WG last call completed on May 1, 2003. Draft is sent to ADs for IESG 
consideration.-  draft-ietf-pana-pana-01.txt   Work in progress. The draft will be discussed at IETF 57.Topic 2- Securing the first hop in PANA using IPsec by Hannes 
Tschofenig
----------------------------------------
---------------------------------The intent of the draft was discussed in brief. This draft provides a 
mechanism for enabling IPsec-based per-packet authentication between the PaC 
and EP, once the client is authenticated by using PANA. IKE 
pre-shared key is derived from the PANA SA, which is established when PaC 
and PAA authenticate to each other.  Pre-shared key is derived from the 
PANA SA. It was mentioned that manual key distribution is not used. Main 
mode and aggressive  mode are easily supported. There may not be any 
issues for IPv4. For IPv6, the router and neighbor discovery related 
extensions are different. Also, the initial problem may be that IPSec 
selector can't be used as a traffic selector. All packets are tunneled to 
the link local address of the EP. The packets are protected twice, for 
local and the remote networks. IKE pre-shared key derivation is done from 
the PANA security association. The recommendation was to use the IPSec 
tunnel mode instead of the IP-IP Transport mode.Hesham Soliman - The problem of the selector seems like the 
implementation problem which may be solvable. This comments was revised 
later in the discussion based on the different understanding.? - It is necessary for PANA WG to contact IPSec WG for solution of the 
selector problem. Keys are for the bootstrapping IKE. If this is the case 
than it will be more complicated.James Kempf -  If PANA is already solving the PAA and host(MN) security 
problem, why it is necessary to have IKE exchanges?Alper Yegin - The current mechanism allows binding of the client ID to the 
data traffic. The PANA association is not exactly the IPSec 
association. There needs to be some kind of binding between them.James Kempf - Can't we just carry EAP inside IKEv2?Alper Yegin - Are you suggesting replacing PANA with IKEv2?James Kempf - No, run IKEv2 independent of and after PANA.Alper Yegin - Let's take this offline and discuss on the PANA mailing 
list.Brijesh Kumar - I am not convinced that the mechanism described in this 
particular I-D is useful, since link layer security mechanism already 
provides enough security. There is no need to run IPsec twice on a single 
client.? - The end points are different and they provide different level of 
security. The safe assumption here is that there may not be security 
support at the layer 2.Chairs did a consensus call on whether or not to adapt this 
individual submission as an official WG item, given that the WG had 
already agreed to tackle this problem space. 15 people said agreed, 5 
disagreed to the adoption of this draft.Conclusion: There is consensus on the adoption of this draft as an 
official WG item.Topic 3. PAA-EP Protocol Considerations: By Yacine El Mghazli
----------------------------------------
---------------------------------- Terminology like PAA, PaC, EP were discussed in brief along with the 
scenario description of PAA/EP separation (when PAA separated from AR and 
also when PAA co-located with AR.- The following PAA-EP Protocol Requirements were mentioned. The details of 
these requirements are noted at 
http://yacine.free.fr/ie
tf/draft-yacine-pana-paa-ep-reqs.txt.  a. Discussion objectives    - No new PANA protocol design    - Use of existing protocol  b. Core Requirements    - pana-req-07 document is used as a base    - Secure    - one-many PAA-EP relationship    - Provisioned data  c. Nice to have functionality    - Pull model    - Inactive peer detection    - recovery- The Protocol Comparison discussion included comparison of SNMP, 
COPS-PR, DIAMTER and ForCES protocols.  1. SNMP Applicability: Description on how SNMP satisfies the current 
requirements and also few pros and cons are discussed.  2. COPS-PR: Same as SNMP, it satisfies most of the requirements but 
seems like having more advantages.  3. DIAMETER: It satisfies all requirements but not meant to be used for 
provisioning.  4. ForCES: This protocol is still being discussed. Otherwise seems like 
satisfying most of the requirements.Gabriel Montenegro - What is the relationship between this subject and 
CAPWAP (BOF)?Alper Yegin - This is about provisioning, and it is not PANA protocol. 
CAPWAP has also some aspects of this. This is a good question, let's ask it 
at CAPWAP meeting as well.Ralph Droms - What about NETCONF as another PAA-EP protocol 
candidate?Alper Yegin - Sure, we should look at that too.Reinaldo Penno - Let's do not waste too much time in the Protocol 
evaluation process. Let's make it quick and simple.Conclusion:The topic is still open to the discussion. There may be a need of 
coordination with other IETF work groups like netconf.Topic 4. PANA Discussion and Open Issues:
----------------------------------------
---------------------------------The list of PANA issues can be found at
http://danforsberg.info:8080/pana-issues/.Issue 9:Issue: Message format not defined in the 00 draftProposed solution: Diameter-like message format is suggested to be used 
(header+AVP)Issues 4,5,16:  1. Device ID needs to be updated     Proposal is to use Re-auth command which contains new device ID.  2. MAC and IP address are used at the same time     Couple of proposals are discussed: Support either MAC or IP address as 
DI and not both addresses at the same time or use both addresses 
(assuming that SEND will solve the issue).     Alper Yegin - Is it really useful to bootstrap 2 layers of 
ciphering?     Pasi Eronen - Both L2 and L3 may be useful, 3GPP does that.     Alper Yegin - What is the purpose of two layers of ciphering in 3GPP?     Pasi Eronen - One for the local access, one for the remote access to 
home domain.     John Vollbrecht - Is this same as EAP with MASTER KEY and Multiple 
Session Keys?     Alper Yegin - Yes, it is.  3. In single Device ID, use multiple IP addresses.     PaC can have multiple IP addresses on the same interface. This may not 
be issue since it is not required to have different interfaces 
specified for all IP address, Is this sufficient or is there any need of 
mentioning all IP addresses as DI and bind to session.     Melinda Shore - Why do we use DI in PANA (regarding the use of 
addresses as identifiers)?     Alper Yegin - We need it to bind the authenticated client to its 
associated data traffic.     ? - Change of address in the middle of session should be looked at as 
well.     Ralph Droms - What is the impact of IPv6 privacy addresses on DI?     Alper Yegin - Generally link-local IPv6 address is used as Device ID. 
Hence, if the inner IP address change, there shouldn't be any problem.Issue 6:How can a PANA session identified? The proposal was to use new 
session-Id.Issue 3:New section is added to the document describing PANA security 
association establishment (section 5.0).Issue 8:The discussion took place on what parameter should PAA communicate to 
perform re-authentication. Session lifetime and Refresh interval were 
mentioned.Issue 11:For the PANA client notification, the author added new section 4.10. Also, 
PAA-EP protocol is evolved to solve this problem.Issue 7:Moving context from one PAA to another PAA may be required for the 
performance reason. The new section 4.9 (Mobility Handling) is added 
describing this.Issue 15:It was mentioned that the cookie mechanism defined for the discovery and 
handshake phase might not be effective for controlling the on-link 
attackers. In Puzzle mechanism, PAA sends a challenge that does not need a 
shared secret for a PaC to respond but need some calculation on PaC. The 
current proposal is to make cookie as a default and study more on the 
security aspects of puzzle and include it in some separate document.Issues 18,19:Some of the result codes ported from the DIAMETER are intended to be used 
for the PANA-Result-Request message.Issue 1,3:The discussion took place whether PANA needs to support capability 
negotiation. The capability negotiation outside of the EAP can be placed for 
downgrading the  attack. The proposed solution is to support 
capability indication.Topic 5. Next steps
----------------------------------------
---------------------------------Basavaraj Patil talked about the next steps for the WG. PANA-IPsec draft 
will be updated based on the feedback. The goal is to finish the PANA 
protocol specification by next IETF. Provisioning protocol 
discussions will continue on the PANA mailing list. We will arrange an 
interoperability testing among the implementors of PANA.

    Slides

    Protocol for Carrying Authentication for Network Access
    PANA enabling IPsec based Access control
    PAA-EP protocol considerations
    PANA Discussion and Open Issues
    Next Steps