eap Mailing List: Re: Issue 309: Review

[Bernard Aboba (bernard_aboba]

The issue of the meaning of "lower layer" was also brought up in Issue 320.  
Are those changes sufficient to clarify the issue?

Does the following change address the re-key issue?

In Section 3.2, change:

"  As a result,  while the lifetime of calculated keys can be less than
  or equal that of the exported keys they are derived from, it cannot
  be greater.  For example, TSK re-key may occur prior to EAP re-
  authentication."

To:

" As a result, while the lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot
be greater. For example, when EAP re-authentication occurs, TSK
re-key will also occur. However, this does not prohibit TSK re-key
from occurring prior to expiration of the lifetime of exported keys.
For example, TSK re-key may occur prior to EAP re-authentication."

Here is some additional material on the EAP conversation phases:

Add the following material to Section 2.1:

Existing EAP lower layers implement phase 0, 2a and 2b in different ways:

PPP PPP, defined in [RFC1661] does not support discovery, nor does
it include a Secure Association Protocol.

PPPOE PPPOE, defined in [RFC2516], includes support for a Discovery stage
(phase 0). In this step, the EAP peer sends a PPPoE Active Discovery
Initiation (PADI) packet to the broadcast address, indicating
the service it is requesting. The Access Concentrator replies
with a PPPOE Active Discovery Offer (PADO) packet containing
its name, the service name and an indication of the services
offered by the concentrator. The discovery phase is not secured.
PPPOE, like PPP, does not include a Secure Association Protocol.

IKEv2
IKEv2, defined in [RFC4306], handles the derivation of unicast security
associations (phase 2a), while the derivation of multicast security
associations (phase 2b) is handled in a separate group key management 
protocol,
as described in [RFC4046]. Several mechanisms have
been proposed for discovery of IPsec security gateways.
[RFC2230] discusses the use of KX Resource Records (RRs) for
IPsec gateway discovery. However, while KX RRs are
supported by many DNS server implementations, they have not yet been
widely deployed. Alternatively, DNS SRV [RFC2782] can be used for
this purpose. Where DNS is used for gateway location, DNS security
mechanisms such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and
Simple Secure Dynamic Update [RFC3007] are available.

IEEE 802.11i
IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
Beacon and Probe Request/Response mechanisms. EAP authenticators
periodically announce their service names (SSIDs) as well as
capabilities using Beacon frames. Alternatively, EAP peers
can query for authenticators by sending a Probe Request to the
broadcast address. The 4-way handshake defined in [IEEE-802.11i]
enables the derivation of unicast (phase 2a) and multicast/broadcast
(phase 2b) secure associations. Note that since the group key
exchange transports a group key from the authenticator to the
peer, two 4-way handshakes may be required in order to support
peer-to-peer communications.

IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations.

IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] {need more text.  Any volunteers?}

-----------------------------------------------------------------------------------------------------------
Issue 309: Review
Submitter name: Maryline Maknavicius
Submitter email address: Maryline.Maknavicius [at] int-evry.fr
Date first submitted: 11/09/2005
Reference: http://lists.frascone.com/pipermail/eap/msg03755.html
Document: KEYING-08
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue

Please find hereafter few comments on draft-ietf-eap-keying-08.

1. IMHO the meaning of "lower layer" should be clarified and make consistent
through all the document.
For instance, figure 3 and section 2.3 consider lower layer as including 
AAA,
while figure 4 and associated explanations of section 2.2 consider AAA and 
lower
layers separately.

For instance, this does  not help understanding section 2.4.1 :
"[a] The lower layer MAY specify additional restrictions on key usage,
    such as limiting the use of EAP keying material and parameters on
    the EAP peer to the port over which on the EAP conversation was
    conducted."

where I guess lower layer does not correspond to AAA, but I may have
misunderstood.

To clarify, I think a definition of "lower layers" is needed in section 1.2.

2. In section 2.1, a typical conversation with phases is given with no 
details
on what applies for specific lower layer protocols like IKEv2, PPP, IEEE
802.11i...
However, in section 2.3 (caching), explanations are personalized to each 
lower
layer protocol, giving clues on how this framework should integrate in each
protocol.

I feel like a section (or an appendix) is missing on how this framework 
applies
to current lower layer protocols.

3. Other clarifications needed in section 3.2:
"  As a result,  while the lifetime of calculated keys can be less than
  or equal that of the exported keys they are derived from, it cannot
  be greater.  For example, TSK re-key may occur prior to EAP re-
  authentication."
I do not understand how the last sentence ("TSK re-key may occur prior to 
EAP
re-authentication") illustrates that exported keys have greater/same 
lifetime
than derived keys. Maybe to be removed or better explained.