2.3.13 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-16

Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper@docomolabs-usa.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: pana@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/pana
In Body: (un)subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/pana
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
  • - draft-ietf-pana-usage-scenarios-06.txt
  • - draft-ietf-pana-requirements-07.txt
  • - draft-ietf-pana-threats-eval-04.txt
  • - draft-ietf-pana-pana-02.txt
  • - draft-ietf-pana-ipsec-00.txt
  • No Request For Comments

    Current Meeting Report

    Protocol for Carrying Authentication for Network Access WG (pana)
    Tuesday, November 11 at 0900-1130
      Basavaraj Patil 
      Alper Yegin 
    Note Takers: Dan Forsberg, Mohan Parthasarathy
    1. Preliminaries (bluesheets, minute takers, agenda bashing): 5 min  Chairs
    Dan will take minutes.
    Mohan will take minutes.
    Raj went through the agenda and document statuses.
    STATUS of WG I-Ds:
    -  draft-ietf-pana-usage-scenarios-06.txt
       WG last call completed on 3/11/03. Draft is sent to ADs for IESG consideration.
    -  draft-ietf-pana-requirements-07.txt
       WG last call completed on 6/12/03. Draft is sent to ADs for IESG consideration.
    -  draft-ietf-pana-threats-eval-04.txt
       WG last call completed on 5/1/03. Draft is sent to ADs for IESG consideration.
    -  draft-ietf-pana-pana-02.txt
       Work in progress. I-D will be discussed at IETF 58.
    -  draft-ietf-pana-ipsec-00.txt
       Work in progress. I-D will be discussed at IETF 58.
    2. PANA protocol update and open issues: 30 min, Yoshihiro Ohba
       raft-ietf-pana-pana-02.txt. See "Change History" section of the draft
       for the list of issues closed in this revision. Detailed issue descriptions can
    	 be found at http://danforsberg.info:8080/pana-issues/
       Newly closed issues and currently open issues will be covered in this presentation
    	 for confirming/achieving consensus.
    Dan: change the URL of open issues on the first slide (take away the "www").
    Closed issues:
    Issue22, R-flag is used to distinguish request and answer.
    Issue23, shared code space with Diameter.
    Issue17, PANA-Error is defined.
    Issue24, avp alignment rule is added.
    Issue18, PANA-Termination-Cause AVP values are defined.
    Issue19, Result-Code AVP values are defined.
    Other issues:
    Issue25. Relates to ISP selection.
    Issues21, 26, 30.
    Issue20. Retransmission timers and counters. Two classes for retransmission values:
    	 PANA-PAA-Discover and other messages.
    Issue25. Service Profile names. Define two new AVPs. NAP-Information and ISP-Information
    	 AVPs. Defined a new flag (S). F-flag is not needed anymore. PAA advertises NAPs
    	 and ISPs (information AVPs).
    Open issues:
    Issue34. NAP and ISP authentications. Proposed solution: use single lifetime (the
    	 smallest one). Both NAP and ISP re-authentications happen at the same time.
    Issue37. Unknown realm propagation. Should unknown realm AAA message routing error
    	 be propagated to PaC. Direct interface between PAA and AAA would be needed.
    Alper: Yoshi, do we know how other EAP lower layers behave in this case?
    Yoshi: IEEE 802.1x doesn't carry any unknown errors.
    Raj: Is it required to use EAP layer? Can't we send unknow error message through
    	 PANA? You need direct interface between PANA and AAA? Or is it an EAP state
    	 machine problem?
    Yoshi: EAP state machine doesn't allow this. My opinion is that this complicates the
    Raj: ok.
    Mohan: How can PANA error message communicate this problem?
    Raj: You introduce PANA-Error message, why not use that?
    Yoshi: We can use PANA-Error message to propagate msg from PAA to PaC. The problem is
    	 between AAA and PAA.
    Raj: Does this mean that we need to do enhancement to the AAA spec?
    Yoshi: no changes to the spec., but to the API perhaps.
    Raj: let's take this into further discussions.
    Issue29: EAP Failure and PANA-Bind-Request. Problematic with NAP and ISP authentication.
    	 Single PANA-Termination-Request can't be used. We may want to change the "bind"
    	 to "result". "bind" doesn't make sense to carry EAP-Failure.
    Raj: the consequence of EAP failure is termination of the session. Can we you use Result
    	-Code in the PANA-Terminatin-Request?
    Yoshi: Could you elaborate.
    Raj: EAP failure means session termination?
    Yoshi: EAP failure doesn't always mean termination of the session. Sometimes two EAP
    	 authentications may occur (NAP and ISP). The two authentications can be
    	 completely independent.
    Issue36. Re-authentication race condition. Resolution: PAA can always be the winner.
    Issue35. EP information. Device-Id AVP can have a field to indicate whether the device
    	 belongs to PAA or a separate EP. This AVP is carried in PANA-Bind-Request.
    Yoshi: the format we can discuss on the mailing list.
    Issue16. Multihoming support. Same or separate session? This is an optimization issue.
    	 Proposed resolution: more thorough analysis needed. Until the analysis is done,
    	 separation is enough.
    Alper: I agree with the proposed resolution. How we bind the device id to the pana
    	 session. We need a good analysis on this and we should look on the impact on
    	 the base design.
    Mohan: How 802.11 does handle this?
    Yoshi: separate session if the mac address is different. 802.1x doesn't use the term
    Issue12: authentication in ad-hoc network scenario. Should PANA support ad-hoc network
    	 scenario where there can be multiple untrusted nodes in between PaC and PAA.
    Hannes: we did an experimental of this. This is not a request to do additional
    	 requirements, but possibility.
    Yoshi: How does the PaC find the PAA?
    Hannes: uses concept from RSVP, router alert option. So it would find the path to the
    	 internet and hit
    Thomas: how is this different to the scenario to the scenario where other nodes can
    	 interfere to the communicates?
    Hannes: different mechanism is the discovery mechanism. This would work only if you
    	 would start IPSec. 
    Raj: other requirements say that PaC and PAA must be on the first IP hop.
    Thomas: are the intermediate nodes ip nodes or l2 nodes?
    Hannes: ip nodes. We wanted to show the possibilities and results of our experiment.
    Thomas: if this is out of the scope, why we have this conversation at all.
    Issue2. Downgrading protection. This is an EAP problem. Use EAP-GSSAPI to negotiate
    	 EAP in secure way.
    Hannes: we should leave this to the EAP, since this is not a PANA issue.
    Alper: let's send these open issues to the list. Follow up on the discussion on the
    	 mailing list.
    3. PAA-to-EP protocol considerations: 15 min, Yacine El Mghazli
       draft-yacine-pana-paa2ep-prot-eval-00.txt. The objective is to gauge consensus of
    	 the WG on the selection of the PAA2EP protocol as proposed in this I-D.
    	 Furthermore, solution-oriented discussions will take place based on this
    	 proposal (I-D: TBD).
    PANA Terminology. EP is in charge to do the access control and enforce packet filters.
    	 DI and optionally cryptographic keys may be provided by the PAA to the EP.
    Discussion objective. Objective today: gauge consensus of the WG on the selection of
    	 the PAA_2-EP protocol as proposed in draft-yacine...
    PAA-2-EP protocol requirements. Secure communication. One-to-many paa-ep relation.
    	 Access control information. PAA initiated communication. New pac notification
    	 to the paa.
    PAA-2-EP protocol evaluation summary. The requirements are soft enough. SNMP. COPS-PR.
    	 NetConf. Other immature solutions (Diameter, Radius, ForCES).
    SNMP applicability against the PAA-2-EP Reqs.
    SNMP applicability re-usable existing MIB objects.
    SNMP applicability additional PANA-specific MIP specs.
    Next steps. Selection of the PAA-2-EP protocol. SNMP? Either annex to the PANA protocol
    	 draft or into a new wg document.
    Alper: proposal is to use SNMP. Any feedback?
    Mohan: we need new MIB variables to the existing? How do we do this?
    Yacine: some additional objects can be seen as an extension.
    Yoshi: using snmp is coming from MIDCOM. I'm not sure if this is applicable to PANA.
    	 Relates also to accounting. If accouting period is shorter, it is difficult to
    	 support this scenario.
    Yacine: snmp doesn't provide accounting stuff. These mentioned issues are not in the
    	 requirements draft.
    Greg Daley: there's no problem using SNMP for config and something else for accounting.
    Yoshi: it is ok to mandante snmp, but we should allow other too.
    Yacine: the wg should just mandate one.
    Raj: is there any reason to rule out diameter, radius? Provides more functionality and
    Yacine: may provide much more functionality in some cases, but my understanding for pana
    	 needs are that req are soft enough to allow any protocol. My understanding is
    	 that pana needs right now a working solution.
    Raj: I accept that an AP may not have diameter or cops.
    Raj: you should also look the work in the nsis wg. We should ask consensus and maybe
    	 take to the mailing list.
    Raj: PAA-2-EP protocol. is snmp sufficient for EP-2-PAA protocol?
    Alper: how many have read the draft? Around 7. We need more than this for voting.
    Raj: back to the mailing list. 
    Alper: Yes.
    4. PANA-IPsec I-D update: 10 min, Mohan Parthasarathy
       draft-ietf-pana-ipsec-00.txt. Objective is to discuss the latest changes (see
    	 Revision Log) and confirm consensus.
    Mohan: this was presented in the last ietf.
    Open issues. Use of Ipsec tunnel mode instead of transport mode. Pre-shared key
    	 derivation for ike.
    Hannes: the draft is very generic. So this is just fine.
    Open issues contd. What to do if msk is updated because of re-authentication. 
    Raj: you get the msk of the resulf ot eap. How does the ike take the key?
    Mohan: pre-shared key into the file. Discussed already on the mailing list.
    Hannes: several issues. API issue. Key naming, which is confusing. It says that which
    	 SA you select. Another is the lifetime. Not only the MSK, but  also authorization
    	 parameters. You have to make that these are in sync. If new msk is generated some
    	 authorizations may have been changed and the ep should know about these. 
    Thomas: some people familiar with ike have raised issues. Security properties. We need
    	 to think more about this. Careful analysis required. Talk to Bernard Aboba.
    Mohan: ike is exactly the same as in 802.11. 
    Thomas: same concerns. Be careful.
    Alper: we should check keying framework draft. Key naming issue is important for this
    	 point. With new msks we get new key names. With option2 we need to differentiate
    	 the previous and the new key. We might end up with a key number. Keys are changed
    	 inside the one session. Maybe we need an additional attribute to identify the key.
    5. PANA state machine considerations: 20 min, Dan Forsberg
       The discussions will be based on the state machine diagrams provided at
    Thomas: How many people read the state machine? (7 or so hands). Not many
    Raj : Has been around for sometime. There has not been feedback on the state machine
    	 draft itself. Need feedback. Should it be part of the protocol solution or a
    	 separate document ?
    Not very many folks have read the state machine draft.
    6. Unspecified source address discussion: 10min, Chairs
    Charter change was requested for the ADs. ADs came back with some concerns about this
    	 issue. Some discussions on the mailing list. Current state is to allow the use
    	 of unspecified IP address. 
    Thomas: This chart is a bit misleading. Today the clients try the dhcp first. If no dhcp
    	 response, allows link-local addresses.
    Alper: We are not changing that. If deployment wants to do PANA, then the network will
    	 not respond to DHCP and start PANA.
    Thomas: you make an assumption that all clients are updated to use pana.
    Alper: Obviously.
    Raj: We didn't change the client behaviour. We are thinking about using link local
    Steve Bellovin: my concern is the concern on the ip stack. This dhcp behaviour is
    	 embedded in a lot of code. There are lot of stacks. This is an attempt to
    	 reverse the decision that was made before. 
    Thomas: brings to my mind. The existing specs may suggest that the unspecified address
    	 is meant to be used only as a source address.
    Steve: also the case that there are a lot of filters. This behaviour is blocked. I'm
    	 concerned about host stacks.
    Vijay: There is another place where unspecified source address is used. IPv6 duplicate
    	 address detection. If this is restricted on link, we should be able to use.
    Ralph: what will this first bullet mean?
    Alper: default host behaviour is that the client will use dhcp address configuration.
    	 If it fails, host uses link local.
    Why allow unspecified PaC address. Address depletion attack. Dad attack.
    James Kempf: Don't use unspecified address. Use the proposed CGA address. You are
    	 shifting the dos attack from dhcp to the pac. One can blast the network with
    Alper: that would be a different type of dos attack.
    Kempf: I meant paa, I'm sorry. You're sifting the problem around, but not solving it.
    	 The fact is that you can't secure the link configuration.
    Alper: its hard to prevent all dos attacks.
    Raj: the thread analysis document talks about this. 
    Kempf: if you have address you can more easily do the dos.
    Alper: no, then the client is already authenticated at that point.
    How does authentication first giving ip address later help? Attacker identification.
    	 Ipsec based access control. Still need secure dad. PANA SA might help SEND. No
    	 straight forward benefit of configuring IP after PANA if IPsec-based access
    	 control is used.
    Utility of handling this threat. Does handling this dos threat improve the overall
    	 security (how about other dos attacks)?
    Deployment considerations. In some scenarios, final address assignment depend on the
    	 client id. Pre-pana address, post-pana address. Address management with ipsec.
    Drawbacks. Sending to unspecified ip address. Receiving from unspecified ip address.
    Mark Stapp: my question is about existing stacks. Somehow the pana client has to have
    	 a configuration in relation to the ipsec. If it is needed or not. If dhcp is
    	 in progress. This sounds very complicated (entangled).
    Pete McCann: in existing deployments today we have good cryptography on existing l2.
    	 this is why we need pana. Hardware hackers. There are fixes to fix ip layer to
    	 the mac layer. Its always good to check the mac address. This doesn't fix the
    	 problem. I still want to see the mac address.
    Thomas: 2 points. 1. I disagree with your summary. It is biased. Couple of examples.
    	 Fragmentation is not that black and white. Yes, you can disable the IP level
    	 fragmentation. Eap methods doing the fragmentation has a cost. This leads to
    	 a lot of round trips and delays. The performance is not acceptable. go back to
    	 the send slide. I think this is an open question if this can be solved by SEND
    	 in pana context. Whether send can deal with this or not is an open issue. 2nd
    	 point. If there is a need for pana to be able to do some exchanges prior to
    	 address assignment. You need to select the isp and then this isp gives the
    	 address. I understand this but this is really different than the dos attack
    Alper: there are two issues. Security and deployment and they are orthogonal to each
    Thomas: you need to be careful with the requirements.
    Alper: yes, there are two different issues here.
    Kempf: send may be able to solve DAD issue. But not with unspecified address. Using
    	 pana for enabling send is speculative at this point. Don't base your design
    	 on that. What is the problem with configuring link-local always and disabling
    Thomas: you are changing the default host behaviour. Does not work if there is no PANA.
    Alper: we can do that only when we have a full control of the network, then we can make
    	 such asumptions. Preconfiguration: do pana first.
    Kempf: What is the problem with link-locals?
    Alper: security is the issue.
    Pete: I still have to check the mac address in the receiver and while sending. This
    	 doesn't really seem to solve the problem. 
    Alper: you can send to link-layer destination or use the broadcast.
    Alper: if the client is using unspecified address, whether the packet is sent to
    	 link-layer destination or broadcast is implementation specific.
    Thomas: client needs to choose an id.
    Alper: session id chosen by the paa and it's unique.
    Thomas: We have a bootstrapping problem. 
    Alper: we may need to send another id from client to the paa. So that the paa can
    	 differentiate the address.
    Thomas: this is solvable, but do we want to go into this direction at all?
    Mark Stapp: We can't trust dad, dhcp, we still need to have this mac checking.
    Ralph: we can't solve the problem with pana. For example: The use of unspec address
    	 with dhcp. You mentioned that authenticated dhcp would solve the dos. 
    Alper: the dad must be secured even when dhcp is used, otherwise we are not solving the
    Ralph: we have technology available today that some platforms combine dhcp with arp
    	 processing for arp security.
    Alper: not familiar, can you send the info please.
    Ralph: I'm wondering about the deployment scenario for post-pana address case. We do
    	 that today. Post-address authentication. How is this mechanism improving this?
    Alper. Referring to? Allocation of pre-pana and post-pana addresses is doable today.
    	 It's the question about the additional cost.
    Ralph: if 802.1x is the scenario. Can we require this to avoid these problems?
    Alper: you can do that.
    Mohan: what is the cost of using link-local ipv4 address? 
    Alper: without this we could just say that use pana. But if we assume that the client
    	 has an ip address first, we have to say that you are using link-locals on the
    	 client or you have to have a dhcp server on the access network.
    Thomas: I have problems of understanding this argument. Its too expensive of having dhcp
    Alper: It is an additional, non-zero, cost. Normally a NAP hosts a dhcp relay. Dhcp
    	 servers are at the ISP sites. Now the NAP will need to have a dhcp server and
    	 an address pool of its own.
    Raj: If you want to run pana you would need dhcp on the access link.
    Ralph: an additional dhcp server on the access link. Each of the backend providers are
    	 running separate dhcp server.
    Thomas: we can migrate pools of addresses to the access link. The problem is which
    	 addresses belong to which isp.
    Question to the WG: do we want to keep allowing use of unspecified ip address by pacs?
    	 Do we want to assume pac always has an ip address?
    Mohan: isn't using link-local addresses just fine?
    Alper: This could be the case.
    Thomas: the problem is that if the spec allows unspecified addresses, we have to work
    	 all the details and put that on the spec.
    Raj: It implies that the client has to support both.
    Alper: we can follow what dhcp did. We have session-id to support this. I don't see any
    	 difficulties in the protocol design.
    Steve: Secure link local address. This is previously unresolved problem. Basically the
    	 client stack vendors would go all the pain of implementing this. Or the clients
    	 do not support it, which in case the operators can't use this. Making this
    	 optional is not a choice. How long does it take to have this deployed into the
    	 hundred of thousands of machines. This is not possible. Maybe 8 years.
    Alper: We will talk about implementations.
    Raj: I agree with you steve. 
    Alper: The question is if we want to have this optional.
    Steve: I don't know what benefits there are in this unspec address option.
    Raj: How many think that unspecified address support is useful? Vote. 
    (alper has results). 7 yes, 13 no.
    Ralph: Are these questions "either-or"?
    Alper: Exclusive. Whether we support this or not.
    Alper: Not clear consensus.
    Thomas: there are real issues here, but we have to figure them out.
    Raj: If there is a consensus that we don't use this option, maybe in the future we may
    	 extend pana.
    Thomas: You seem to be concerned that giving the address first has issues. But there are
    	 many other dos attacks too.
    Mark: Just moving the dos attack somewhere else.
    Greg: we can solve this on pana discovery phase. Don't wait pana to do this. Make sure
    	 you have the base draft out. 
    Thomas: Isp selection issue. Can pana along solve this? We have to see if this solution
    	 is usable in the context. Service selection, traffic identification need to be
    Thomas: I suggest we go with the current charter. We need to tease out the issue. We
    	 might find a middle ground.
    Raj: Rough consensus. Go forward with assuming that pac has an ip address.
    7. Implementation report: 10 min, Victor Fajardo; 10 min, Hannes Tschofenig
       Reports from people who have been implementing the PANA specification. The former
    	 implementation was recently published at http://www.opendiameter.org/
    Victor fajardo. C++, lgpl, os: linux, windows xp. Diameter and eap implementations are
    	 also awailable.
    Functional architecture. Defines pana api. Independent of eap implementation. Abstracted
    	 transport model. Dictionary-based message processing.
    API. Core object instances. Session based pac and paa objects. 
    Victor: PANA state machine is helpful, but additional documentation is needed.
    Transport model. Ip stack bypass. 
    PAA architecture.
    Future plans.
    Hannes: I will post my slides to the mailing list.
    8. Next steps: 5 min, Chairs/Ads
    pana state machine discussions will take place.
    We'll have a security review.
    Paa-to-ep provisioning protocol details will be worked out.
    Alper. Thanks, see you in korea.


    PANA Update and Open Issues
    PAA-2-EP protocol
    PANA enabling IPsec based Access control
    PaC State Machine States
    PaC with unspecified IP address
    PANA Implementation in Open Diameter
    Next Steps