Subject: requirements comments

From: Alper Yegin <[email-masked]>
Date: Sun, 11 May 2003 00:48:28 -0700

.. and these are Derek Atkins' comments on the PANA requirements draft.

Alper

---

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

> Abstract
> 
> You do realize that PPP uses EAP, which is also the basis for
> 802.1x?  That means that the authentication method (EAP)
> is already agnostic to the link layer in use.  This implies
> that your basic assumption about the problem is flawed.  Could
> you please explain how PANA is different?

You are right that EAP is link-layer agnostic. But there needs to be a
transport for EAP to be used on a network. The current EAP transports are
link-layer specific. PANA is developing a link-layer agnostic transport for
EAP.

> 1. Introduction
> 
> You specifically state in the introduction that:
> 
>  The Working Group will not invent new security protocols and
>  mechanisms but instead it will use the existing mechanisms. In
>  particular, the Working Group will not define authentication
>  protocols, key distribution or key agreement protocols, or key
>  derivation.
> 
> So I'm wondering why EAP is not sufficient?  You do not answer this
> question.  Why can't you just use EAP?  What is missing from EAP that
> you need something different (or in addition)?  If nothing else, could
> you please add at least one paragraph (or better, at least a couple
> paragraphs) that answer these questions?

EAP is already part of the protocol here. PANA carries EAP. PANA is the
transport for EAP, which makes EAP available on any IP network.

This is covered more on the Problem Statement and Usage Scenarios draft
draft-ietf-pana-usage-scenarios-06.txt which we referenced from this
requirements draft.

> 4.1.2. Authorization, Accounting and Access Control
> 
> The requirements seriously limit what you're doing.  How is
> requiring a boolean access-control decision different than what
> RADIUS provides?

Good point. We need to elaborate on this. What is outside scope is
developing an extensive protocol that allows negotiation of authorization
parameters between the client and the network. But, today when your client
is authenticated, the AAA backend can send a long list of authorization
parameters to the access network. That is fine. To the client this looks
like a boolean result (either authorized or not), but to the access network
there are many more parameters supplied by the AAA backend.

> 4.1.4. Identifiers
> 
> You state:
> 
>  The DI MUST be carried
>  either explicitly as part of the PANA payload, or implicitly as the
>  source of the PANA message, or both.
> 
> A word of caution.. If you carry the id in the payload you MUST
> verify the correctness of that identity.  You cannot just believe it;
> the id must be authenticated, not asserted.  Also, if you have a
> multi-step protocol and the identity is authenticated in one step,
> you must not assume that an identity provided in a later step is
> also authenticated; you must re-check any explicit identity against
> one that was already authenticated.
> 
> Case in point is the recent M$ passport flaw: the identity of the user
> was explicit, but it was not checked by the system.

OK.

> 
> 
> 4.5.2. Disconnect Indication
> 
> This section is inconsistent with the PANA Threats document.  I like
> this version better :)

OK.

> 
> 
> 4.9.3. Location Privacy
> 
> Can you define Location Privacy?  I realize it's out of scope, but
> what is it?

Hmmm... I think what we should cover here is "identity protection", not
"location privacy". I'd re-write this section as:

4.9.3. Identity Protection

Some clients might prefer hiding their identity from visited access networks
for privacy reasons. Providing identity protection for clients is outside
the scope of PANA. Note that some authentication methods may already have
this capability. Where necessary, identity protection can be achieved by
letting PANA carry such authentication methods.

Alper