Subject: FW: Usage Scenarios I-D - Review comments

From: <[email-masked]>
Date: Tue, 21 Jan 2003 13:46:08 -0600

Review of Pana Usage Scenarios Draft,
<draft-ietf-pana-usage-scenarios-03.txt> dated October 25, 2002.

Reviewed by John Vollbrect <[email-masked]>

Comments.

1. The draft makes a good start at defining a set of possible applications 
for a protocol that supports a standard way of authenticating network 
access.  The list of applications is useful in understanding the range of 
what PANA will be expected to support.  The list is impressive in its scope 
and the knowledge the authors have of requirements and implementations in 
very diverse areas.  In general it seems to be saying that authenticating 
network access is always a good thing, and it should not be necessary to 
reinvent a method to do that for every new media/ link layer that is 
implemented.  I agree.

2. One application not included in the list of applications - and I think 
should be - is network to network connections.  There is some discussion of 
connecting PANs (personal area Networks) to a net, but the concept of 
connecting two large subnets was not addressed. If this is included, it 
will impact some of the naming considerations as well as helping to point 
out the need for mutual authentication between what is now called the 
Device and the PAA.

3. The draft suggests that PANA can be used to support a number of 
applications, but does not say why existing solutions are not useful.  In 
particular, it seems that 802.1x attempts to do much of what PANA is 
describing at the link layer.  While the draft describes overhead for PPP 
as a drawback, it does not address deficiencies in 802.1x that would be 
addressed by PANA.  Perhaps this is ok - PANA may decide to use 802.1x?

4. I think the trust relationships expected in the PANA environment need to 
be clearer.  In particular the relationship between the PaC, the PAA, the 
EP, the Access Point or Access Router and the Device should be described. 
There are a number of relationships that are discussed in the document that 
are possible individually, but without some clearer indication of the model 
for trust relationships that are expected in the PANA environment as well 
as thosed created by PANA protocol transactions, the discussion is hard to 
follow.

5. The assertion is made (p.4) that a network layer transport for EAP would 
be better than PPP because it would not have the PPP overhead.  This may be 
true, but it is not clear to me that a network layer transport would not 
have similar overhead.

6. PANA is suggested as an alternative to WEB based authentication.  My 
understanding of why the HTTPS authentication schemes have been developed 
is that there are no EAP clients universally available to support an 
equivalent user interaction.  Making PaC software available everywhere that 
allowed authentication by prompting the user for id/pw would be very 
popular, but it does not show what PANA provides that existing protocols 
don't or couldn't by extension.  Again this is not a bad thing if PANA 
might choose existing protocols.

7. One of the things I have thought to be a characteristic of PANA goals, 
the ability to authenticate before having a permanent IP address, does not 
seem to be mentioned.

8. The document uses the term "link layer agnostic".  I am not sure what 
this means exactly.  One discussion I have had with some of the PANA group 
indicated that the idea is to force a level 2 connection and then do PANA 
over that.  If this is the idea, it would be better said explicitly.  If 
not, it would be good to say what link layer agnostic means in practice. 
802 is trying to use 802.1x as its link layer agnostic authentication 
protocol.  It also is developing Key Exchange Protocols for establishing 
session keys where necessary.  They are different but related protocols.

Summary/ Recommendation

I think this document provides a good starting point for an architecture 
design group. PANA does have initial architecture with elements like PaC, 
PAA, etc.  I would like to see it also describe trust relationships and 
transactions that create new "access session trust".  If this is not what 
PANA does, then a clearer definition of what PANA will do is needed.

My suggestion is that the applications in this draft be used as the basis 
for a next draft which describes these applications in terms of the PANA 
elements and transactions. Once that is done it would be possible to 
describe specific protocols required to support specific transactions.

There is parallel work being done in a number of places.  For example 
access control protocol work is being done in IEEE 802.1x, 802.11i, and EAP 
working groups.  Some helpful work has been done in the AAAArch Research 
group -  RFCs 2904  and 2905 could be good background material.   PANA 
might provide some architectural support for these groups rather than 
define a new protocol.

In my opinion PANA has staked out an interesting problem space, but has not 
made clear why a new protocol is needed.  The applications described in the 
draft all require authentication and some require access management or 
provisioning.  It is an impressive list, and if it can be shown that a 
single Protocol/architecture could support all of them that would be a 
major step forward.

