Subject: FW: Review Request of PANA I-D

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Mar 2003 11:20:29 -0800

Folks,

Here is Pete McCann's review comments.
Thanks Pete, for this thorough review and providing text.

alper

------ Forwarded Message
From: Pete McCann <[email-masked]>
Date: Wed, 12 Mar 2003 16:23:02 -0600
To: [email-masked]
Cc: <[email-masked]>
Subject: Review Request of PANA I-D

Hi,

Here are my comments on draft-ietf-pana-usage-scenarios-04.txt.

General comments:

The document could use a good going-over for grammar and style.

I think the PAN example is not very well motivated.

Specific comments:

Section 1, 2nd paragraph:

Change
   Ability to support multiple
   authentication methods or to perform both network access provider and
   Internet service provider authentication are not available to all
   link-layers.  
To
   However, not all link-layers support multiple authentication
   methods or allow independent authentications for the link access
   and Internet service providers.

Change
   An even higher layer authentication mechanisms are
   needed whenever such additional requirements are not met by the
   underlying link-layers.
To
   A higher layer authentication mechanism is
   needed whenever such additional requirements are not met by the
   underlying link-layers.

Change
   Currently there is not a standard
   protocol to perform network access authentication above link-layer.
To
   Currently there is not a standard
   protocol to perform network access authentication above the
   link-layer.

Section 2

Missing article in:
   Authentication protocol must be able to carry various authentication
   methods regardless of the underlying access technologies.
Change to:
   An authentication protocol must be able to carry various authentication
   methods regardless of the underlying access technologies.

Question on:
   An important aspect of network access is the ability to enable
   dynamic service provider selection.  Regardless of their network
   access provider (NAP), clients should be able to select an Internet
   access provider (ISP) of their choice.
This is a statement applicable to public policy debates, not an IETF
standard.  What is it doing in this document?  Perhaps re-word it to
say "Some deployment scenarios require a separation between network
access provider (NAP) and Internet service provider (ISP)."  Then you
need to define these terms, and state that each entity may require
separate authentication using a different authentication method.

   This is usually achieved by
   clients presenting an identifier which carries domain information
   during the authentication process unless some other link-layer
   specific selectors are used during link establishment.
Do you really need the "unless" part of this sentence?  It distracts
from the point you are trying to make.

I really don't like this paragraph:
   A network-layer authentication mechanism that will support various
   authentication methods can be developed by using a protocol that
   carries EAP [RFC2284bis].  EAP acts as an encapsulation of arbitrary
   authentication methods, but it still requires a transport between the
   client and the access network.  Among all the link-layers, only IEEE
   802 defines how to carry EAP on the link-layer [802.1X].  Any other
   link-layer has to resort to using PPP/PPPoE [RFC1661,RFC2516] as a
   link-layer agnostic way of carrying EAP.  Inserting this additional
   layer(s) between the link-layer and network-layer to achieve this
   goal is an inadequate method.  Using PPP just for client
   authentication incurs extra round-trips, generates overhead of PPP
   processing for data packets, and forces the network topology into a
   point-to-point model.
Suggest re-wording to:
   The Extensible Authentication Protocol (EAP) [RFC2284bis] offers a
   natural way to encapsulate many different authentication methods.
   While embedding of EAP into various link layers has been defined
   elsewhere, e.g., for 802 networks [802.1X] and within PPP
   [RFC1661], EAP could achieve even greater applicability if it could
   be carried directly over IP.  That way, the resulting IP packets
   could be carried over any link technology.  While it is possible to
   use PPPoE [RFC2516] to carry EAP on an Ethernet network, the
   ungainly insertion of an extra layer incurs additional round-trips
   at connection time, generates overhead of PPP processing even for
   subsequent data packets, and forces the network topology into a
   point-to-point model.

Delete this sentence; the point should have been made in the previous
paragraph: 
   It is believed that EAP is a key protocol in supporting
   various authentication methods for network access, and its
   applicability should not be limited to access networks that are using
   IEEE 802 and PPP links.

   PANA can be used over any link-layer that
   does not support EAP encapsulation.
Why limit PANA to only links that don't support EAP?

   PPP might be perceived as a
   link-layer agnostic transport for EAP, but using PPP solely for
   authentication purpose incurs unnecessary cost and imposes additional
   limitations.
This point was already made.  Suggest deleting.

If you accept the 3 prior comments, the remaining single sentence
should be merged with the next paragraph.

Change:
   for the network access purpose.
To:
   for the purpose of network access.

This sentence is awkward:
   Therefore, this authentication might be required to
   generate cryptographic keying material unless presence of a secure
   physical or link-layer channel is assured prior to it.
Suggest deleting the "unless" part.

The comma in the following sentence doesn't belong:
   link-layer ciphers, or IPsec for providing

The following sequence of sentences seem contradictory.  In the first
and second you are talking about how to derive an IPSec SA, in the
third you are saying it is out of scope.  Which is it?
   It should be noted that the keying material produced
   by the authentication methods is generally not readily usable by
   IPsec.  A key exchange protocol like IKE [RFC2409] might be used to
   create the required IPsec security associations.  The mechanisms that
   are used to turn keying material produced by the initial
   authentication method into link-layer or network-layer ciphers are
   outside the scope of PANA.

