Subject: [eap] Proposed resolution to Issue 122: Clarification of LL requirements

From: [email-masked] (Bernard Aboba)
Date: Tue, 6 May 2003 10:58:18 -0700 (PDT)

The text of Issue 122 is given below. The proposed resolution is to change
a paragraph within Section 3.1 from:

"As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g. wired PPP
or IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided.
Where keying material for the lower layer ciphersuite is itself
provided by EAP, typically the lower layer ciphersuite cannot be
enabled until late in the EAP conversation, after key derivation
has completed. Thus it may only be possible to use the lower
layer ciphersuite to protect a portion of the EAP conversation,
such as the EAP Success or Failure packet."

To:

"As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g. wired PPP
or IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided.

Where keying material for the lower layer ciphersuite is itself
provided by EAP, ciphersuite negotiation and key activation is
controlled by the lower layer. In PPP, ciphersuites are negotiated
within ECP so that it is not possible to use keys derived from
EAP authentication until the completion of ECP. Therefore an
initial EAP exchange cannot protected by a PPP ciphersuite,
although EAP re-authentication can be protected.

In IEEE 802 media, key activation also typically occurs after
completion of EAP authentication, so that while an EAP
re-authentication or pre-authentication exchange can be
protected by a lower layer ciphersuite, an initial EAP
exchange typically cannot be."

Comments?

---------------------------------------------------
Issue 122: Clarification of LL requirements
Submitter name: Mohan Parthasarathy
Submitter email address: [email-masked]
Date first submitted: May 2, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-May/001121.html
Document: EAP-02
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:

In section 3.1, Lower layer requirements,

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g. wired PPP
or IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided.
Where keying material for the lower layer ciphersuite is itself
provided by EAP, typically the lower layer ciphersuite cannot be
enabled until late in the EAP conversation, after key derivation
has completed. Thus it may only be possible to use the lower
layer ciphersuite to protect a portion of the EAP conversation,
such as the EAP Success or Failure packet.

I have couple of questions.

1) How do you delay the EAP success packet so that it can be
protected ? For example, if you are using ECP, you should have
reached the IPCP negotiation phase. But IPCP has not begun until EAP
success packet is transmitted. right ? what am I missing ?

2) Under what conditions the EAP failure packet can be protected ?
Doesn't failure imply that key has not been derived ?

[Pasi Eronen]

I think the draft is misleading here: as far as I know (please correct
me if I'm wrong :), existing lower layers that use EAP transmit the
EAP success packet unprotected, and enable the ciphersuite only after
that.

If this is indeed the case, I suggest we the text to:

  "... When keying material for the lower layer ciphersuite is itself
   provided by EAP, typically the lower layer ciphersuite is enabled
  only after the EAP conversion has concluded. Thus, the EAP conversation
  itself is usually not protected."

[BA]

Mohan is correct that not all link layers can
permit protection of EAP packets within an
initial authentication. In PPP, ECP
can only begin after authentication has completed
so protection of EAP packets is only possible for
re-authentication.

It would be possible for an EAP Failure to be
protected in re-authentication, or pre-authentication,
where lower layer protection is already in place.
However, for an initial authentication,
given the changes made in Issue 116,
it is now expected that the Success/Failure
packet will match the outcome of the single
authentication method that is run. As a result,
a Failure could only be protected if a key were
derived *and* somehow the peer failed to
authenticate to the authenticator. This could
happen in a protocol such as PEAP.