Subject: Final WG meeting agenda

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 12 Mar 2002 13:30:41 -0800

Dear PANA WG members,

Here is the final agenda for the PANA WG
meeting at IETF53..

alper

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

Protocol for carrying Authentication for Network Access WG (pana)

Monday, March 18 at 1300-1500 
==============================

CHAIRS:  Basavaraj Patil <[email-masked]> 
                Alper E. YEGIN <[email-masked]> 

AGENDA:

1. WG Scope and Charter Clarification, 15 Minutes, Basavaraj Patil

2. PANA Requirements, 30 Minutes, Alper Yegin
   draft-ietf-pana-requirements-01.txt

3. PANA and EAP, 15 Minutes, George Tsirtsis

4. Usage Scenarios, 25 Minutes, Hesham Soliman
    draft-ietf-pana-usage-scenarios-01.txt

5. PANA Framework, 25 Minutes, Reinaldo Penno

6. LSA from a Framework Perspective, 10 Minutes, Franck Le

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 12 Mar 2002 17:35:12 -0800

Folks,

If you have any comments, questions or outstanding issues
with the following drafts, please send it to the mailing list:

This way maybe we can get few issues out of way (or
on the radar) and make better use of the face-to-face 
meeting at IETF.

Thanks.

alper

---

From: Eva Gustafsson <[email-masked]>
Date: Fri, 15 Mar 2002 14:22:47 -0800

Hi,

I have read the drafts, and I have some comments and questions
on the requirements draft (draft-ietf-pana-requirements-01.txt).
(My apologies if any of these issues has already been discussed
on the list...)

Correct me if I'm wrong, but my understanding of this access network
authentication concept is that it consists of two parts: the carrier and
the
authentication protocol. Currently, it seems to me that the term PANA
is used for both parts, and the requriements draft actually puts
requirements both on the carrier and on the authentication protocol
itself
without clearly defining the difference. I find this a bit confusing,
since
my understanding of PANA is that it is the carrier part only. I would
appreciate if the requirements and terminology draft could clarify these

issues.

This leads into my next question: is PANA intended as a carrier for
any possible authentication protocol (this is the impression I get from
reading the drafts), or is it intended as a carrier for a specific
authentication protocol (this is my current understanding of PANA)?
Either way, it needs to be clarified.

Also, if PANA is intended as a carrier for a specific authentication
protocol, this protocol would put very specific requirements on
PANA, right? Then these requirements should be specified in the
requirements draft.

Section 4.1.3: "PAA MAY use either a AAA backend, some other
mechanism or a local database to authenticate the PaC. PANA protocol
MUST NOT make any assumptions on the backend authentication
protocol or mechanisms."

Why not? In my opinion, a requirement on PANA is that it must
be able to work with Diameter and RADIUS in the backend. Making
PANA work with Diameter and RADIUS would most probably put
a number of specific requirements on the PANA protocol. Is there a
reason for not discussing this in the requirements draft?

Could someone explain to me what "some other mechanism" in the
backend refers to? I don't really see the specific requirements that
"some other mechanism" puts on the PANA protocol.

The draft states: "The protocol design will be limited to defining a
messaging protocol (i.e., a carrier) for providing the clients'
information
to the network for authentication and authorization purposes."
Later on, it states: "PANA MUST authenticate a PaC for network
access."

This is a bit confusing to me; either PANA in itself performs
authentication
or it does not. To my understanding, it does not. Either way, it should
be consistent throughout the draft(s). (This also relates to my first
question
on separation between the carrier and authentication parts.)

Also, there is a continuous emphasis on authentication. Shouldn't the
draft consider both authentication and authorization, and the specific
requirements that authorization in itself may put on the PANA protocol?

Section 4.2.1: could someone explain to me the definition of
"multi-access links"?

Section 4.1.2: " In addition to carrying authentication information,
PANA MUST also carry a binary result (i.e., success or failure)
of authorization for network access to the PaC. Providing finer
granularity authorization is outside the scope of PANA."
What is the reason for this limitation?

Thanks,
Eva

---

From: Eva Gustafsson <[email-masked]>
Date: Fri, 15 Mar 2002 15:32:30 -0800

And here are some questions and comments on the usage
scenarios draft (draft-ietf-pana-usage-scenarios-01.txt).
(Again, my apologies if these issues have been discussed
before...)

Where in the draft are the usage scenarios described?
They are not obvious.

What is the relation between this draft and the requirements draft?
I see a lot of requirements on PANA in the usage scenarios draft.

Section 2. iii: "Authentication MUST be independent of any IP
address configuration method..." and "Authentication MUST be
able to occur both before and after configuring an IP address..."

