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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 10 Jan 2003 17:12:46 -0800

> 
> 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.
> 
Why is this required to setup filters in one set ?

> 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.
> 
Why aren't these two authentications independent of one another i.e
why do we have to link them together ? 

-mohan

> 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: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 10 Jan 2003 17:25:16 -0800

> why do we have to link them together ?

The two authentications should take place independently. But at the
end they are used to authorize some (combination) service to a single
device.

Access network should be able to look at an incoming packet and be able
to identify a filtering rule to apply without any ambiguity. The filtering
rules might be result of one or more authentications, that's fine.

If a device is going through multiple authentications with the
access network, we need to know how to treat the result of each one.
In the case Lionel is describing, the final service authorization
is a combination of each authentication/authorization. In another
(simpler) case the latest authentication/authorization may override
the previous one. (as if the client is either getting service associated
with user1@NAP or user1@ISP)

alper