Change:
   and therefore regarded as a stop-gap
To:
   and therefore is regarded as a stop-gap

Change:
   Mobile IPv4
   [RFC3344] protocol has a built-in authentication mechanism.
To:
   The Mobile IPv4
   [RFC3344] protocol has a built-in authentication mechanism.

Change:
   therefore utilizes Mobile IPv4 protocol for network
To:
   therefore utilizes Mobile IPv4 for network

Section 3

Change:
   The first three subsections describe PANA usage scenarios categorized
   in terms of lower-layer security.  Other subsections describe
   scenarios that are not categorized in terms of lower-layer
   security.
To:
   In this section, the first three subsections describe generic PANA usage
   scenarios categorized in terms of lower-layer security.  The remaining
   subsections describe specific scenarios for Mobile IP, personal
   area networks, and limited free access.

Change:
   In the networks where a certain degree of security is provided at
   physical layer, authenticating the client is still essential since
   physical layer does not provide information on the client, but per-
   packet authentication and encryption may not necessarily be provided
   at higher layers.
To:
   Even in networks where a certain degree of security is provided at
   the physical layer, authenticating the client may still be
   essential if the physical layer does not provide identification
   information on the client.  However, per-packet authentication and
   encryption may not be necessary.

Change:
   In DSL
   networks where PPP or PPPoE is used for both configuration and
   authentication (and IP encapsulation), the providers may not require
   to migrate to use PANA.
To:
   In DSL networks where PPP or PPPoE is used for both configuration and
   authentication, PANA may not be required.

Change:
   A standard,
   link-layer agnostic network access authentication is needed for this
   type of DSL networks and PANA can be used to fill the demand.
To:
   A standard, link-layer agnostic network access authentication would
   be an improvement for this type of network.

Change:
   lower-layer 
To:
   the link-layer

Section 3.2:
Suggest the following re-write (proposals to remove PPP aren't really
going anywhere):

   Certain cellular link-layers such as GSM and cdma2000 provide their
   own authentication mechanisms as well as ciphering of data sent
   over the air interface.  This technology specific authentication
   enables authorization for link access by the NAP, and can provide
   per-packet authentication, integrity and replay protection at the
   link-layer.  However, it does not necessarily provide authorization
   at the network-layer which can only be done by authenticating the
   client to an ISP.  So, this necessitates another layer of
   authentication.  It should be noted that this second authentication
   takes place over a secure channel.

   CDMA2000 is a good example of such an architecture where multi-
   layered authentication for network access takes place.  CDMA2000
   networks require the user/device to authenticate with the MSC/VLR
   before providing access to the packet data network.  The technology
   specific access authentication which uses the CAVE (cellular
   authentication and voice encryption) algorithm also provides cipher
   keys to the mobile and the base station for securing the link layer
   for all subsequent voice and data carried on the air interface.  In
   the Simple IP mode of CDMA2000 service, the ISP authentication is
   provided by using CHAP within PPP.  In the Mobile IP mode of
   CDMA2000, the Mobile IPv4 protocol supports a challenge/response
   style authentication.

   As this architecture evolves, PANA could be supported as a single
   unifying network-layer authentication mechanism.  This would
   replace both CHAP, which would allow for potential evolution of the
   link-layer away from PPP, and Mobile IPv4, which is important
   because Mobile IPv6 does not support the foreign agent concept.

Section 3.3

   Another cause of missing lower-layer
   authentication is due to the difficulty of deployment.  Assuring
   physical security or enabling link-layer security might not be
   practical for various reasons.
The above statements are unsupported assertions.  Can you give some
more specific examples?
This whole paragraph is worded quite awkwardly.  Suggest re-write by a
native english speaker.

Section 3.4
several grammar mistakes here.

Section 3.5

   short range wireless or wireless links would form a PAN.
Assume you mean "wired or wireless"

   Just like any
   access network, a PAN also requires authentication and authorization
   prior to granting access to its clients.
Not necessarily.  My cellphone doesn't need to authenticate my laptop
when I connect over an RS-232 wire.

Section 4 Acronyms should be moved closer to the beginning of the
document.

-Pete

------ End of Forwarded Message

---

From: Alper Yegin <[email-masked]>
Date: Sat, 15 Mar 2003 09:39:20 -0800

Hi Pete,

I agree with your comments, we should update the text accordingly.
Let me respond to few points where you raised questions.

> The above statements are unsupported assertions.  Can you give some

Physical security cannot be practical in all cases. The best example is
wireless access networks. We cannot physically limit hosts' access to the
"link". Building walls around the coverage area and controlling who can get
through the gates is not practicle.

As far as the link-layer security is concerned, even if a reasonable
link-layer security technology is available, operators might not deploy it
for reasons like cost of upgrades, lack of client support, etc. For example,
despite the availability of 802.1x, hot-spot operators are still using
web-based http redirect hackery. The above statement does not claim
deploying PANA is more practical, but this is a decision operators should
make. There might be cases where upgrading to PANA might be more effective
and still provide acceptible level of security.

We should expand on this in the text too.

> Assume you mean "wired or wireless"

Yes.

> when I connect over an RS-232 wire.

OK, this is physical security. As long as you are the one who plugs in the
cables, you are fine. PANs also come with wireless connections.

Thanks Pete.

alper