Does the usage scenarios draft put requirements on the authentication
procedure? What specific authentication protocol does this refer to?

Throughout the draft, I have a hard time understanding the difference
between PAA and NAS. In section 1.3 it is stated: "For example,
PAA is a NAS." Is PAA really the same thing as a NAS? Or does
PAA constitute a subset of the NAS? Or what is the relation between
them?

What is the formal relation between the local security association
(LSA) and PANA (and the PAA)?

Section 2. i: "Need for authentication over unauthenticated L2 links."
How can a link be authenticated (or unauthenticated)?
What identifier is this authentication based on?

Section 3.1: "The important point is that PANA MUST support
all multi-AR scenarios."
From reading the draft, I have a hard time understanding what
these scenarios are. It would be nice if the draft could outline
these scenarios, point out possible problem areas, and discuss
what implications they may have on the PANA protocol and
on the PAA.

Lastly, I have the same question as I had for the requirements
draft: why isn't authorization considered to the same extent
as authentication?

Thanks,
Eva

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 15 Mar 2002 16:18:41 -0800

Hi Eva,

> appreciate if the requirements and terminology draft could clarify these

Yes, it seems like we need to add some more text into the draft to
clarify this further.

Within the scope of this WG is to:
- pick one (or more) already defined authentication protocols, as payload
- define a link-layer independent carrier
- make sure this combination satisfies the requirements. some requirements
  are satisified by the transport, some by the payload. this division really
depends
  on the particular protocols of choice.

> Either way, it needs to be clarified.

The I-D says:

   PANA MUST NOT define new security protocols or mechanisms. Instead
   it must be defined as a "carrier" for such protocols. PANA MUST
   identify which specific security protocol(s) or mechanism(s) it can
   carry (the "payload").

So, the goal is not to define a carrier for *any possible authentication
protocol*.

> PANA, right? Then these requirements should be specified in the

Depending on the choice of the payload, proposed protocols have to deal
with their payload-driven requirements. We are defining the high-level
requirements that must be satisfied by the marriage of the proposed
transport+payload.

> be able to work with Diameter and RADIUS in the backend. Making

This is what we mean by "use AAA". Radius, DIAMETER, or some
other AAA implementation along this line.

> reason for not discussing this in the requirements draft?

Do you think we might have Radius specific or Diameter specific
requirements that cannot be generalized under a "use AAA backend"
requirement?

> "some other mechanism" puts on the PANA protocol.

For example deploying your own proprietary database across
all access nodes in your domain. This is to prevent people from
being conditioned that AAA is the only backend. Does it create
any particular requirement on the transport? I guess not.. As long
as people know how to use the "payload" with their proprietary
system.

> on separation between the carrier and authentication parts.)

Agreed.

> requirements that authorization in itself may put on the PANA protocol?

The inseparable part of the authorization is already included in the
protocol.
(ability to say the PaC has passed authentication and granted network
access).
But, finer granularity authorization is not in the scope. (the ability for
the PaC
to ask for different levels of service, e.g., bandwidth, and the PAA to
grant
different levels of service..)

> Section 4.2.1: could someone explain to me the definition of

non point-to-point. like ethernet. which means potentially having
several hosts and routers on the same link.

> What is the reason for this limitation?

Because we think designing PANA with finer granularity authorization
at this point is not necessary. Later it can be extended to handle this
case.

Thanks.

alper

---

From: subir Das <[email-masked]>
Date: Fri, 15 Mar 2002 19:36:55 -0500

Hi Eva,

