Last Modified: 2004-02-02
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.
|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|
Protocol for Carrying Authentication for Network Access WG (pana) Monday, March 1 at 1530-1730 ================================== CHAIRS: Basavaraj Patil Alper Yegin Note Takers: Hannes Tschofenig, Yacine El Mghazli # = conversations/comments/questions * = slides Slides are available at http://www.toshiba.com/tari/pana/ietf59-pana.html 1. Preliminaries (bluesheets, minute takers, agenda bashing) : 5 min Chairs ---------------------------------------- -------------------------------- 2. PANA framework: 30 min, Alper Yegin draft-ohba-pana-framework-00.txt. This is a new I-D. The WG's opinion will be solicited for accepting this I-D as an official working group item. * functional model * signaling flow * deployment env. a) secured phys netwk a1) crypto sec (cdma2000) a2) phys sec (dsl) ... * IP address conf pre-PANA address: PRPA post-PANA address: POPA * PRPA conf possible ways static dhcpv4 v4 link-local dhcpv6 ipv6 address autoconf (global or link-local) * POPA conf (no IPSec) dhcpv4/6 ipv4: - POPA replaces PRPA (prevent address selection problem) - host route between PaC and PAA (preserve on-link communication) ipv6: - use both PRPA and POPA at the same time # subir: once auth done with PRPA, when there is an EP. Which address the PAA sends to the EP ? POPA or PRPA ? # alper: after binding (here is my new IP address POPA) POPA is sent to EP to update the filter. # lionel: if L2 protection is used, do we rely on mac address ? # alper: yes. * POPA conf (IPsec) possible ways IKE DHCP ... * Combinations table for recap # alper: the mac address is used when IPSec-based access control is not used. no device id update is necessary in this case. # subir: treatment between IPSec and non-IPSec case is different. IPsec case: what PAA sends to EP ? PRPA ? # alper: yes. ipsec case: PRPA is configured and used during PANA. # subir: what will the PaC send to the PAA ? # alper: PRPA. alper: PRPA is used for outer header, POPA is used for inner header. IPsec SA used to accept/drop packets. * additional approches (1) using PRPA as TIA IPv6 requires SPD selection based on the name (session_ID) not the IP address explicit support in RFC2401bis RFC2401? not clear should we include this ? # alper: do we include this case into the framework ?... maybe in the appendix. * approach (2) using PRPA as TIA IPv4 RFC2401: same considerations forwarding considerations # alper: should we include this ? any feedback regarding implementations? * Data Traffic protection already available in type (a) environments enabled by PANA in type (b) environments EAP generated keys SA prototocol draft-ipsec * PAA-2-EP EP closest IP capable acccess device to PaCs co-located with PAA or separate one or more EPs per PAA EP may detect presence of PaC and trigger PANA by notifying PAA * Net (ISP) discovery and select traditional select NAI-based Port-number or L2 address based PANA-based discovery and select PAA advertises ISPs PaC explicitly picks one # jari: in pana you can also do nai based selection? # alper: yes. # alper: there are two service providers here: access and isp # jari: how is this isp selected? # jari: [question regarding his draft and network selection...] # hannes: known as EAP sequencing # alper: this is not related to EAP sequencing. the client says only which ISP he wants to be authenticated to. # hannes: can a client have separate NAIs ? # alper: yes # subir: the PAA receives the NAI. who does the mapping ? # alper: NAS does. PAA is on the NAS. # dan: how would exactly the routing work? # alper: it heavily depends on the scenario. alper lists a few scenarios. there may be roaming agreement. # dan: if NAS cannot map, we must specify what happens then # alper: this is like "unrecognized user" case. # dan: it's 2 different issues. # subir: do you consider scenarios where there is an access net using several ISPs? # alper: AAA packets goes to the AAA backend. the home AAA server athenticates and authz you. simple roaming. # farid: seems like there is both home-ISP and mediate-ISPs. why not using NAI for both ? why don't you need jari's new nai scheme? # alper: I look into details later. for me it looks like NAI overloading. # yoshi: this ISP selection is independant of any intermediate ISPs. similar to SSIDs. * Authentication method choice depends on the env. DSL deployment PANA needed when static IP or DHCP-based configuration is used (instead of PPP) bridging mode address translation (NAPT) mode router mode # subir: how does the ppp & pana scenario looks like? # alper: you don't need PANA if there is PPP in the stack. * dynamic ISP selection as part of the DHCP protocol or an attribute of DSL access line DHCP cient ID run DHCP, and PANA PRPA is the ultimate IP¨address as part of PANA auth temporary PRPA via zeroconf or DHCP with NAP run PANA for AAA POPA via DHCP, replace PRPA # subir: who runs the DHCP server ? managed by NAP or ISP ? # alper: it really depends. the NAP can run a DHCP relay for instance. * WLAN net-layer per-packer sec (ipsec) link-layer per-packer sec (WPA-SK) * IPsec, IKEv2 IPv4: ipsec TOA= PRPA (dhcp) ipsecd TIA= POPA alternative RFC 3456 IPv6 ipsec-toa= prpa ipsec-toa=popa * bootstraping WPA/IEEE 802.11i PSK mode enabled MAC address used ... * Flow # subir: if the PaC gets an IP address, which address will the dhcp server provide to the pac when the same mac address is provided ? # alper: dhcp always maintains a list of mac address # yoshi: the requests appear on 2 different sub-nets. the server can give different IP address. the interfaces are different. # raj: let's get this discussion offline. * co-located PAA and AP(EP) * capability discovery types of network IEEE 802.1X-secured PANA-secured data driven PANA discovery client initiated discovery unauthenticated * The end. # lionel: about WLAN: in that case, we use the MAC address as DI. ip address could also be used. could we mandate the case when we use different auth ? this could be included in the draft. # alper: changing the IP address wont affect the whole framework # lionel: can this be clarified in the text ? # alper: should this become PANA wg item? # raj: how many read the draft?  # raj: among them, who says yes?  # raj: let's take this to the list. 3. PANA protocol update and open issues: 30 min; Yoshihiro Ohba, Basavaraj Patil draft-ietf-pana-pana-03.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. * issue 52: details of double auth # jari: [concerns about how you avoid the MITM attack]. you need keys from both eap methods. how it works ? # yoshi: combine keys. # jari: combine keys is fine. # lionel: I don't understand the need. I don't see the usefulness. # jari: I guess you don't have to have a combined key. you have to prove possesion of the keys. it's a real issue. * issue 53: additional discovery information * issue 54: mandatory cookie # alper: I don't fully understand: if you want to make the discovery stateless why cannot we mandate the cookie and allow the eap method payload as a response? # yoshi: EAP creates state for the retransmission. # jari: something else: for a real auth to start, you have to have identity request at the first message. do you? i am not sure that you need state in all cases # yoshi: it seems to be according to the EAP draft. # jari: to be exact: the EAP requires to have a state on this transmission thing. from a technical view, maybe we dont need it...but maybe we shouldn't go that far. * issue 55: is client cookie useful? # jari: yes, a host can be a malicious node claiming to be a PAA. it would be good to provide this protection # hannes: initially, we proposed also to use another solution. # alper: if we use that cookie, everyone on the same subnet will hear it, and everyone can respond with the same cookie. this threa cannot be prevented, since the discovery is broadcasted and hence also seen by the adversary. a malicious can always act as if it were an authenticator. for off-path adversaries we can simple do filtering. * issue 56: AAA routing based on NAI vs. ISP choice clarification # yoshi: clarifications added in the next version of the draft. * issue 57: PSR retransmission strategy # yoshi: does it make sense ? # lionel: stateless or stateful discovery ? who creates the cookie, PaC or PAA ? # yoshi: generated by PAA. # lionel: the PAA is not able to know if it's stateless or not. # yoshi: I don't understand # lionel: the PAA has to keep records # yoshi: no. the PAA does not have to keep record. let's discuss on the list... * issue 58: fast-reauth and authz. CTP has some problems as described in the eap-keying draft. # kempf: what's the CTP issue ? # jari: [refers the eap-keying draft in detail] # hannes: deployment issue. nothing surprisly new. [issue in detail]. # jari: [discussion whether a CT has to carry all authorization parameters]. some authorization parameters are implicit and not communicated to the nas such as the session limit they are only enforced at the visited network. # alper: move this to the ML please * issue 62: PAA discovery triggered by data traffic * issue 63: MAV AVP a SHOULD or a MUST now it is a should, it would be better to meke it MUST * issue 64: 2 separate codes for session id * issue 65: clarification on simultaneous per-packet protection [raj for the closed issues:] * issue 28: PaC/PAA state machine # raj: should be included in the next version of the protocol draft. * issue 35: EP information * issue 36: reauth race condition * minor issues # raj: questions to the ML. 4. SNMP usage for PAA-2-EP interface: 20 min, Yacine El Mghazli draft-yacine-pana-snmp-01.txt. This is a new I-D. The WG's opinion will be solicited for accepting this I-D as an official working group item. # alper: how many people have read the draft  # alper: how many thinks it should be a WG doc  # alper: not enough people. see on the ML. # raj: I think it's ok, it's a long time now that this is discussed. # alper: yes. 5. PANA-IPsec I-D update and open issues: 15 min; Hannes Tschofenig, Mohan Parthasarathy www.yegin.org/IETF/draft-ietf-pana-ipsec-02.txt. Objective is to discuss the latest changes (see Revision Log) and confirm consensus. # yacine: the PSK is derived from the AAA-key, what if it changes? must we re-provision the EP with the new one ? # hannes: it's close to the session_id problem. # alper: it is an issue. 6. Next steps: 5 min, Chairs/Ads # alper: goal is to update the drafts as soon as possible and send them to wg last call before the next ietf. for all drafts: - pana-pana - pana-ipsec - pana-fwk - pana-paa2ep END.