Subject: Fw: comments on draft-ietf-pana-usage-scenarios-03.txt

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 15 Jan 2003 18:20:24 -0800

I suspect this message didn't appear on the PANA mailing list
because Bernard is not subscribed (?). Anyways, until the problem is fixed,
here is a copy...

----- Original Message -----
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 14, 2003 11:02 AM
Subject: comments on draft-ietf-pana-usage-scenarios-03.txt

> Section 1
>
> "IEEE 802.1x" - the X is capitalized. Also IEEE 802.1X only applies to
> wired IEEE 802 networks. IEEE 802.11i is the standard describing how IEEE
> 802.1X is adapted to use on IEEE 802.11.
>
> "This has the advantage of decoupling the association of
>    authentication from the access technology."
>
> It's not clear to me that this is completely achievable. For
> example, in order to protect against spoofing it's necessary to tie the
> authentication to subsequent data traffic. Where physical security can't
> be assumed, this is done via key derivation and subsequent per-packet
> integrity and authentication. That also implies that transient session
> keys need to be derived for use with an L2 ciphersuite. The details of EAP
> key derivation and transient session key adaptation need to be addressed
> somewhere -- but I haven't seen a discussion anywhere in the PANA
> documents. This could represent a major flaw in the architecture, so I
> think that more attention needs to be paid to nailing this down.
>
> "Binding device identifiers to PANA clients"
>
> It is not clear to me how this is done without either physical security or
> an L2 ciphersuite supporting per-packet integrity and authentication (and
> keys derived from the authentication).
>
> Section 3
>
> "   Access networks which are not physically secured from unintended
>    usage usually require clients to go through an authentication and
>    authorization process."
>
> Even if they are physically secured this is often required. But if they
> are not, then I'd claim that this is not enough -- you need to bind the
> authentication to subsequent data traffic. It's not clear to me in reading
> these documents how this is accomplished.
>
> "An important aspect of an authentication protocol is the ability to
>    provide dynamic service provider selection to the clients."
>
> This isn't part of EAP, since it's assumed that the choice is done out of
> band. For example in IEEE 802.11, the SSID is indicated in the
> Association/Reassociation Request.
>
> "This is
>    usually achieved by clients presenting an identifier which carries
>    domain information during the authentication process."
>
> The choice of identity is not the same as the choice of network to
> connect to, and can't be assumed from it. I could use the same id
> ([email-masked]) to access 3 different networks, all advertised on the
> same access point.
>
> "Support for various authentication methods, including the ones that
>    can provide dynamic service provider selection and roaming can be
>    achieved by using an authentication protocol that can carry EAP
>    [RFC2284]. "
>
> EAP doesn't provide service provider selection.
>
> "  Defining a network-layer transport for EAP would provide a cleaner
>    solution to this problem."
>
> Assuming that the EAP lower layer requirements are met. Please see RFC
> 2284bis-09, Section 3:
>
> http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt
>
> 4.1
>
> "A standard, L2 agnostic network
>    access authentication is needed for this type of DSL networks and
>    PANA can be used to fill the demand."
>
> Or Ethernet Last Mile could be run over the DSL PHY and IEEE 802.1X could
> be used instead. Not sure this scenario is very convincing.
>
> 4.2
>
> "One can enable
>    WEP security to protect the authentication messages."
>
> Not sure what "protect" means here -- WEP has no per-packet authentication
> or integrity protection, just (weak) confidentiality.
>
> 4.3
>
> "   Ethernet links composed of legacy hubs and switches and early
>    deployment of Wi-Fi networks (802.11b) do not use link layer
>    authentication or security mechanisms such as, 802.1X."
>
> IEEE 802.11b does support link-layer authentication -- that's what
> Authentication frames are for. I think you mean that per-packet integrity
> and authentication aren't supported.
>
> Since IEEE 802.1X is typically a firmware upgrade, "legacy" switches are
> indeed supported. Hubs aren't supported, whether legacy or new ones.
>
> "  In such scenarios, a standard network layer solution such as, PANA is
>    suitable since it provides link-layer agnostic network access
>    authentication. "
>
> It isn't clear to me that PANA is suitable for such scenarios unless the
link
> is physically secure, because:
>
> "  Although PANA does not define key distribution protocol or mechanism,
>    it is possible to use PANA to enable per-packet protection mechanism
>    such as, IPsec and WEP, to secure communication in the edge subnet."
>
> Not sure how this can be done if a "key distribution protocol" isn't
> defined. Can you clarify?
>
> Using PANA to key IPsec isn't a good idea. EAP keying doesn't provide the
> facilities required for IPsec keying, such as Phase 2 SA negotiation,
> rekey support, etc.  See:
>
> http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt
>
> "where lower layer authentication and key distribution mechanisms are
>    absent PANA could be very useful."
>
> Since PANA doesn't define key distribution, how is the required
> functionality provided? I'm not clear on this.
>
>
>
>

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 17 Jan 2003 17:57:49 -0800

