PANA Working Group Meeting Minutes IETF53 (Monday, March 18 at 1300-1500) 1a. WG Scope and Charter Clarification, (By Basavaraj Patil) ------------------------------------------------------------ Alper Yegin is now new co-chair of PANA WG. Two WG docs are identified so far a. Requirements and terminology draft. The design team is working on this draft from the beginning of January. The current timeline for this draft is - Version 0 by the end of January - Version 1 will be out based on the mailing list discussion - Working group last call will be after IETF-53 meeting b. Usage scenario draft - Revision 1 is under discussion - Need couple of issues to be resolved before working group last call 1b. General Charter Clarification Discussion It seems like there may be some misunderstanding regarding the current goal of PANA WG. As per charter, this WG focuses on the layer2 agnostic mechanism for interacting end host with the authentication and authorization infrastructure. This is essential because a single mechanism is required that performs the authentication and authorization functions. This makes hosts simple to implement, deploy and inter-work. As per this charter PANA will define a network access protocol, which is independent of layer-2 and IP versions (IPv4 or IPv6) and support multiple authentication schemes. Current mechanisms exist today are - Use of PPP to carry authentication information - PPPoE for authentication (note that PPPoE may not be just for authentication). - Network specific network authentication mechanism (like GSM, CDMA, 802.1x etc.) - Web/HTTP based mechanism (direct to web site) Why PANA: Single mechanism for a host to do authorization and authentication over different access network technologies. PANA will define (select) existing protocols for network access that will have the following characteristics: - L2 agnostic - Identifying authentication/authorization using existing security mechanism Moving forward - Agreement on requirements - Develop a framework (this should be small effort) - Propose a protocol as a solution - Implementations !!! Comments: - There was some confusion among some members in this group regarding what sort of IP address may be used. - IP connectivity and authentication may be viewed as chicken and egg issue (having authentication before obtaining IP address and getting IP address to perform authentication). If PANA is used, one might not need access layer specific authentication. Single mechanism may be used for any access network regardless it is 802.11, GSM or any other access network. - Co-chair explained the goal of the charter saying that currently different access networks have different mechanism for authentication. This WG is trying to come up with the generic mechanism, which can be used by all these access networks. - WG is assuming that this is layer3 mechanism, which is problematic since it will have all types of security attack problems at link layer. - Further discussion was to have separation of layers functionalities. The group argued that current mechanisms are relying on link layer authentication. For example PPP performs authentication and IPCP rely on that. This brings up the issue of getting PANA adopted by existing access networks - Pat C. : GSM, CDMA, WLAN are not going to change their authentication mechanism because of a new protocol that PANA will specify. We need authorization at L2. Alper : Only network authentication at L3 Pat C. : Why separate them ? George T: L2 authentication happens at access pt, not at the access router, PANA tries to solve this issue. - Who wants this today ? What are the target environments? - We don't do business case at IETF. It'll be needed when nodes are in GSM or WLAN. - IEEE already exists, what is PANA buying here? - Glen Z (Cisco): Authorize L2 with L3 ? May work for a few protocols, but not for all. Dynamic filtering ? 2. PANA Requirements (By Alper Yegin) ------------------------------------- draft-ietf-pana-requirements-01.txt Goal: The current goal is set to define a carrier and at least one payload (in terms of authentication protocol) to meet the requirements of network access authentication. 2a). Authentication The difference between the carrier and payload were clarified. It was mentioned that PANA must not define new security protocols or mechanisms. Instead PANA must be defined as a "carrier" for such protocols. PANA must identify which specific security protocol or mechanism it can carry in terms of payload. More than one DI (Device Identifier) can be used by PaC and that may be associated with multiple IP addresses. Comments: - This is not agnostic to layer-2. Here link type does matter. It was clarified that layer-2 information is used in the PANA protocol for authentication purpose. It could either be MAC address, IMSI or anything else. Getting IP address can be done by any means and may not rely on which layer link may be used. - One DI for more than one IP address may be a kluge. - DI can be exchanged through some secure way instead of exchanging in the clear-text. - DI is part of protocol specification and may not be discussed as a part of requirements. Co-chair clarified that it should be part of the requirement to identify type if DI used. - EAP in the requirements draft seems like the good idea. Mutual authentication, re-authentication, integrity protection are essential requirements. The draft should also assume protection against eavesdropping, spoofing and replay attacks. - Information like what kind of DOS attack may be occurring etc. should be covered in this draft. - It is also possible that if EAP is not available, then having secure channel is not guaranteed. 2b). Authorization: In addition to carrying authentication information, PANA also carries a binary result (i.e., success or failure) of authorization for network access to the PaC. - Should PANA be designed extensible for finer granularity authorization (ability to carry a chain of extensions) => like qos parameter exchanges etc. - Should we have a requirement on extensibility? As far as location of PAA concerns, there should not be any restriction on where the agent should be located. Similarly, this document should not make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC. EAP association may be limited and should be assumed the same through out the Mobile IP application duration. The question brought up was whether PANA works even before IP address configuration. Note that it is working assumption that PANA works after the IP address configuration. This may be a deployment issue but seems like no one in the group had issues against this. Also, it should be clarified in the requirements that User name and password may not be the only way to authorize the user. Other requirements on security and DOS attacks were discussed. PANA must be robust. The line containing "robustness is no worse than TCP syn attack" will be removed from the draft. More comments were taken at this point and commentors expressed concerns on the consistency of the requirement statements and goal of PANA. More threat analysis to be done to define security requirements. If PANA depends on EAP then the requirement draft needs to say that. George T. commented that PANA does not assume EAP on PANA. Then a commentor expressed concern on using L2 over-L3. He was asked to send comments to the mailing list. 3. Usage Scenarios - draft-ietf-pana-usage-scenarios-01.txt (By Hesham Soliman) ----------------------------------------------------------------------- Problem statement included reason of having common authentication technique. The current authentication process and access control mechanisms have dependency upon the type of network that a user is attaching to. As a result a need of having a flexible authentication, which is independent of underlying access technologies and access control mechanisms is identified. Currently some access networks do not have in-built authentication support. PANA helps resolving the following situations: - Local Re-authentication: There is also a need for local re-authentication between client and PAA. This re-authentication may be due to timing or parameter changes or detection of connectivity/reachability etc. - IP address configuration and timing independence - IP version independence (IPv4 and IPv6) since PANA is considered layer-3 protocol. - Support of multiple access routers - Solves NAS issues since the location of NAS determination is essential. A scenario where handoff occurs between different technologies under same administrative domain is discussed. A client is associated with one access type so handoff is a big problem. It was mentioned that context transfer doesn’t help in this case. In the scenario like this, PANA provides single authentication and authorization infrastructure for operators. Comment: - This is a political problem. If both technologies use different authentication scheme, it doesn’t make sense in using PANA in these types of scenarios. - If user is authenticated with one access network then context transfer is done at the time of handoff. It is still essential that a user is authenticated by the new access network (where user is roaming). - For the authentication purpose, it is necessary to have NAI type of link layer identifier. - Details like location of PAA in the network should not be discussed while discussing scenarios in this document. - Scenario discussed to explain multiple AR is useful but PANA’s role in solving the issue is not very clear. - Pat C. asks if PAA could be on the edge. ANswer was it can be on both edge and non-edge. Erik N. points out that this is a valid question in the given scenario. 4. PANA and EAP (George Tsirtsis) --------------------------------- EAP supports most current PANA requirements (directly or indirectly). Checks for each requirements mentioned in the PANA Requirements draft were presented. It was noted that currently Disconnect Indication and PAA discovery are not supported. Reliability and congestion control are also kind of supported. Work to be done: - Define EAP transport at the network layer - Define Explicit DI transport - Disconnect indication - PAA discovery - Local AAA and key distribution: must be coupled - Reliability and congestion control Comment: - SASL or TLS may be better candidates instead of EAP. - L2 transport takes care of all these problems. Using EAP for L3 is almost like EAP over EAP. - EAP BoF will discuss separating key part from the EAP. - EAP assumes that back end is separate from the relay. This may not be the case with SASL. - Whether EAP is the only payload PANA should be working on? It was clarified that EAP is a preferred payload and that is the assumption so far. This point will be further discussed on the mailing list. It seems overall, confusion is why layer-3 authentication is required which again rely on the layer2 information. 5. PANA Framework, (By Yoshihiro Ohba) -------------------------------------- Different scenarios were discussed explaining how PAA interacts with other network entities and the factors involving the location of PAA. It was mentioned that it is possible to have PAA one hope away from the PAC. Also PAA is viewed separate from the access device. The issue again might be relating to the address assignment since the IP address is used for the authentication. The question raised was that what address should device use as global address. Security factors identified so far are: - Requirements for a need of LSA (Local Security Association) between a client and a server - Key derivation - PANA exchanges be integrity protected and encrypted - EAP is one of the candidates based on the current security requirements. The following are current assumptions on AAA infrastructure: - Secure AAA infrastructure - Information carried between AAAL-AAAH is viewed same as PAC-PAA - PAA should able to pass info to another PAA if necessary. This will reduce server interactions - AAA authentication information will be pushed down to the access device. This brings one more protocol to the table probably midcom, diameter or something similar. Comments: - These are good requirements but it is essential to have well defined interoperability. There was also a short discussion on PAA Discovery. The possible candidates are ICMP, DHCP or others. The co-chair asked for the volunteers to work on the PANA framework draft. More discussion will take place on the mailing list.