Subject: Re: draft-ietf-pana-usage-scenarios-00.txt

From: Alexis Olivereau <[email-masked]>
Date: Wed, 30 Jan 2002 15:40:42 +0100

Hello all,

I would like to react quickly on this draft, specially §2:
  "Different kinds of service models are also emerging in today's   
Internet.  For example, while basic connectivity may be   
user-agnostic, enhanced services will be available only to    authorized
users (since charging is involved for such services)."

As far as I know, PANA is to address "only" authentication aspect.
Collected authentication data may then be forwarded to a AAA server for
AAA authentication part.  The topic raised here in the draft seems much
wider however, since it deals with authorization, which is itself
closely linked with charging.  Let me just share my vision: I am not
sure that we can really that easily split authentication part from two
other 'A's when considering a deployed AAA architecture.

If I have well understood, the envisioned situation is the following:
  * User connect to a network through any interface/technology.
  * User provides credentials to PAA and establishes a LSA (BTW this is
really a critical point: AAAH can easily distribute a shared secret to
both user (directly) and PAA (through AAAL) but... we need something
very close to a PKI :/ ).
  * User may then want to get authorized for a specific service.  This
aspect is not to be considered in PANA WG, maybe NSIS or another WG can
address it.
I am not sure whether this analysis is correct (?)... In such a scheme,
it appears that user does not dialog any longer 'directly' with AAA
infrastructure (?) except for authentication, for which PANA is to carry
all info towards AAA.

Many problems may arise then.  For example "dynamic charging". 
Basically, charging parameters may change during a session; on the other
hand, a negotiation phase with AAA infrastructure is very likely within
an authorization request.  Negotiation requires direct communication
between end user and AAA, while nothing is designed yet to carry such
negotiation messages.  On the other hand, we may have to carry an
authorization request towards AAA in case the 'Agent Model' of RFC2904
is used (first AAA, then QoS if authorized by AAA).

Will we have to design one day a 'Protocol for carrying Authorization
Requests'? A 'Charging Negotiation Protocol'? Can we, even lightly,
extend PANA to address these points?
What do you think?

Alexis

+ a minor point for draft authors: p.7 "D1 or D2" should be "D1 or D3",
"D3 or D4" should be "D2 or D4".

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 30 Jan 2002 14:20:57 -0500

Hello Alexis.

> closely linked with charging.  

Since the usage scenarios I-D mainly describes service models
possiblly realized by using PANA, it might include both in-scope
issues and out-of-scope issues for PANA.  See the charter for the
scope.  Also, the terminology/requirements document will make the
scope clearer.

The issue on whether PANA is to address "only" authentication aspect
or not is being discussed by the terminology/requirements team.  In my
understanding, when a client is authenticated, the authentication
result (i.e., success or failure) would also indicate a binary result
of authorization for network access service.  So carrying such a basic
authorization result is at least in scope of PANA, IMHO.

> Let me just share my vision: I am not

I'm not sure what do you mean by "we need something very close to a
PKI".  In addition, as you may know, PAA may or may not use AAA
infrastrucure for authenticating a user.

> aspect is not to be considered in PANA WG, maybe NSIS or another WG can

MIDCOM WG also addresses that aspect.  We need to discuss whether the
aspect is to be considered in PANA WG or not.  I hope it is not to be
considered instead of re-inventing the same wheel.

> negotiation messages.  

So far, carrying accounting data is out of the scope of PANA.

> On the other hand, we may have to carry an

I don't think realizing those protocols within PANA is a good idea.
Instead, I would suggest considering how to utilize LSA established by
using PANA for those protocols.  In fact, I would prefer modular
approach (i.e., separated protocol per main functionality) than
combined approach.  One typical example is the fact that PANA is
independent of IP address configuration mechanism.  If people prefer
AAA over DHCP and AAA-extention for MIPv6, this WG were not created :)

> "D3 or D4" should be "D2 or D4".
Content-Description: Card for Alexis Olivereau

Thanks for correction.  I'll fixed it in the next version.

Yoshihiro Ohba

---

