Subject: RE: Please review

From: <[email-masked]>
Date: Mon, 19 May 2003 10:41:19 +0300

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 16 May, 2003 21:31
> 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.
> 
> 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.
> 
> > 
> > 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.
> 
> 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 :)
> 
> >>> 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
> 
> Please see my above response.

Actually this issue is related to security threats document, so I 
changed the document in the issue, huh.

You're making assumptions about the backend that fulfill the requirments
for the protocol that doesn't contain the backend?!... At least we should 
say what are the assumptions (features needed). It's not a good reason to
say that existing protocols do like this or like that or that there are 
features.

I'm not saying that we should do mutual auth. between PaC and PAA without
any backend support. But it's possible that PaC mutually authenticates AS 
and PAA authenticates AS, but AS doesn't authenticate PAA. For example 
think about the scenario with NAP and ISP.

> 
> > 
> >> 
> >>> 
> >>> 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.
> 
> OK, I see we should add PAC ID in the terminology. Do you 
> have suggested
> text?

Maybe you have, since you used the term in the first place? I don't know
what it is. EAP uses term identity, though.

> 
> > 
> > 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_?
> 
> 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?

Relates to the term "session". But I'll change the document type for 
this issue, so that the requirements draft gets through..

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

It would have been better not to use the "Terminology" word in 
the title, though. Almost every draft has a terminology section, 
but it's not mentioned in the title..

> 
> > 
> >> 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
> 
> Again, agreeing that we'll have X in the solution does not 
> mean that we'll
> go back and update the requirements draft accordingly.

I didn't say that.

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

I changed the document type for the issue.

> > 
> >> 
> >> 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..
> 
> Good questions but these should be discussed in the 
> "solutions" draft, not
> the requirements draft.

How about saying something about the dynamicity of the identity or 
device ID in the requirements.. or better using the term session..

- Dan

> Alper
> > - Dan
> >> Alper
> >>> - Dan

---

From: Alper Yegin <[email-masked]>
Date: Mon, 19 May 2003 12:05:39 -0700

> think about the scenario with NAP and ISP.

PAA and AS must be able to authenticate each other. Otherwise, a rogue PAA
can insert itself in the communication. This is a simple AAA requirement.
But, this is not coming from PANA, it is not PANA specific. We don't have to
describe or lay out the requirements of what AAA does. These are well-known.
We need to identify new ones if PANA expects additional features (I hope it
does not, I'm not aware of any).

I don't see how NAP/ISP makes a difference.

> but it's not mentioned in the title..

Good point. I think this is the source of confusion. I should be able to
remove it from the title.

> device ID in the requirements.. or better using the term session..

I don't think we need to have these as formal requirements.

Alper