Last Modified: 2003-01-22
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.
| 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 |
Protocol for carrying Authentication for Network Access WG (pana) WEDNESDAY, March 19th, 1530-1730 ================================= CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com> Alper Yegin <alper@docomolabs-usa.com> Thanks to Pekka Nikander and Spencer Dawkins for capturing the minutes of the WG meeting, AGENDA: 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 Parthasarathy ====================================================== - 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 ================================================== http://www.toshiba.com/tari/pana/draft-i etf-pana-requirements-05.txt 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 trade-off. 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 address. 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 used. 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 allocated. 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 differences. 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 ====================================================== http://www.toshiba.com/tari/pana/draft-i etf-pana-pana-00.txt Presented by Hannes T. Described the difference between the PANA framework and the PANA protocol. 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 cookie. 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 important. 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 messages. 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 issue. Shivar Ranamana?: Is AAA going to be used mainly for session key distribution? 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 protocol. 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. Trade-offs. 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 environment. 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 anyways. 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 IKE? 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. |