Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft...

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Fri, 10 Jan 2003 20:30:12 +0100

Hi Alper and Happy new Year to the PANA folks!

I will try (with some delay) to answer to your request using a suitable scenario.

One basic objective of multiple-level authentication could be to allow the NAP to distinguish different users and to be able then to provide distinct network configurations to those clients (with different classes of Service (CoS) for instance).

On this basis, two different users may subscribe to:

- two different CoS offered by the NAP,
- two different ISPs,

and they may be able to use the same access link but at different time (in this example).

If one user would like to browse the Web, the client will be first authenticated by the NAP in order to determine what Cos the client has subscribed to. Once authenticated by the NAP, the client will be authenticated by his/her ISP as usual.

- If the first authentication failed (but the second one succeded), a per-default network configuration could be selected for the current connection or the NAP could decide to reject the access request.

- If the second authentication failed (but the first one succeded), the client will not be allowed to browse the Web but some local services (provided by the NAP) could be nevertheless offered.

Several other combinations are also possible.

Does this scenario answer correctly to your questions, Alper?

>-----Message d'origine-----
>De : Alper E. YEGIN [mailto:[email-masked]]
>Envoyé : samedi 14 décembre 2002 00:19
>À : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba;
>[email-masked]
>Cc : [email-masked]
>Objet : Re: About the NAP/ISP distinction in the usage-scenarios
>draft...
>
>
>
>Lionel,
>
>I think it'd be useful to understand the semantics of each 
>authentication,
>and the expected actions taken by the client and the network 
>after each one
>is
>completed.
>
>For example:
>1- what does it mean to the NAP when a client gets authenticated? What
>actions
>should be taken (e.g., how are the filters updated, where are 
>they updated,
>etc.)?
>
>2- What can or cannot the client do after this first round of
>authentication?
>
>3- same question as 1, but for ISP authentication.
>
>4- same question as 2, but for ISP authentication.
>
>
>alper
>
>
>
>> Hi Alper,
>>
>> I think that, in the described scenario, the principle of 
>two successive
>authentications (one per AAA backend) may appear obvious. However,
>considering a single PAA handling the both authentication 
>procedures, there
>is an issue concerning the use of the DI.
>>
>> The most intuitive idea is to reuse the same DI for both 
>authentications
>and to use different sets of credentials 
>(identifier,authenticator) supplied
>by the client. But according to the current draft on the PANA 
>requirements
>and as Yoshihiro said, it seems that it should not be possible.
>>
>> On the other hand, the alternative would be to use different 
>DIs but the
>PAA would create distinct bindings, and so distinct instances 
>in this case,
>that would make the network access control more complex.
>>
>> A simple solution here could be to allow in the PANA requirements the
>association of one single DI with different PaCs, but this may 
>raise up some
>other previous/new concerns.
>>
>> What do you think about this?
>>
>> Best Regards,
>>
>> Lionel
>>
>>
>> >-----Message d'origine-----
>> >De : Alper E. YEGIN [mailto:[email-masked]]
>> >Envoyé : jeudi 12 décembre 2002 00:16
>> >À : MORAND Lionel FTRD/DAC/ISS; 
>[email-masked]; Yoshihiro
>> >Ohba; [email-masked]
>> >Objet : Re: About the NAP/ISP distinction in the usage-scenarios
>> >draft...
>> >
>> >
>> >
>> >Hello Lionel,
>> >
>> >Thanks for bringing this scenario up.
>> >
>> >In the case both NAP and ISP requires their own independent
>> >client authentication, I presume we can still envision both
>> >using the same PAA on the BAS (broadband access server). Does this
>> >makes sense?
>> >
>> >For NAP authentication, PAA consults with AAA backend in NAP
>> >network. For ISP authentication, PAA consults with AAA backend
>> >in ISP network.
>> >
>> >Somehow the client needs to know (or discover??) that it has
>> >to go through the authentication twice. Discovery might be tricky
>> >because something has to tell the client that the second one
>> >is meant for the ISP, etc.... If the client knows it has to do both,
>> >it can differentiate the authentication process by using different
>> >client identifiers in each. Therefore PAA can demultiplex the
>> >authentication request to the right backend.
>> >
>> >So, running PANA twice between the PaC and the same PAA maybe one
>> >approach. Each time PaC can use a different set of 
>credentials. If the
>> >same credentials are used, then we need something else in 
>the process
>> >to indicate which one is for NAP authentication vs for ISP
>> >authentication.
>> >
>> >When two different set of credentials are used, if PaC uses the same
>> >DI, this might be an issue. Normally they would appear as 
>two separate
>> >clients to the PAA, but since the network is aware of this
>> >dual-authentication
>> >scheme, and the requests are coming from the same circuit, 
>maybe this
>> >can be handled. And than, how will these DIs be used with service
>> >provisioning, after each authentication? Is EP still co-located
>> >with BAS here? How should the NAP authentication update EP, and ISP
>> >authentication update EP? These are general questions about 
>the model
>> >you are describing..
>> >
>> >
>> >alper
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >----- Original Message -----
>> >From: MORAND Lionel FTRD/DAC/ISS
>> >To: [email-masked] ; Yoshihiro Ohba ;
>> >[email-masked]
>> >; Alper E. YEGIN
>> >Sent: Monday, December 09, 2002 5:59 AM
>> >Subject: About the NAP/ISP distinction in the 
>usage-scenarios draft...
>> >
>> >
>> >Hi folks,
>> >
>> >In the current version of the Usage-Scenario draft, in the 
>section 3:
>> >Problem Statement, the distinction between NAP (Network Acces
>> >Provider) and
>> >ISP (Internet Service Provider) is pointing out.
>> >
>> >[...An important aspect of an authentication protocol is 
>the ability to
>> >provide dynamic service provider selection to the clients.
>> >Regardless of
>> >their network access provider (NAP), clients should be able to
>> >select an
>> >Internet access provider (ISP) of their choice. This is
>> >usually achieved by
>> >clients presenting an identifier which carries domain
>> >information during the
>> >authentication process. ]
>> >
>> >This distinction is particularly true in the case of DSL
>> >networks where NAP
>> >and ISP are often two different players. Besides traditional
>> >"package" offer
>> >(access + Internet provided by the ISP), NAP are able to
>> >provide broadband
>> >access services directly to the user, regardless of the ISP
>> >selected by the
>> >user. Moreover, different access network configurations may be
>> >provide to an
>> >xDSL client, based on the access service subscribed to the
>> >NAP. We could
>> >also imagine the provision of some local services in the
>> >short/medium term.
>> >
>> >In order to provide such a "customized" service, the NAP needs to
>> >identify/authenticate the user that logs on to the access 
>network. This
>> >authentication is independent from the authentication achieved
>> >by the ISP
>> >and so not necessarily based on the same user credentials.
>> >This induces a
>> >requirement for two levels of authentication: one at the NAP
>> >level, one at
>> >the ISP level. I think that this requirement is not only
>> >restricted to xDSL
>> >network and be generalized on the contrary.
>> >
>> >For the time being, if PPP is used to carry user information for ISP
>> >authentication, NAP identification is mainly based on
>> >information on the
>> >physical link used for the connection (phone line number, ATM
>> >link, etc.)
>> >and not according to the user using the connection. So it is
>> >not possible to
>> >distinguish two consecutive users using the same link and 
>the network
>> >configuration is only based on the service subscribed for the
>> >access link.
>> >
>> >and now I wonder:
>> >How the PANA protocol could fulfil such a requirement on two
>> >authentication
>> >levels (NAP, ISP)?
>> >What would be the consequences on the general PANA requirements?
>> >Would it be useful to include/precise this scenario be in 
>the current
>> >usage-scenarios draft?
>> >Any comment/reaction from the mailing list?
>> >
>> >Lionel.
>> >
>> >
>>
>
>

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 10 Jan 2003 14:45:39 -0800

