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

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Mon, 13 Jan 2003 10:46:55 +0100

Hi Alper,

It was actually one of my previous conclusions. But maybe there are other points of view...

>-----Message d'origine-----
>De : Alper E. YEGIN [mailto:[email-masked]]
>Envoyé : vendredi 10 janvier 2003 23:46
>À : MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba;
>[email-masked]
>Cc : [email-masked]
>Objet : Re: About the NAP/ISP distinction in the usage-scenarios
>draft...
>
>
>
>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...
>
>
>> 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: <[email-masked]>
Date: Tue, 14 Jan 2003 18:14:25 -0600

> > This requirement means that a PaC client can't use PANA 
> > protocol from an
> > access network (AN) that doesn't support PANA, even if there 
> > were networks
> > that support PANA behind the AN :). This is an issue that affects the
> > transition period.
> >
> 
> Yes, if an access network wants to use PPP, or 802.1x, or PANA for
> authentication, it has to place the right set of protocol entities in
> the right place on the network. Enabling use of PANA thorugh 
> access networks that are not aware of this protocol does not sound too 
> practical (or needed) to me.

But from the EAP analogy, the access network can be considered simply
as a passthrough. In EAP the access network does not have to understand
or support the actual EAP methods. The same approach may be considered
as viable for PANA in certain scenarios. I believe the point is that
the access network or EP needs to be somehow informed about the success
or failure of the authentication of a PaC which results in an ACK or
NAK for IP connectivity being sought by the client.

-Basavaraj