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

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Thu, 12 Dec 2002 12:17:49 +0100

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: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Dec 2002 11:22:41 -0500

I considered a bit more on this issue.

When multiple EAP methods are used in a single EAP conversation (EAP
allows it), it is possible for an EAP peer (or a PaC in the case of
PANA) to use different identifiers for each of the EAP methods in the
conversation.  Such identifiers can be used for choosing a different
authentication server for each method.  This can serve for your
purpose with using a single DI and a single PAA and still not
violating the PANA requirements since the DI is associated with a
single PaC.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 13 Dec 2002 15:19:28 -0800

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.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Dec 2002 11:19:20 -0500

I have one additional issue in mind that would affect the requirements
for EAP authentication policy.

Assume that multi-method EAP authentication is used for providing
multi-level authentication (i.e., NAP authentication and ISP
authentication).  If the EAP method performed for ISP authentication
fails, but the other EAP method performed for NAP authentication
succeeds, should the entire EAP conversation fail?  I think EAP should
be flexible enough to allow the policy in which EAP-Success message is
returned even when some of the methods fails.

Yoshihiro Ohba