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 <firstname.lastname@example.org>
Alper Yegin <email@example.com>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Margaret Wasserman <email@example.com>
Internet Area Advisor:
Thomas Narten <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: https://www1.ietf.org/mailman/listinfo/pana
In Body: (un)subscribe
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
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
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 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
the PAA and the EPs.
Goals and Milestones:
|Done|| ||Submit usage scenarios and applicability statement to the
|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 |
No Request For Comments
Current Meeting Report
Protocol for Carrying Authentication for Network Access WG (pana)
Tuesday, November 11 at 0900-1130
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:
WG last call completed on 3/11/03. Draft is sent to ADs for IESG consideration.
WG last call completed on 6/12/03. Draft is sent to ADs for IESG consideration.
WG last call completed on 5/1/03. Draft is sent to ADs for IESG consideration.
Work in progress. I-D will be discussed at IETF 58.
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").
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.
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).
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
Yoshi: EAP state machine doesn't allow this. My opinion is that this complicates the
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
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
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
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.
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.
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
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
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.
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
PANA enabling IPsec based Access control
PaC State Machine States
PaC with unspecified IP address
PANA Implementation in Open Diameter