Subject: RE: Please review

From: <[email-masked]>
Date: Thu, 15 May 2003 11:10:37 +0300

Some comments and questions below.

> -----Original Message-----
> From: ext Mohan Parthasarathy [mailto:[email-masked]]
> Sent: 14 May, 2003 19:26
> To: Alper Yegin; [email-masked]
> Subject: RE: Please review
> 
> 
>  
> > 
> > > 
> > > 2) In section 4.1,
> > > 
> > > A PaC can be identified by the credentials (e.g., identifier,
> > > authenticator)
> > > 
> > >  This usage of the word identifier is confusing. It is 
> not talking 
> > > about device  identifier but about the identity of the 
> > device here. I 
> > > think it would be better to use
> > >  identity to mean "authenticating the identity" and 
> > identifier to mean
> > > the "device
> > >  identifier".
> > 
> > I see. How about this:
> > 
> > PANA MUST enable authentication of  PaCs for network access. 
> > A PaC's identity can be authenticated by verifying the 
> > credentials (e.g., identifier, authenticator) supplied by one 
> > of the users of the device or the device itself. PANA MUST 
> > only grant network access service to the device identified by 
> > the DI, rather than granting separate access to multiple 
> > simultaneous users of the device. Once the network access is 
> > granted to the device, the methods used by the device on 
> > arbitrating which one of its users can access the network is 
> > outside the scope of PANA.
> > 
> 
> Sounds good to me.

The confusion lies in the words "PaC's identity". What is PaC's 
identity? Aren't we talking about identity of the user or an account 
that can be charged [identity can be a temporary id or encrypted in 
some ways so that PAA can't trace the identities]. Session id is the
only one that doesn't change during the PANA session. The identity 
is specific to the EAP method and thus we can't rely on that too much
but on the authentication result.

I think the process goes like this: if authentication is succesfull, 
bind the session id to the DI. If security associations are created 
they must be bound to the session id too. 

> 
> > 
> > > 
> > > 3) In section 4.1,
> > > 
> > >  Both the PaC and the PAA MUST be able to authenticate each 
> > other for  
> > > network access. Providing capability of only PAA 
> > authenticating the  
> > > PaC is not sufficient.
> > > 
> > >  I guess the above the same issue we were discussing  
> > yesterday i.e it 
> > > depends  on which environment PANA is being used. So, you 
> > may need to 
> > > clarify "MUST be able to".
> > 
> > New text added:
> > 
> > Both the PaC and the PAA MUST be able to authenticate each 
> > other for network access. Providing capability of only PAA 
> > authenticating the PaC is not sufficient. 
> 
> The last sentence can be reworded to "It may not be sufficient
> for just the PAA to authenticate the PaC" (or something better). 

How does PANA enable mutual authentication between PaC and PAA? Does 
the PAA have an identity that is authenticated? By whom?

Does this mean that the EAP Server must be in the same domain as 
the PAA, if mutual authentication is required?

> 
> > Mutual authentication capability is necessary in some environments 
> > but not in all of them. For example, clients might not need 
> > to authenticate the access network when physical security is 
> > available (e.g., dial-up networks).
> > 
> 
> ok.
> 
> > > 
> > > 4) In section 4.1.4, identity and identifier can be used 
> to clearly 
> > > distinguish the  things that are used in authentication and 
> > > authorization.
> > 
> > I didn't quite get what I should be doing here.
> 
> Same as (2) above. During the authentication phase, you verify
> the identity of some one. This is the most common usage. And
> access control is based on identifier/device identifier. I am
> mostly biased by IKE/Ipsec usage.

Yep, and the identifier is bound to the SA.

> 
> > 
> > > 
> > > 5) In section 4.1.4,
> > > 
> > >      PAA MUST be able to create a binding between the PaC and the
> > >      associated DI upon successful PANA exchange. The DI MUST be 
> > > carried
> > >      either explicitly as part of the PANA payload, or 
> > implicitly as 
> > > the
> > >      source of the PANA message, or both.
> > > 
> > >  Isn't the second line related to the first line i.e The 
> DI MUST be 
> > > carried  for ...creating such a binding. It might help 
> > clarifying it.
> > 
> > Some new text here:
> > 
> > PAA MUST be able to create a binding between the PaC and the 
> > associated DI upon successful PANA exchange. This can be 
> > achieved by PANA communicating the PaC identifier and DI to 
> > the PAA during the protocol exchange. The DI can be carried 
> > either explicitly as part of the PANA payload, or implicitly 
> > as the source of the PANA message, or both.
> > 
> That sounds better.

What's the difference between PaC identifier and DI? Maybe it is
"between PaC identity and DI". But see my comment about identity
above.

What about this:

  PAA MUST be able to create a binding between the PaC and the
  associated DI upon successful PANA exchange. This binding is 
  identified with a session id, which doesn't change during the 
  PANA session. For each session PaC's DI is delivered for PAA 
  and bound to the session. The DI can be carried either explicitly 
  as part of the PANA payload, or implicitly as the source of the 
  PANA message, or both. If PANA SA is created, it MUST be bound
  to the session.

- Dan

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 May 2003 11:28:41 -0700

> How does PANA enable mutual authentication between PaC and PAA?

By carrying EAP methods that can authenticate peer to authentication server
and vice versa.

> Does 

Generally it is the authentication server (AS) that is being
"authenticated." If the AS is co-located wiht PAA, this is like
authenticating the PAA. When they are separated, it is the responsibility of
the AS to authenticate PAA (via IPsec, TLS) before returning a positive
result to the PaC. Anyways, at the end, PaC knows PAA is trustworthy.

Note: So far what I explained has nothing to do with PANA. This is EAP and
AAA design.

> the PAA, if mutual authentication is required?

No, please see above.

> What's the difference between PaC identifier and DI?

PaC ID gets authenticated and authorized for network access.
For example: your NAI.

Once the PaC with PaC ID is authorized, the network must know how to
recognize the packets of this particular PaC. This is when device ID comes
into play. Examples of device ID are: mac address, IP address.

[when simple filters are not sufficient, crypto keys are also bound to the
PaC. We can see them as attributes of device ID]

> Maybe it is

I'd not get into session id in the requirements draft.
We don't have to have a session id for this protocol. We now have it in the
design, but.... it's a bit of a syntethic abstraction (which of course have
many uses......)

All the protocol needs is to know what is authenticated: PaC.
Once the authentication is successful, what is used for access control:
device ID.
As long as we know how to bind a PaC to a device ID, we are done.

Alper