Subject: PANA meeting minutes (IETF 53)

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 28 Mar 2002 16:23:34 -0800

Folks,

See the IETF 53 PANA WG meeting minutes below.
Many thanks to Jayshree Bharatia and Samita Chakrabarti
for taking notes during the meeting!

---------------------------------8<------------------------

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.

------------------------------->8--------------------------