Subject: RE: Please review

From: <[email-masked]>
Date: Fri, 16 May 2003 11:30:15 +0300

Alper, 

Some comments.

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 15 May, 2003 21:29
> To: Forsberg Dan (NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: Re: Please review
> 
> 
> 
> > How does PANA enable mutual authentication between PaC and PAA?
> 
> By carrying EAP methods that can authenticate peer to 
> authentication server
> and vice versa.

Mutual authentication between PaC and AS is different than 
between PaC and PAA.

This creates an implicit requirement for the relationship 
between PAA and AS (_two way_ SA between PAA and AS), which 
is out of the scope of PANA.

> 
> > Does 
> > the PAA have an identity that is authenticated? By whom?
> 
> 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.

There is a difference between one way (PAA<--AS) SA and two way SA 
(PAA<-->AS) as I tried to explain above. Maybe it would be a good
idea to clarify this in the requirements draft, or at least the 
requirement itself (what is really wanted?!).

I created an open issue about this (clarifying text required):
http://danforsberg.info:8080/pana-issues/issue13

> 
> > 
> > Does this mean that the EAP Server must be in the same domain as
> > the PAA, if mutual authentication is required?
> 
> No, please see above.
> 
> >>> 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?
> 
> 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.

Ok. I was 'afraid' that PaC ID would actually mean something static 
and specific for the device itself :). Anyway, PaC ID is not in the
current terminology. The PANA Client definition talks about identity
not about PaC ID. So, we can't use PaC ID, if we don't clarify it!
And eventually we are talking about the same issue here: identity.

Just a clarification in the device point of view. Identity can change. 
The same device can be used with different identities (over time). 
So, the nature is dynamic.

I think PANA Client itself is too vaguely identified ("entity").
This creates confusion, because there are users and devices. None 
of these is a PaC directly. User identities and device identifiers
are dynamic, but is PANA assuming that one or both of these is 
static for the PANA _session_? If it is the user identity, it 
must be the same all the time (during the session), which again 
is an implicit requirement for the protocol. If we are assuming 
static DI, we are restricting too much.

> 
> [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
> > "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.
> 
> I'd not get into session id in the requirements draft.

"Protocol for Carrying Authentication for Network Access (PANA)
Requirements and _Terminology_".

> 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......)

Didn't we already agree about the session-id AVP. See Issue6:
http://danforsberg.info:8080/pana-issues/issue6

OK, here goes another suggestion:

  PAA MUST be able to create a binding between the PaC identity 
  and the associated DI upon successful PANA exchange. For each 
  session PaC's DI is delivered for PAA and bound to the PANA 
  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 PANA session.

Eventually we are talking about sessions, since we have reauth 
messages and a PANA SA.. so there should be a term that clarifies 
this, "PANA session". Then we should clarify also the lifetime 
of the session and lifetime of the SA.. and how to identify the
session.

I created an issue about this too:
http://danforsberg.info:8080/pana-issues/issue13

> 
> 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.

I assume you mean PaC identity and device ID (DI).

How do you create this binding if both are changing? What is the 
relationship between the session then.. and session-id.. and where
do you bind the SA and session lifetime..

- Dan

> Alper
> > - Dan

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 May 2003 11:31:20 -0700

> Mutual authentication between PaC and AS is different than

Either PaC has a direct trust relation with the PAA, or an indirect one
(such as PaC trusts AS which trusts PAA). Either way, at the end PaC and PAA
are mutually authenticated to each other.

> is out of the scope of PANA.

Yes, and this implicit requirement is for AAA to deal with. It is already
there, this is how PPP and 802.1X, and Mobile IPv4 all work today. PANA is
not doing anything new or fundamentally different in this respect (and this
is a feature not a bug :)

> http://danforsberg.info:8080/pana-issues/issue13

Please see my above response.

> And eventually we are talking about the same issue here: identity.

OK, I see we should add PAC ID in the terminology. Do you have suggested
text?

> static for the PANA _session_?

At least PAC ID is static. Is device ID static? Well, we are discussing this
on another thread. But does this matter for the requirements draft?

> If it is the user identity, it

That does not mean we'll fold every terminology we run into in the solutions
draft back into the requirements draft. Requirements draft states what the
protocol should do, and in order to do that it provides guidelines. It is
not meant to be a mirror image of the solution at hand.... Actually,
evolving the requirements draft based on the solution is not a good idea.

> http://danforsberg.info:8080/pana-issues/issue6

Again, agreeing that we'll have X in the solution does not mean that we'll
go back and update the requirements draft accordingly.

> http://danforsberg.info:8080/pana-issues/issue13

PANA SA and pana session ID might be the results of following the
requirements, but that does not mean that they have to be stated in the
requirements. Again, I see this as backwards pulling them into the
requirements draft.

The important point is: people can develop the PANA protocol without the
requirements draft stating what is session ID and PANA SA. That means,
requirements draft is sufficient. Do you think we are missing anything if we
don't mentioned these abstractions in the requirements draft?

> do you bind the SA and session lifetime..

Good questions but these should be discussed in the "solutions" draft, not
the requirements draft.

Alper