From: Alexis Olivereau <[email-masked]>
Date: Thu, 31 Jan 2002 14:59:13 +0100

Hello Yoshihiro,

> authorization result is at least in scope of PANA, IMHO.

Okay but that's not really authorization in the sense of 'matching a
user profile for access to a specific QoS/service'.  Plus this kind of
authorization cannot be dissociated from authentication process.  Though
there are some cases where we may want to get authorized without any
authentication.  Just consider the concept of prepaid cards for phone
calls; we may want to extend this concept to network access, let's say
"2 prepaid hours of 512kbps connection".  Then how do we present that
kind of credential, which can be understood/validated only by AAA?

> infrastrucure for authenticating a user.

Sorry I was not that clear here... What I meant is that in case you do
not have AAA, you need a pki to establish a shared secret between MN and
PAA.  And actually if we have AAA, AAA acts like a pki... Anyway this
was not the topic I wanted to raise here :-)

> considered instead of re-inventing the same wheel.
 
Thank you, I did not know that.  I will follow their work more closely.

> So far, carrying accounting data is out of the scope of PANA.

I did not really mean accounting because end user does not have to worry
about accounting data is collected (s/he has to check that accounting
entity does not cheat, yet, but that's another thread).  On the other
hand, charging parameters _have to_ be negotiated between user and AAA:
"I want 512kbps / Okay that's 2$ per min / Well perhaps 384kbps will be
enough :-)". Or something like that, which we have no protocol to carry
yet.

> AAA over DHCP and AAA-extention for MIPv6, this WG were not created :)

This is an approach that looks reasonable.  On the other hand, a long
time ago :-), when PANA used to be named "User Network AAA Protocol" I
had the feeling that we were planning to fill the gap between end-user
and AAA infrastructure: direct communication appear to be more and more
required.  Now with PANA it looks like we are distancing from AAA and
strongly focusing on authentication, whereas 'Network Access' may imply
some fine access control (e.g. QoS).
But, again, the modular approach you defend looks coherent and I fully
agree that LSA will have to be an essential prerequisite for other
protocols in case they are developped externally.

Alexis

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 15:27:47 +0100 (CET)

> scope.  Also, the terminology/requirements document will make the

Hmm - if the usage scenario document does it it would seem to make
sense to label which scenario or "component" os scenario is in scope for
PANA. If not utter confusion about scope will contiue to be a problem.

As an alternative the document could also just specify the things that are in
scope.

  Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 31 Jan 2002 12:47:06 -0500

> As an alternative the document could also just specify the things that are in

OK.  Maybe labeling approach would be better because the I-D contains
important senarios such as relationship between PANA and /64 prefix
address assignment/access control, where the component of /64 prefix
address assignment/access control is out of the scope of PANA.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 31 Jan 2002 13:42:39 -0500

> kind of credential, which can be understood/validated only by AAA?

It would be an interesting issue.  Actually there is a proposal named
DSNP (Dynamic Service Negotiation Protocol) used for such purpose (see
draft-itsumo-dsnp-00.txt).  However, from the modularity viewpoint, it
would be better to separate that functionality from PANA, IMHO.

> was not the topic I wanted to raise here :-)

OK.

> enough :-)". Or something like that, which we have no protocol to carry

See my first comment.

> protocols in case they are developped externally.

Thanks for understading my point.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 31 Jan 2002 14:31:31 -0800

Alexis,

> kind of credential, which can be understood/validated only by AAA?

Well, the buyer of that pre-paid car can be given a userid and a password:

id: prepaid<number>@<provider's_name>.com
password: <that 16 digit numbers they give out>

So, just like [email-masked] is associate with certain
level of service (unlimited, charged $19.99 per month), this user
"prepaid<number>" is a temporary user with rights to 2 hour
connectivity.....

> required.  Now with PANA it looks like we are distancing from AAA and

I'd not call this "distancing". Authentication is common to both PANA and
AAA,
and in fact the first step. We are covering this necessary step with PANA.
It's just
we are not covering all the bases that AAA does (yet).

> protocols in case they are developped externally.

alper