Subject: Minutes from SLC, IETF-52

From: subir Das <[email-masked]>
Date: Wed, 26 Dec 2001 09:31:07 -0500

PANA WG Meeting Minutes, SLC, Thursday, Dec 13th at 1530-1730
=============================================================

Thanks to Jarno Rajahalme, Eva Gustafsson and  Gopal Dommety for taking
the notes.

AGENDA:

1. Agenda bashing & WG Milestones Discussion    20  Mins
   B. Patil/S. Das

The chairs presented a short history of this working group: BURP BoF,
URP BoF, PANA WG( (BURP->URP->PANA, Internet Area) and then charter
Highlights:

To define a protocol between a user's device and a node in the network
that allows:
 -- the device to authenticate to an agent in the local network (PANA
authentication agent, PAA)
 - the device to discover the IP address of the PAA
 - the PAA to use either local mechanisms or the AAA infrastructure to
    authenticate the device.
- PAA provides hook to access control protocol but does not specify
 any access control mechanisms (this is  out of scope for PANA)

Issues: requirements on the protocol, approach for handling security
 issues, relation to AAA infrastructure.

- WG will produce
 - Usage Scenarios (Info)
 - Requirements and Terminology (Info)
 - Framework (PS)
  - Chosen approach for handling the security issues with existing
security
    protocols
  - Assumptions the protocol is making on AAA infrastructure
  - Relative locations of the PAA and any access control functions
 - Interactions (Info)
  - relationship to PPP, 802.1x
 - Protocol Spec. (PS)
- MIB Definition (PS)

The chairs also presented milestones.

 - challenging schedule, but strive for high quality documents
   must not miss the window of opportunity

Question: Relation to address assignment

Answer: Will be addressed later on

Question: What exactly is the problem we are trying to solve here? Why
not
Use IPSec instead.

Answer: Parameters/credentials needs to be sent from the user
device to the network, then we can utilize the AAA infrastructure in the

 backend to authenticate for access.

AAA is not running to the laptop, need to carry the credentials from the

device to the AAA client. Extending AAA mechanisms to the user's device.

Today we have PPPOE, 802.1x is doing similar, but 802 specific, don't
apply
to e.g. CDMA-2000.

Question: EAP is already supported by Diameter. Are we looking for EAP
or something else? Do we really need something else?

Answer: We are looking for a generic solution; we don't want
a mechanism that is specific for each link layer. But of EAP works
everywhere...
The intent of PANA is Transport and not to re-invent EAP.

Question: 802.1x is an EAP wrapper. If everyone is else is using EAP why

we need something else? All link layers already have it?

Answer: Is this a BOF or the WG? Anyway, here we are using multi-access
links
 although it can be used also on point-to-point links.

Comment: These questions and answers need to be made clear and go into
the framework introduction, or people will ask the same questions over
and over again.

2. Usage Scenario Draft                         30 Mins
http://people.nokia.net/~patil/Internet_Drafts/draft-ohba-pana-usage-scenari

os-00.txt
http://www.ietf.org/internet-drafts/draft-ohba-pana-usage-scenarios-00.txt

   Yoshihiro Ohba

Changes:
- removed key distr. to other apps
- mobility auth token removed
- added terminology
- added "LSA Details" section
- Terminology

Scenarios:
- limited charge-free network access
- Multi-ARs in a single subnet
- 3 possible locations for the PAA
- access router, other (core) router, independent PAA
- Device with multiple interfaces
- Interface switching/multi-homing/interface sharing
- IPsec tunnel to protect ND if an Ethernet switch is between a GD and
AR
- A GPRS scenario
- Intra-domain, inter-technology handoff

Question: There are two parts of authentication; initial (full)
authentication that goes back to AAA, and local exchange. Does
re-authentication mean doing the same thing as initial authentication?

Answer: Re-authentication is performed when lifetime expires...
Comment: There are two reasons for authentication; for the AAA to say
that you are still there, and for the local access to say that you are
still there.

Answer: This will be defined in the terminology. Chairs also agreed that

we need terminology clarifications..

Note: There was a discussion on charge-free local network access, on
authorization and policies; if there is a charge PANA is
used, if there is no charge there is no PANA...

Question: Local vs. Global re-auth. Do we need terminology to make the
distinction?

Question: (ref. limited charge-free) Walled-Garden? Authorization over
PANA?

Answer: PANA not used to pass any policies for access, policies at the
access
network.

Comments: No need to go through the solutions at this point, just
present
the scenarios
        : PANA should not be concerned about neighbor caches or address
resolution
        : Now we should discuss only about what the WG should be doing

Question: Do you assume IPv6?

Answer: The slide is for IPv4.

Comment: It would be useful to get your view on why usage scenarios are
useful in the first place. Usage scenarios should explain: this is
something people want to do with our network that they cannot do today
that would be enabled with PANA. (That type of scenarios would be better
that the level we are working on.)

Question: Why it is that the scenarios are useful in first place? Going
through
interactions with routing etc. is not addressing that fundamental
question

Question: Do you differentiate between user and device
 authentication in these scenarios?

Answer: Basically, the user is authenticated.

Comments: One way to see it is to do like PPP does; you authenticate a
identifier.
       : We cannot mix the identifiers; it is crucial to understand what

is user and what is device.
       : PANA SHOULD use AAA (not MAY).

Comments: Large rat hole on identification: Identify the device with
what ever
identifier PPP uses.
      : PANA should be mandated to use IETF AAA Standard
      : backend can be anything
      : Using something else than Diameter should be out of scope.
Legacy
reasons to use something else.
       : Diameter/Radius/LDAP/Whatever
       : It  leaves scope  for various  protocols, but  not IETF
protocols are
outside the acope.

Comment: What PAA uses in the backend does not matter; we define the
protocol between the device and the PAA. This will come up in the
requirements; what PAA uses in the backend could be anything
(Diameter, RADIUS, local configuration...)
nswer: It is not irrelevant what protocol is used by the PAA in the
backend, since the user needs to provide credentials.

Question: Difference between GPRS case and the multi-access case?

There was a comment about using Kerberos in the PAA backend,
and a short discussion about its vulnerability to attacks.

 Answer: Kerberos for wireless access? We should not go to the
Kerberos.. as it is proved that Kerberos is vulnerable to Dictinoary
attack. Thomas Wo's paper on how to crack Kerberos, very effective
crack.

Comment: All these scnearios are being deployed today and work.
so what are we  doing with this new protocol?

3. A Smart-Card based scenario for PANA Framework 10 Mins
   Jari Malinen

http://www.ietf.org/internet-drafts/draft-kniveton-sim6-00.txt

- Experimental, mobility friendly scenario
- Simple carrier of an authentication method (ICMP)
- Requirements
 - Domain model flexibility (2 or 3 domains involved)
 - Modularity and extensibility
 - No assumptions on where the authorizer or KDC resides
  - Smart Card generates keys locally
  - Another instance of  then key moved  elsewhere

 Question: IPR issues on your proposal (reduced roundtrips)?

 Comment: This issue was never really clarified...

 Comment: IPR question is a valid question?
 Answer : Specific EAP method IPR is pointless for the WG consideration

 Question: AKA or GSM EAP method. Is the smart card relevant here?

 Comment: Should focus on how to carry EAP over IP

4. Discussion on Requirements and Framework for PANA 30 Mins
   S. Das/B. Patil

The chairs initiated a discussion on requirements and framework for PANA

(to create a requirements and framework I-D)
Objective/Goals

Comment: Should have once sentence "How to use EAP over IP"

Answer: Yes, but that is a solution and we should not go into solution
space yet.

Comments:  PPP not necessarily our solution
       : Keeping EAP in mind will help focus the
       : If EAP fulfills the requirements, then use it

: Done already?

Comments: EAP over IKE may also fit here... EAP is part of the answer.
        : Everyone is using EAP; we cannot ignore it.
        : Done already
        : PIC ? (IPSRA)
        : MIPv4 done, MIPv6 not done, do not want Mobile IPv6 specific
solution.
        : Not doing EAP is not an option anymore.

Comment:EAP over IP may not be the only answer. what abot EAP in IKE?
looks like there is an EAP component

Answer: this seems more of an architectural issue.

- Scenario 1

Issue 1,
Issue 2,
Issue 3: How often to authenticate?
Issue 4:
Issue 5: Location of the PAA?
Issue 6: PAA Discovery?
Issue 7: Implications to access control
Issue 8:
Issue 9: How to carry auth. info?
Issue 10: LSA?
Issue 11: Relationships between PAA & AAA protocols
Issue 12: Assumptions for the AAA infra?
Issue 13: What happens if no AAA infra?
Issue 14: Transport protocol to use for reliability?

More issues?

5. Input for PANA requirements (Alper Yegin)
   <draft-yegin-unap-snard-00.txt>                      10 Mins

- a carrier to AAA
- a front-end to AAA
- Already done for MIPv4
- PANA should be generic
 - can be used to provide some FA-functionality in the visited network
(operator requirement)
- "A" is for authentication
 - implicit Authorization
 - Should be extensible to the latter "AA"'s

- Should be fast!
- Piggybacking on existing signaling
- PAA discovery (simple, fast)
- Intra-domain movement
 - key distribution
 - LSA
 - Context transfer
 - hierarchies
- AAA trust relationships
- Security
 - capability for periodic and on-demand auth. (session lifetime)
 - Replay protection
 - Use NAI
- Not all clients have an IP address at the time of PANA execution

Question: Are you assuming that the PAA always runs on the access
router?

Answer: Not all PAA functionality needs to be in the access
router, but yes, there is a correlation; if the PAA is not in the access

router, you need an IP address to get to it.

Comments: If not in AR, need at least a relay in the first hop router?

Comment: Confused by the statement that this should work without IP
address.

Answer: Best end to anchor is NAI.

Comment: NAI-issue: NAI is used with AAA for message routing. IP address
is
totally useless as an identifier. Compare to the DHCP with relays, i.e.
the
PAA location is irrelevant.

Comment: Try to design for a generic problem (not specific problem).

Comments: PANA is a carrier; nothing more. PANA can be used to
 carry EAP over.
       : The location of PAA is irrelevant.

Question: SAs? Imply IPsec?
Answer: Not necessarily

Question: Let's not just focus on the one specific example scenario
(roaming w/ NAI)

Answer: Do not confuse examples with the protocol architecture. EAP over

PANA will be very flexible.

Comments: There seems to be some confusion that this is targeted
towards mobile or implicit roaming involved.

Commensts: Roaming is implied here.
          : Efficiency in MIPv4 combination of Address config, Access
Auth,
and mobility management. Also has important security properties.

6. Summarize/Next Steps                         20 Mins
   Chairs

Patil: Next Steps
- Terminology / Requirements draft volunteers?

The chairs stated that we need to come up with requirements and
terminology, and asked for volunteers to work on it.