2.3.11 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-22

Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper@docomolabs-usa.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Erik Nordmark <erik.nordmark@sun.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:
JAN 03  Submit usage scenarios and applicability statement to the IESG
JAN 03  Submit security threat analysis to the IESG
FEB 03  Submit protocol requirements to the IESG
APR 03  Submit interaction of PANA with 802.1x and PPP document to the IESG
JUL 03  Submit protocol specification to the IESG
NOV 03  Submit MIB for PANA to the IESG
  • - draft-ietf-pana-usage-scenarios-04.txt
  • - draft-ietf-pana-requirements-04.txt
  • - draft-ietf-pana-threats-eval-02.txt
  • No Request For Comments

    Current Meeting Report

    Protocol for carrying Authentication for Network Access WG (pana)
    WEDNESDAY, March 19th, 1530-1730
    CHAIRS:    Basavaraj Patil 
    	   Alper Yegin <alper@docomolabs-usa.com>
    Thanks to Pekka Nikander and Spencer Dawkins for capturing the minutes of 
    the WG meeting,
    1. Agenda bashing and WG doc status,  10 Mins,  Chairs
    - Problem Statement and Usage Scenarios.  
      Applicability, Usage scenarios.
      Completed WG LC, issues being addressed.  
      Will be submitted to IESG after IETF56 for IETF LC.
    - Security issues and Threat Analysis.  
      WG Last Call will take place after IETF56.
    - Requirements draft.  
      WG Last Call will take place after IETF56.
    2. PANA Threat Analysis and Security Reqs.  update, 10 Mins, Mohan 
    - Removed Identify Protection after last IETF
    - Added a Device Identifier attack
    - Renamed "data protection" to "service threat"
    - Clarified trust relationships
    - Added PAA-AS path threats reference
    - ... plus editorial changes
    Main feedback:  Service theft.  Not very clear in -01, tried to clarify 
    this for this version.  How does PANA establish an SA between a client and 
    the enforcement point, if such is needed?  The established trust 
    relationship between the client and the PAA can be extended to 
    establish e.g. an IPsec SA between the client and the enforcement point.
    No questions or comments.
    3. PANA Requirements update, 10 Mins, Alper Yegin
    Updates in this revision
    - Added definition of Enforcement Point
    - Points out requirements met by EAP choice of EAP method is important
    - PaC not required to have an IP address prior to PANA
    - Added EAP lower layer requirements pointer to EAP draft
    - PAA and PaC must be exactly one IP hop away from each other not quite the 
    same as being on same physical link or multilink subnet 
    - PAA delivers authorization information to EP. PANA is looking to MIDCOM 
    for guidance/experience here
    - Please review and provide comments!
    Terminology and the requirements draft.  Missed the deadline.  Slides 
    covered the updates on the latest version.  There was discussion of IP 
    address pre-configuration. IP address configuration before PANA issue was 
    discussed at the IETF 55 and consensus was reached on the mailing list 
    shortly after the meeting. Decision is not to require PaC to have an IP 
    address prior to PANA and this is explicit in the charter.
    There was also a comment on how PANA differs from 802.1X. Since this issue 
    has been discussed several times before, the member was directed to 
    problem statement draft and asked to provide comments on the mailing list if 
    the document was not clear on that.
    Enforcement Point, doing filtering, typically based on IP address but 
    maybe using a cryptographic mechanim e.g. IPsec.
    Some of the requirements need to be satisfied by the EAP methods used.  For 
    example key generation, client identifier types, mutual 
    authentication.  Thus, the PANA protocol itself does not need to take care of 
    these.  On the other hand, the choice of EAP methods becomes more 
    important.  PANA protocol does not limit, it is an deployment decision what 
    EAP methods to use.
    Client should not be required to have an IP address prior to PANA.
    New section for EAP lower layer requirements.  rfc2284bis has a whole 
    section on what EAP requires from its transports.  Reference to this.  This 
    is what PANA should comply with as well.
    Further clarification on the location of PAA.  Confusion of what is 
    subnet etc.  One IP hop away; not necessarily on the same physical link.  
    Also not the same as in the same subnet, thanks to the multilink draft, 
    which allows IP subnets to be distributed multiple hops away.  
    Therefore the requirement of exactly one hop to avoid confusion.
    New section on PAA-EP protocol.  Authorization information needs to be 
    provided to the EP. Minimally client identifier, possibly 
    cryptographic keys would need to be transported. The protocol may need to 
    support push model, or pull model, depending on deployment scenario and who 
    is going to initiate the transaction. Goal or task of PANA WG is to 
    identify at least one such protocol.  MIDCOM is working on something 
    similar to configure firewalls and NATs.  EP is a kind of firewall.
    Please review and comment.  Volunteers sought.  Initial review needed 
    before the last call.
    John Schnizlein:  Expressed concerns that PANA was essentially the same as 
    802.1x and hence not really required. 
    Chairs mentioned that this issue has been discussed previously on the 
    mailing list and there exists a FAQ specifically that answers the 
    question of PANAs objectives. 
    Erik Nordmark:  There seems to be a tradeoff at least in the IPv4 space on 
    configuring the address first.  Service attacks against the address 
    configuration.  On the other hand, if we run the protocol without an IP 
    address we might not be able to use existing security mechanisms. There are 
    tradeoffs. But this is not like black and white.
    Alper:  We don't say PaC must have an IP address.  But say that there is a 
    John Schnizlein:  If the client doesn't need an IP address, a layer 3 
    protocol to authentication in contrast to.  Looks like 802.1x covers the 
    space.  1x is layer 2.  Seems to have the same kinds of 
    characteristics.  PaC and PAA are single layer 2 link away.  You can use the 
    protocol before an address gets assigned.  It is using EAP.  Pana is 
    starting to look at 802.1x.
    Alper:  If you can run 802.1x on other links.
    John S.:  Justifying a framing label on EAP.  Another ethertyp.
    XXX:  Second the comment.
    Hannes:  Different usage scenarios.
    Alper:  Expectation is that the lack of IP address does not change the 
    design.  There are IP protocols like DHCP in IPv4, and Mobile IPv4 that can 
    work without IP addresses as well. 
    Raj:  We have done this similarity exercise before.
    John S.:  No point in repharsing the same.  Some of the distinction for 
    PANA has now been reversed.  Previously the PAA and PaC could be several 
    links away.  Now they are on the same link.  A number of revisions made 
    recently has brought it back to the same space from which the 
    distinction was made recently.  This reopens the earlier questions. 
    Alper:  It is not an objective to make PANA very different from 802.1x.  If 
    PANA is 802.1x on IP layer that is fine.
    John S.:  Now we are talkin on a different layer but not using layer 3 
    Raj:  Using layer 3 address, the unspecified address.
    John Vollbrecht:  I don't see this either.
    Raj:  The only change in the draft was that unspecified address can be 
    Alper:  Requirement of one hop was made to simplify the protocol.
    John: Actually agree with the reason to make the changes.  
    Conclusions make a lot of sense.  Idea of making authentication before 
    setting an adress makes a lot of sense.  The requirement of being on the 
    data link makes a lot of sense.  This is exactly the funcitonal 
    specification for layer 2 authentication mechanism.  Only thing you need is 
    layer 2 message type.  All the things that
    Erik:  Maybe this is discussion that we can defer to list.  There are 
    other differences as well.
    John S.:  Two key things:  same l2 data link, before l3 address is 
    Erik:  What is the problem if it is identical?  We keep up rehashing the 
    thing over and over again.  This is not productive.  People speaking up in 
    this room have not been vocal on the mailing list.
    John Vollbrecht:  Needs to be good justification not to use 802.1x.  
    Having hard time not to consider 802.1x.  Need a description of the 
    Alper:  Please read the problem statement and usage scenarios draft and get 
    on the PANA mailing list and provide comments. We are not going to 
    discuss this issue at the next meeting.
    Paul Congdon:  IEEE is working on 802.1x.  Suggesting some sort of liason 
    between 802.1x and PANA.
    Raj:  Not trying to replace 802.1x.  It can be used.  There are use cases 
    where you don't have 802.1x.
    4. PANA Protocol Solution, 60 Mins, Design Team
    Presented by Hannes T.  
    Described the difference between the PANA framework and the PANA 
    Different environments, different usage scenarios, depending on how much L2 
    security there is.  Difficult to support all in a single protocol.  
    Obvious that we need to use EAP.
    Working assumptions:
    - need to have some topology knowledge
    - device identifier provides enough security in some enviornments
    - l2 disconnect indication cannot be assumed
    - in many cases you need to establish a session key
    Discovery.  A few mechanisms:
    - multicast UDP send by the client
    - enforcement point sends a PANA_START
    Threats.  Discovery procedure is always vulnerable to MitM and DoS.  
    Fairly difficult to protect against these.  Prevent off-path attacks, 
    memory space exhaustion.  Design based on cookies and a message 
    exchange.  PAA sends an implementation dependent cookie, client repeats the 
    UDP to carry EAP.  Counter some threats.  Heavily depend on the choice of 
    the EAP method.
    PANA relies on EAP method fragmentation or IP fragmentation.  PANA 
    provides ordered delivery on the top of UDP.
    Sequence number handling for ordered deliver of messages.  Three 
    different methods considered.  Chosen dual-sequence number with orderly 
    delivery.  Might want to have a look at the appendix of the draft to learn 
    the reasons for the choice.
    SA to protect subsequent PANA messages.  Re-authentication, 
    disconnect.  Same key material may be used to bootstrap layer 2 or layer 3 
    security associations.  Again, selection of EAP methods very 
    Hesham Soliman:  No algorithm negotiation.  Do we need that to boostrap 
    layer 3?
    Answer:  No algorithm is only related to PANA SA, not to the layer 2 or 
    layer 3 SA creation.
    No outer (secure) tunnel establishment, i.e. outside of the EAP 
    PANA does not protect against using weak EAP methods in hostile 
    environments.   You have to use something like PEAP or EAP-TTLS.  These 
    have their problems, but fixing those is outside the PANA WG.
    Device Identifier attribute used to establish a filter rule on the 
    enforcement point.  When EP an PAA are not co-located, a protocol is 
    needed.  This is not the PANA protocol.  MIDCOM WG seems to offer a 
    protocol.  PANA WG will select one of those.  PANA WG does not create 
    their own MIDCOM like protocol.
    Assumption that cannot always assume disconnect indication.  Therefore need 
    re-authentication and garbage collection.  Threat of theft of service, one 
    previously used by someone else.  Soft state principle.  (See slides)
    A message to terminate the session, to stop accounting.  Or to revoke or 
    stop network access by the network.
    Identified a number of open issues, to be discussed in the mailng list.  
    (See slide)
    Woojune Kim: Disconnect.  Re-authentication from client side.  
    Re-authentication looks like a keepalive message.  Is 
    disconnecting a PANA protocol, is PANA supposed to do that.
    Answer.  Unfortunately you don't have link layer disconnect 
    indication on all links. These messages are used to voluntarily stop the 
    network access.
    Woojune Kim:  It's hard to see the usefulness.
    Derek Atkins:  Operationally you can't rely on that.  You can get a 
    crash.  You just need L2 indication, or you need to have like a TCP 
    session that keeps up all time and has keep alives.
    Answer:  Fully agree.  Only sending keepalives is not secure.  
    Therefore re-authentication is needed.
    Hesham Soliman:  Why not rely on a timer?
    Answer: Reauth depends on a timer.  But there are cases where you don't 
    want to wait for a timer.
    Woojune Kim:  Re-auth is like keep-alives.
    Answer:  Keep-alive is unprotected, this is protected.
    Alper:  We are we discussing whether the protocol should have such a 
    message, or whether the architecture should *rely* on this message.
    Answer:  It is optional, you might want to send it.
    Alper:  Applicability depends on environment, not a protocol design 
    Shivar Ranamana?:  Is AAA going to be used mainly for session key 
    Answer:  AAA simply carries the EAP messages.  On the other hand the 
    session key is carried from the EAP endpoint to the PAA over the AAA 
    Shivar:  PANA diameter?
    Answer:  If you don't terminate the EAP in the PAA, it must go to the AAA 
    infrastrecure somehow.  These rely on the standard AAA protocols.  No new 
    requirements from PANA to AAA.
    Derek:  Assumptions that have been made but not explicit.  How often doing 
    re-authentication?  How often reauth with EAP?  Annoy the user with 
    "retype your password"?  User password for long living 
    authentication.  EAP once an hour.  PANA keep-alive:  you are still here.  
    Answer:  EAP reauth goes back to home AAA:  Policy issue, PANA cannot 
    enforce.  Negotiation of re-authentication lifetime is a 
    possibility.  Might want to do re-auth more often, depending on the 
    Derek:  E.g. PPP connection.  You can stay as long as want, never have to 
    type password again.  Want WLAN to be the same.
    Alper:  Current design provides all you want.  The issue of mixture is a 
    deployment decesion.
    Derek:  PANA should say something, mention these.
    Alper:  We can have a considerations section, but can not provide any 
    numbers for the frequency of these messages.
    Derek:  You can have just a discussion, which ones should be low, which 
    ones high.
    Hesham:  PANA guidelines should say how to configure.
    Presenter:  This is an open issue, we can have text on how these are 
    changed etc.
    Alper:  I don't think we need to build a negotiation for how often these 
    messages should be generated. They can be initiated by either side 
    Raj:  If you have L2 disconnect indication, you don't necessarily need 
    re-authentication.  Can happen as triggered by the PAA.  But if there is no 
    L2 disconnectio indication, then you may want to negotiate re-auth every 
    five minutes or so.
    Woojune Kim: Need to have both, have to configure correctly.
    Dan Forsberg:  We can consider a third option: Session resumption.  It has 
    more complexity though.
    Answer:  Some EAP methods have fast reconnect you do not need to go back to 
    your home AAA server.
    Discussion of IPsec SA setup between the PaC and the EP:
    Alper: PANA protocol creates a PANA SA.  PANA SA is not sufficent to 
    create access control in certain enviornments.  For example if DI is not 
    enough for filtering.  In shared links DI is not sufficient.  The 
    attackers can spoof.  Need to deploy crypto based access control.  If the 
    link layer does not provide, as a last resort the deployment can use 
    IPsec.  PANA SA is not the same as the IPsec SA.  Somehow PANA key 
    material must be converted to IPsec SA. Outside the scope of the PANA 
    protocol, but should the WG investigate this?  Hopefully an 
    informational RFC as a guideline document.  Use PANA key material and feed to 
    Hesham:  Using PANA SA to initiate an IPsec SA?  Feeding something to IKE?
    Alper:  Yes.  
    Hesham:  IPsec must be between PaC and EP.
    Alper: Need to look at when PAA and EP separate.
    Hesham:  PaC does not know if EP and PAA are co-located
    James Kempf:  Russ Housley gave a presentation at AAA.  AAA must satisfy for 
    key distribution.  Very good presentation.  Would clarify this issue.
    Alper:  Question to WG:  Should we look at this problem?
    Hesham:  Want to add:  Run over both secure and non-secure links.
    Natural that this is something to have a look at.
    Sense the room.  
    - should do:  15
    - should not:  4
    Rough consensus is to look.  Discuss on the mailing list.
    5. Next Steps, 5 Mins, Chairs
    Please get on the mailing list to raise any issues on the problem 
    statement document. We should also start discussing PAA-EP protocol on the 
    mailing list.


    PANA Terminology and Requirements I-D: Update
    PANA Threat Analysis and Security Requirements
    IPsec SA Setup
    Protocol for Carrying Authentication for Network Access - General