Hi Lionel,

One way to achieve this scenario is to:
- let a user have two identifiers. E.g.: [email-masked], and [email-masked]
- Single PAA co-located with the BAS (broadband access server).
- PaC either performs single PANA authentication in which two
  subsequent authentication methods are executed, one with each PaC
  identifier; or it performs one PANA authentication after another, again
  each with different PaC identifier.
- One set of filters should be set on the EP, which will be a product
  of the successful authentication methods.

If two PANA authentications take place, then PAA should be able
to associate both with the same entity. Note that they would have
different PaC identifier, but since they are coming from the same
device (circuit id) in particular order with close proximity, this
is possible.

One change needed on the current set of assumptions and requirements
would be to relax one2one mapping between PaC and device identifiers.

Can anyone think of other ways to implement this scenario?

alper

----- Original Message -----
From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
To: "Alper E. YEGIN" <[email-masked]>; "Yoshihiro Ohba"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 10, 2003 11:30 AM
Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft...

> One basic objective of multiple-level authentication could be to allow the
NAP to distinguish different users and to be able then to provide distinct
network configurations to those clients (with different classes of Service
(CoS) for instance).
> If one user would like to browse the Web, the client will be first
authenticated by the NAP in order to determine what Cos the client has
subscribed to. Once authenticated by the NAP, the client will be
authenticated by his/her ISP as usual.
>
> - If the first authentication failed (but the second one succeded), a
per-default network configuration could be selected for the current
connection or the NAP could decide to reject the access request.
>
> - If the second authentication failed (but the first one succeded), the
client will not be allowed to browse the Web but some local services
(provided by the NAP) could be nevertheless offered.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 10 Jan 2003 19:36:15 -0500