John Vollbrecht
[email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Jan 2003 21:06:57 -0500

This is my attempt to respond to John Vollbrect's comments.

Thanks,

Yoshihiro Ohba

> reinvent a method to do that for every new media/ link layer that is 

OK.

> out the need for mutual authentication between what is now called the 

In the case of connecting two large subnets, I think the connection is
static in most current usages, so this scenario might be supported by
simply using IPsec tunnel mode with IKE for mutually authenticating
the peering gateways and establishing an appropriate IPsec SA, based
on a shared secret or digital certificates for IKE to be set up when
installing the peering gateways.  So I think PANA might not be useful
for the proposed scenario.

> addressed by PANA.  Perhaps this is ok - PANA may decide to use 802.1x?

Replacing 802.1X is not a goal of PANA, but this does not necessary
mean that PANA may decide to use 802.1X.  This is because (1) IEEE 802
is not the only link layer on which IP is expected to run, and (2)
even in IEEE 802 networks, if 802.1X is not deployed yet but
authentication is somehow needed (the statement is applicable to some
DSL networks), then a protocol like PANA might be useful.  We can
clarify this in the next version of the draft.

> as thosed created by PANA protocol transactions, the discussion is hard to 

I agree.  We will mention the trust relationships expected among
entities related to PANA in the next version.

> true, but it is not clear to me that a network layer transport would not 

If we just consider the overhead of carrying EAP, we might argue "EAP
over IP over link-layer" vs "EAP over PPP over link-layer".  But if we
also consider the overhead of carrying data traffic, "IP over
link-layer" has always less overhead than "IP over PPP over
link-layer".  Does this clarify the point?

> might choose existing protocols.

I think PAA discovery and authentication initiation from PAA is
difficult with using https solely.  It might be possible to use https
to carry EAP but define a new protocol only for PAA discovery.
However, I don't think just running EAP over https is enough.  We
might need to define additional rules such as when TLS connection
needs to shutdown or in which case TLS connection can (or must) be
persistently open, how a device identifier is protected from
man-in-the-middle attack during authentication conversation, as well
as message formats.  But isn't it almost equivalent to define a new
protocol on top of http over TLS rather than extension, and isn't http
just another overhead for carrying EAP?

> the ability to authenticate before having a permanent IP address, does not 

I'm not sure what a permanent IP address exactly mean, but at least a
temporary IP address can be used to autenticate before having a
globally routable IP address.

> session keys where necessary.  They are different but related protocols.

I agree that the term "link layer agnostic" is not clear.  We will
revise the term in the next version.  We will also state that PANA is
to be performed after layer-2 connection is established.

> PANA does, then a clearer definition of what PANA will do is needed.

OK.

> describe specific protocols required to support specific transactions.

I think ongoing work on PANA framework could serve for that purpose.

> might provide some architectural support for these groups rather than 

Please see my above comments on https.

> single Protocol/architecture could support all of them that would be a 

We'll try to reflect all of your comments to make specific points
clearer.

> [email-masked]

Thanks again.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 21 Jan 2003 18:14:05 -0800

Thank you John for your review and comments.
I have some responses inlined below.

> out the need for mutual authentication between what is now called the

This is interesting. The current scheme might be fine as long as
there is a client-master relation between the two networks (like
one is an access network, the other is an mobile network). But
when it's peer-to-peer, this might not be true.

> addressed by PANA.  Perhaps this is ok - PANA may decide to use 802.1x?

We should clarify this better in the draft. 802.1x is not link-agnostic,
as it only runs over IEEE 802 types. PANA is aiming at running over
any link that IP can run.

> as thosed created by PANA protocol transactions, the discussion is hard to

Good point. Discussing the trust relations would help in explaining the
scenarios. 

> true, but it is not clear to me that a network layer transport would not

In cases where PPP is used just as a carrier for authentication, its
presence even after the authentication phase is unnecessary (but you
cannot get rid of it). Carrying EAP above IP won't incur this additional
(and persistent) layer.
 
> might choose existing protocols.

Web based authentication is a temporary solution to the problem, I agree.
People would like to migrate to better solutions from there as they
become available. PANA can be one of the candidates depending on the
scenario. Please note that web based authentication is not only
applicable/used/considered for WLAN. People are considering it (if not
deploying already) even for DSL access when no proper authentication
protocol is present.

> the ability to authenticate before having a permanent IP address, does not

We can mention this, although none of the scenarios is really capturing this
feature.

> over that.  

Assumption is that Layer-2 connection is allowed for a limited access to
enable PANA exchange. This assumption means different things in different
scenarios. for example in DSL scenarios where PANA is needed, subscriber can
already send and receive IP packets. Or in 3GPP2, radio link is already
established. 

> If this is the idea, it would be better said explicitly.  If
> protocol.  

I suspect the scope is important here. 802.1x might be called "link
layer agnostic" with respect to IEEE 802 links, but not necessarily
for all links that IP can run on.

> It also is developing Key Exchange Protocols for establishing

There are clearly some relations between PANA and the above mentioned
components. But I'm not sure if any of them is a substitue for what
PANA is aiming at.

> single Protocol/architecture could support all of them that would be a

For that, we are identifying various scenarios and breaking down the
problem into managable, modular components. Carrying EAP above IP seems
like a common component that is needed by all, and that can satisfy some
scenarios on its own, but not all of the scenarios of course.

alper