Subject: [eap] issue 300 (ports)

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Jul 2005 13:47:14 +0300

>
>
>In draft-ietf-eap-keying-06.txt, the definition of "port" is not
>clear.  In fact, the draft talks about peer ports and authenticator
>ports.  On the other hand, there is a definition of "network access
>port" in IEEE 802.1X specification, but I'm not sure the port in the
>eap-keying draft is exactly the same as defined in 802.1X.
>
>Also, can an "authenticator port" be physically separated from the
>authenticator?  I think they can be separated.
>

This does seem to be an issue. I'm not sure we can
define "port" well enough, given the variety of link layers
that use it in different ways.

I went through keying-07 and tried to see if we can avoid
this problem. Most of the text involving ports simply
reminds the reader that multiple physical or virtual ports
may be involved, and the implications to identification.
I don't think this part is problematic, but our definitions
(like in TSKs) should not rely on the term "port". A small
proposed change below.

>   Transient Session Keys (TSKs)
>
>      Session keys used to protect data exchanged between a port of the
>      peer and a port of the authenticator after the EAP authentication
>      has successfully completed.  TSKs are appropriate for the lower
>      layer ciphersuite negotiated between the ports of the EAP peer and
>      authenticator.  Examples of TSK derivation are provided in Appendix
>      D.

s/between a port of the peer and a port of the authenticator/in a session
between the peer and the authenticator/

>    Session-ID
>
>       The Session-ID uniquely identifies an EAP session between an EAP
>       peer (as identified by the Peer-ID) and server (as identified by
>       the Server-ID).  The EAP Session-ID consists of the concatenation
>       of the Expanded EAP Type Code (including the Type, Vendor-ID and
>       Vendor-Type fields defined in [RFC3748] Section 5.7) and the
>       Method-ID.  The inclusion of the Expanded Type Code in the EAP
>       Session-Id ensures that each EAP method has a distinct Session-ID
>       space.  Since an EAP session is not bound to a particular
>       authenticator or specific ports on the peer and authenticator, the
>       authenticator port or identity are not included in the Session-Id.

This seems OK.

>    EAP is typically deployed in order to support extensible network
>    access authentication in situations where a peer desires network
>    access via one or more authenticators.  Since both the peer and
>    authenticator may have more than one physical or logical port, a
>    given peer may simultaneously access the network via multiple
>    authenticators, or via multiple physical or logical ports on a given
>    authenticator.  Similarly, an authenticator may offer network access
>    to multiple peers, each via a separate physical or logical port.  The
>    situation is illustrated in Figure 3.

This seems OK too.

> [2]  Entity Naming.  A basic feature of a Secure Association Protocol is
>      the explicit naming of the parties engaged in the exchange.
>      Explicit identification of the parties is critical, since without
>      this the parties engaged in the exchange are not identified and the
>      scope of the transient session keys (TSKs) generated during the
>      exchange is undefined.  As illustrated in Figure 3, both the peer
>      and NAS may have more than one physical or virtual port, so that
>      port identifiers are NOT RECOMMENDED as a naming mechanism.

Ok.

>    Absent an explicit binding step within the Secure Association
>    Protocol, the AAA-Key is not bound to a specific peer or
>    authenticator port.  As a result, the peer or authenticator port over
>    which the EAP conversation takes place is not included in the AAA-Key
>    scope.

Ok.

> [e]  Key scope determination.  Since the Discovery phase is handled out-
>      of-band, EAP does not provide a mechanism by which the peer can
>      determine the authenticator identity.  As a result, where the
>      authenticator has multiple ports and AAA-Key caching is supported,
>      the EAP peer may not be able to determine the scope of validity of
>      a AAA-Key.  Similarly, where the EAP peer has multiple ports, the
>      authenticator may not be able to determine whether a peer has
>      authorization to use a particular AAA-Key.  To allow key scope
>      determination, the lower layer SHOULD provide a mechanism by which
>      the peer can determine the scope of the AAA-Key cache on each
>      authenticator, and by which the authenticator can determine the
>      scope of the AAA-Key cache on a peer.

Still OK.

>
>
>    [a] may contain multiple physical ports;
>    [b] may advertise itself as multiple "virtual" authenticators
>        or peers;
>    [c] may utilize multiple CPUs;
>    [d] may support clustering services for load balancing or failover.
>
>    As illustrated in Figure 1, an EAP peer with multiple ports may be
>    attached to one or more authenticators, each with multiple ports.
>    Where the peer and authenticator identify themselves using a port
>    identifier such as a link layer address, it may not be obvious to the
>    peer which authenticator ports are associated with which
>    authenticators.  Similarly, it may not be obvious to the
>    authenticator which peer ports are associated with which peers.  As a
>    result, the peer and authenticator may not be able to determine the
>    scope of the AAA-Key.

Ok...

> Entity Naming
>      The peer and authenticator SHOULD identify themselves in a manner
>      that is independent of their attached ports.

Ok.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Jul 2005 08:51:16 -0700 (PDT)

> between the peer and the authenticator/

I think Yoshi is saying that while EAP keying parameters are not bound to
ports, that the TSKs are.

While this is true in IEEE 802.1X, IEEE 802.11i, and IEEE 802.16, is it
always the case?  As long as replay protection would remain feasible, I
see no intrinsic reason to prohibit the sharing of TSKs between ports of
the same authenticator.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Mon, 18 Jul 2005 16:58:49 -0700

Jari,

> this problem. 

Even though the term "port" is somewhat polluted, can we still come up
with a term for this? Having been involved in few separate discussions
that can really use a well-defined term for such functionality, I think
that'd help EAP users a lot.

Alper

> Most of the text involving ports simply