Last Modifield: 05/20/2002
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.
| DEC 01 | First draft of Usage Scenarios I-D (Informational) | |
| FEB 02 | Submit first draft of Requirements and terminology I-D (Informational) | |
| MAR 02 | Usage Scenarios I-D sent to the IESG for consideration as an Informational RFC. | |
| APR 02 | Submit first draft of Framework specification based on scenarios I-D (PS) | |
| MAY 02 | First draft on PANA interactions with PPP and 802.1X (INFO) | |
| JUN 02 | Requirements and terminology I-D sent to the IESG for consideration as an Informational RFC. | |
| JUN 02 | First draft of Protocol specification I-D (PS) | |
| AUG 02 | Framework document sent to the IESG for consideration as Proposed. | |
| OCT 02 | PANA interactions with PPP and 802.1X to IESG | |
| NOV 02 | Protocol specification to IESG | |
| DEC 02 | First draft of MIB definition (PS) | |
| MAR 03 | Submit MIB Definition I-D to IESG for consideration as Proposed. | |
| MAR 03 | Close down or recharter |
Protocol for Carrying Authentication for Network Access (PANA) WG Monday, November 18 at 1300-1500 ================================= Chairs: Basavaraj Patil, Alper Yegin Note Takers: Ernie Tacsik, Subir Das 1. Agenda Bashing, 5 Mins ------------------------- No comments made 2. Charter Update and WG document status, 10 Mins, Chairs --------------------------------------------------------- Report by chair (Basavaraj Patil): Only change to charter after Yokohama - added PAA and enforcement point separation, and updated the milestones. Charter is available at ietf web page. Three WG documents are available at this moment, and they will be informational. Security threat analysis is a new wg document. 3. Requirements draft update, 10 Mins, Reinaldo Penno. ------------------------------------------------------ draft-ietf-pana-requirements-03.txt short presentation covering updates to the requirements draft. PAA-EP protocol requirements - Security - Protocol used between PAA and EP should be able to detect inactive peer within an appropiate time period and delete the related states. - Architecture needs to allow PaC and PAA initiated authentication. - Have a mechanism for a newly introduced EP to learn the policies currently in effect on that access network. - PAA should be able to notify an EP for allowing/disallowing access for a particular client. This should happen without EP sending a request to the PAA. changes in requirements draft - pana models - discovery discussion: Michael Thomas: are we dealing with policy discovery here? Chair (Basavaraj Patil): no - PANA only addresses discovery of PAA. 4. Security issues and Threat analysis, 40 Mins, Mohan Parthasarathy ---------------------------------------- ---------------------------- draft-ietf-pana-threats-eval-00.txt The draft does not talk about solution, specific protocols. List may not be complete. Only general threats are discussed, for example: PAA discovery, authentication, leaving the network, attack the network etc. Discussion on requirement PANA MUST protect the identity of the PaC against eavesdropping Michael Thomas: risk reward benefit expose identity consider that you may NOT want to expose identity of PAA in discovery client may need to know (or guess) the PAA. Hannes Tschofenig: questions requirement of must protect identity - this requirement seems to favour certain solutions. Comment: if you have layer 2 protection then this is not a problem. Michael Thomas: to protect identity you must do something like diffie-hellman. Michael Thomas: identity protection is costly. Hannes Tschofenig: agreed. Chair (Basavaraj Patil): questions if diffie-hellman is appropriate does access network need to know id of client? or only need to authenticate. Michael Thomas: suggested real requirement is to provide ability to protect client privacy, not a "MUST protect" requirement. Jarno Rajahalme: suggested real requirement is to protect user privacy. Unknown1: Whom do you want to protect the identity or what type of threats are analyzed? Unknown2: may be location privacy.. Hesham Soliman: base requirements should be on the general case, we should have one set of requirements, not multiple depending on the various deployment environments. Michael Thomas: DoS is an issue of we want id confidentiality. Discussion on leaving the network Unknown: Is it realistic to think about disconnection.. things may crash.. wire may be disconnected... Chair (Alper Yegin): It is not mandatory but if one sends it should be protected. Attack on normal communication - requirement: PANA in combination with the underlying authentication protocol (e.g. EAP) MUST be able to derive keys in order to enable confidentiality. Michael Thomas: how do you use keys? will it be solved in PANA? Discussion on the extent of protection Unknown: how are packets protected smacks of reinventing ipsec? Answer: No implication that data is secure. Erik Nordmark: PANA protocol must be secure itself, questions if this is just last-hop local protection? Mohan Parthasarathy: yes, for the local protection. Unknown: I think PANA should take care by itself but here we see a different things. Not clear to me whether the last hop protection is necessary. Hannes Tschofenig: I think it is necessary to know whether it is about exchanging EAP messages securely, or something else. Whether the focus of PANA is to put the filters at the first hop router . Chair (Basavaraj Patil): Charter does not talk about securing data at the first hop networks it talks about securing PANA itself. Unknown: We should put a requirement that EP and PAA are secured.. Hesham Soliman: suggested must be able to derive keys in order to enable confidentiality and per-packet authentication." Gopal Dommety: is draft suggesting doing encryption EAP to PaC should this be mandated? other issues with keys. Michael Thomas: is PANA a layer 3 PPP or is it a AAA key distribution system need explicit use sceanarios. Chair (Basavaraj Patil): the intended threat to address is to protect against someone injecting packets into network using a previously authenticated users IP address. Erik Nordmark: confidentiality on the identity is not needed. George Tsirtsis: (on PANA requirement of having an IP address) we can use unspecified IP addresses. Hesham Soliman: is this an issue for IPv6? Erik Nordmark: there is a tradeoff, between having and not having having IP address there already - there are pros and cons. George Tsirtsis: what if one meets all requirements without using an IP address configured on the PaC? Gopal Dommety: a solution that works Without an IP address would be good. 5. Secure Network Access Authentication (SeNAA), 20 Mins, Dan Forsberg ---------------------------------------- ------------------------------ draft-forsberg-pana-secure-network-access-auth-00.txt Discussion on running TLS over UDP: Hannes Tschofenig: How are you deriving the SA for IPsec? If it is authetication only, then why you care about confidentiality. Also if you use only EAP then EAP should provide you the confidentiality. Michael Thomas: running TLS over UDP loses many TCP benefits (such as fragmentation, support for long certificates) Hannes Tschofenig: TLS needs PKI, or else MitM attacks is an issue. Chair (Basavaraj Patil): do we need to protect DI of PAA? 6. PANA over TLS, 20 Mins, Yoshihiro Ohba ----------------------------------------- draft-ohba-pana-potls-00.txt Design policy Start from providing maximum level of security Basic features Authentication parameters including EAP PDUs are carried over TLS TLS runs over reliable transport Discussion: Unknown: You mentioned that you would like to support some EAP methods but if I move and want to support the legacy authentication methods. may be we should consider some other mechanisms to protect those legacy mechanims. What about protecting the other hops. Yoshihiro Ohba: The current draft addresses the EAP protections over TLS but a security discussion is necessary to address these issues. Hannes Tschofenig: on secure channel terminate tunnel in home AAA not at last hop protection mechanism need to be all the way to the end cannot assume the access network is trustworthy. Michael Thomas: huge overlap with IPSRA and IKE per packet integrity on data flows. Why all this effort to use TLS? Chair (Alper Yegin): we are open to discussing other solutions. Erik Nordmark: WG should not consider lot of other proposals. I advocate to discuss the high level methods on the mailing list before producing several drafts... Chair (Basavaraj Patil): Let's explore the other methods and discuss in the mailing list. Derek Atkins: notes there is work in progress on a draft to use Kerberos over EAP. Clarification by chair (Alper Yegin): there are no assumptions in PANA to use TLS. 6. Next steps: chair (Alper Yegin) ---------------------------------- - Wg last call on problem space and usage cenarios after ietf 55 - Complete threat analysis draft and go to wg last call jan03 - Complete requirements draft and go to wg last call end of jan03 - Focus on options for protocol solutions on the mailing list |