Thank you Bernard, for the review and useful comments.
Follow up comments inlined below...

> 802.1X is adapted to use on IEEE 802.11.

OK, we shall fix the terminology.

> think that more attention needs to be paid to nailing this down.

Physical security, L2 ciphesuites, and IPsec are the tools
for protecting subsequent data traffic after PANA. Details are
not really suitable for this usage scenarios draft, but yes,
we should capture these at a high level in this document.

> keys derived from the authentication).

There are three types of environments that PANA can be used.
One is where there is physical security. When it is not available,
L2 ciphersuites can be used instead. And in the (worst) case L2
doesn't have that support either, IPsec can be used. We should
capture these better in the document, I agree.

> Association/Reassociation Request.

It isn't really part of EAP, but some uses of EAP relies on
presence of domain information as part of the client identifier.
For example use of EAP with PPP in DSL networks. Subscriber does not
have the facilities to convey its choice of ISP before the authentication,
hence it does so during the authentication. IEEE 802.11 could do the same
(maybe), but it's taking advantage of some L2 features instead.

> ([email-masked]) to access 3 different networks, all advertised on the

It depends on the application of EAP. You are right for IEEE 802.11 links,
but usage of EAP over PPP over DSL lines is different.

> EAP doesn't provide service provider selection.

Yes, we should clarify this..

> http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt

Good point. As far as I can see, our current assumptions are aligned
with these requirements. Do you (or anyone else) see any issues here?

> be used instead. Not sure this scenario is very convincing.

I guess there are multiple alternatives, even including using captive
portal scheme on DSL. Each has pros and cons, various cost/benefit factors.

> or integrity protection, just (weak) confidentiality.

OK, this paragraph is not clear. And at least we should replace WEP
by TKIP/WRAP/AES CCMP.

> indeed supported. Hubs aren't supported, whether legacy or new ones.

OK.

link
> defined. Can you clarify?

PANA should not define its own key distribution/derivation. Instead,
users of PANA should rely on appropriate EAP methods to provide these
functionalities. When needed (i.e., when there is no physical security),
EAP methods that can derive/distribute keys should be used for network
access authentication. And following this initial authentication, L2
ciphersuites (if available), or IPsec should be enabled for authentication
and integrity check of data traffic.

> http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt

The keys provided by an EAP method cannot be readily used with
IPsec. The newly-generated trust relation between the PaC and PAA
needs to be turned into an IPsec SA, and for that IKE can be used.
This sounds like a heavy weight operation, but note that this
is used when there is no L2 ciphersuite available. We should
provide guidelines for how this is done, as well. Maybe in the
form of an informational RFC...

> functionality provided? I'm not clear on this.

We should clarify that this is not accomplished by PANA, but by particular
EAP methods. PANA indirectly enables this by carrying EAP that can carry
such authentication methods.

alper