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

From: [email-masked] (Mohan Parthasarathy)
Date: Tue, 6 May 2003 13:23:11 -0700

Bernard,

>=20
> The text of Issue 122 is given below. The proposed resolution=20
> is to change
> a paragraph within Section 3.1 from:
>=20
> "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."
>=20
> To:
>=20
> "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.
>=20
> 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,
                             ^ be
> although EAP re-authentication can be protected.
>=20

> 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."
>=20

One possible rephrasing to match the one above..

In IEEE 802 media, key activation also typically occurs after
completion of EAP authentication. Therefore an initial EAP exchange=20
cannot be protected by lower layer ciphersuite, although an EAP
re-authentication or pre-authentication exchange can be protected.

Re-authetnication and pre-authentication are not defined ? Does
it matter ?

-mohan
 =20
>=20

> Comments?
>=20
> ---------------------------------------------------
> 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:
>=20
> In section 3.1, Lower layer requirements,
>=20
> 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.
>=20
> I have couple of questions.
>=20
> 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 ?
>=20
> 2) Under what conditions the EAP failure packet can be protected ?
> Doesn't failure imply that key has not been derived ?
>=20
> [Pasi Eronen]
>=20
> 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.
>=20
> If this is indeed the case, I suggest we the text to:
>=20
>   "... 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=20
> conversation
>   itself is usually not protected."
>=20
> [BA]
>=20
> 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.
>=20
> 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.
>=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>=20