Lionel and Alper,

> device (circuit id) in particular order with close proximity, this

In the case of two PANA authentications, it seems that there is an
assumption that the client uses the same username part (i.e., "user1"
in the above example) of the two identifiers.  If this is not the case
(I think NAP and ISP identifiers can be independently assigned), how
can the PAA tell whether different identifiers are used by the same
client or or by different clients?  Note that the device ID may be
spoofed or may be re-assigned to other device before the second PANA
authentication occurs.

On the other hand, if we use single PANA authentication with two
subsequent authentication methods, the two identifiers are associated
within the single PANA authentication, so the two identifiers can be
independently assigned.  However, a PaC may not be able to know the
authentication result of each method (this could happen in EAP),
(though it can know the final authentication result of the single EAP
sequence), and someone might not feel convenient about this
restriction.

Fortunately, there is another usage.  That is, running two EAP
sequences in a single PANA authentication, i.e., one EAP method is
performed in each EAP sequence in order to generate Success/Failure
message per each method.  Note that PANA over TLS works with this
usage.

> would be to relax one2one mapping between PaC and device identifiers.

I don't think we should relax the requirement for the above reason.

> Can anyone think of other ways to implement this scenario?

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 13 Jan 2003 12:10:39 -0800

Hi Yoshihiro,

> spoofed or may be re-assigned to other device before the second PANA

I agree this gets tricky than. Depending on the environment, two
subsequent authentication requests may or may not come from the same
"client".

> message per each method.  Note that PANA over TLS works with this

Yes, running two independent EAP sequences (each with its own
success/failure messages) inside a single PANA sequence is a good idea.
but....

> I don't think we should relax the requirement for the above reason.

....but your recommended method still doesn't cure the mapping problem
between
the client ID and the device ID. If we run two EAP sequences with two
different
client identifiers, PAA will still have two PaC ID that maps to a
device ID.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 13 Jan 2003 15:32:42 -0500

> client identifiers, PAA will still have two PaC ID that maps to a

I think the two EAP identities used in a single PANA authentication
can be handled as a single PaC ID that is a concatination of the two.

Yoshihiro Ohba