> (Again, my apologies if these issues have been discussed

  Thanks for your comments. Pl. see my answer inline.
> Where in the draft are the usage scenarios described?

  Agreed. We will describe some scenarios in the WG meeting and 
  will incorporate in the next version.
> What is the relation between this draft and the requirements draft?

  Usage scenario draft provides input to the requirement draft.

> able to occur both before and after configuring an IP address..."

  Agreed. There is some ovelap and we are trying to separate it.
> procedure? What specific authentication protocol does this refer to?

  No. It describes the high level problem without mentioning specific 
  requirements and solutions. 
> PAA constitute a subset of the NAS? Or what is the relation between

  Yes, PAA is similar to NAS at a  high level.

> (LSA) and PANA (and the PAA)?

  LSA is a security association created locally between PAA and PaC
after 
  successful initial authentication. So it is a part of PANA. 

> What identifier is this authentication based on?
  
  We refer "unauthenticated L2 links" as L2 links which do not have 
  support for authentication. In particular, L2 protocols which do not 
  have mechanisms to carry authentication parameters. 

> what implications they may have on the PANA protocol and

  Agreed. As I mentioned earlier, we will incorporate that in our next 
  version after the WG feedback.
> draft: why isn't authorization considered to the same extent

  I guess Alper has already replied to this issue.

  Regadrs,

  Subir

---

From: Eva Gustafsson <[email-masked]>
Date: Sat, 16 Mar 2002 18:08:29 -0800

Hi Alper,

Thanks for your comments!

> requirements that cannot be generalized under a "use AAA backend"

Yes I do, although these requirements may apply to the authentication
protocol / payload rather than to PANA as a carrier.
(I'm not sure about this part yet...)

However, from your explanation of the scope of the requirements draft,
my understanding is that it defines high-level requirements both on PANA
(the carrier) and on the authenticaion protocol / payload. So, I think the
draft should at least specify what AAA protocols must be supported in
the backend. Currently, the draft states that PANA must co-exist with
"Mobile IPv4 [MIPV4], Mobile IPv6 [MIPV6], fast handover protocols
[FMIPV4, FMIPV6], and... ...IPv6 stateless address auto-configuration
[ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP
[DHCP]". I would expect at least the same level of detail for the "AAA
backend". (There isn't even a reference to any AAA protocol in the draft
right now...)

Also, do you intend to use for example Diameter as it is specified today
in the backend, or do you expect PANA or the payload to require
extensions to Diameter (or any other AAA protocol used)?

> protocol. (ability to say the PaC has passed authentication and granted
> network access).

Ok...

> the PaC to ask for different levels of service, e.g., bandwidth, and the
> PAA to grant different levels of service..)

Why not?

Are you saying that for example a scenario where the network for some
reason wants to terminate a client's access to resources (network-initiated
termination of authorization) must not be supported by PANA?
(Or do you see this as part of PAA-initiated re-authentication?)

> at this point is not necessary.

Why? Could you explain your thinking?

Thanks,
Eva

---

From: Eva Gustafsson <[email-masked]>
Date: Sat, 16 Mar 2002 18:17:32 -0800

Hi Subir,

Thanks for your comments.

> We will describe some scenarios in the WG meeting and

Sounds good!

> Yes, PAA is similar to NAS at a  high level.

Could you elaborate on this?

> after successful initial authentication. So it is a part of PANA.

Ok. Right now, the draft defines LSA as a "temporary security
association between a client and a NAS...".

> have mechanisms to carry authentication parameters.

Ok. I find that definition much more comprehensible than
"unauthenticated L2 links".

Thanks,
Eva

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 16 Mar 2002 22:29:13 -0500

> > will incorporate in the next version.

I want opinions from the WG members on what exact scenarios shoule be
included.  In fact, some usage scenarios on "how PANA can be used"
were described in the previous version, however, some people did not
like it and instead requested to focus on describing the problems to
be solved by PANA.

> Could you elaborate on this?

PAA is a NAS in that it allows network access to the device after
verifying the credentials provided by the client.  

> "unauthenticated L2 links".

OK, we will change the title of need (i) to more comprehensible one.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Sat, 16 Mar 2002 20:32:27 -0800

Eva,

> (I'm not sure about this part yet...)

Yes, I think so.

> backend". (There isn't even a reference to any AAA protocol in the draft

I disagree. If there is a well-defined AAA framework, and the AAA protocols
are in compliance with this framework, we can get away just referencing to
AAA
and not to any particular instance of AAA. The burden is on the proposals to
show
how their payload are compatible with AAA protocols.

> extensions to Diameter (or any other AAA protocol used)?

I don't expect extensions to AAA protocols. Do you?

> > PAA to grant different levels of service..)

see below..

> termination of authorization) must not be supported by PANA?

It must be supported as 4.2.2. describes.

> (Or do you see this as part of PAA-initiated re-authentication?)

That can be used as a tool as well, but we should have a direct message for
that (4.2.2)

> Why? Could you explain your thinking?

In this simple form, the protocol can serve an essential and more
immediate need: Authenticating network access.
And we can achieve this goal (protocol design) faster .
Another protocol(s) can be use after a successful PANA authentication
for further authorization (including IP addres allocation, etc.)
Or, later PANA may(?) be extended to serve these needs as well.
Extending the charter and scope to include full blown authorization
won't be as productive. I think this is a good modular strategy.
IMHO.

alper

---

From: subir Das <[email-masked]>
Date: Mon, 18 Mar 2002 10:23:15 -0500

> Could you elaborate on this?

  PAA will have the same functionality like today's NAS in terms  of
access authorization. PAA will verify the user credentials and provide 
the hooks to access control protocols to perform the access control.

Subir