Subject: [eap] WG last call issue: EAP-04 editorial nits

From: [email-masked] (Henrik Levkowetz)
Date: Tue, 17 Jun 2003 19:30:28 +0200

Submitter name: Henrik Levkowetz
Submitter email address: [email-masked]
Date first submitted: June 17, 2003
Document: EAP-04
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of issue:

Section 1.3:

   "Acknowledged result indications
             The ability of the authenticator to provide the peer with
             an indication of whether the peer has successfully
             authenticated to it, and for the peer to acknowledge
             receipt, as well as providing an indication of whether the
             authenticator has successfully authenticated to the peer.
             Since EAP Success and Failure packets are neither
             acknowledged nor integrity protected, this claim requires
             implementation of a method-specific result exchange that is
             authenticated, integrity and replay protected on a
             per-packet basis."

s/authenticated, /authenticated and/

Section 2.2:

   "EAP packets with codes of Success or Failure do not include a Type,
   and therefore are not delivered to an EAP method.  Success and
   Failure are discussed in Section 4.2."

s/and therefore/and/
(- I don't see an immediate logic, so I'd rather just state the rule here.)

Section 3.1:

   "[1] Unreliable transport.  In EAP, the authenticator retransmits
       Requests that have not yet received Responses, so that EAP does
       not assume that lower layers are reliable.  Since EAP defines it
       own retransmission behavior, when run over a reliable lower
       layer, it is possible (though undesirable) for retransmission to
       occur both in the lower layer and the EAP layer."

Awkward. Rewrite last part to: "Since EAP defines its
own retransmission behavior, it is possible (though undesirable)
for retransmission to occur both in the lower layer and the EAP
layer when EAP is run over a reliable lower layer."

...

       "After EAP authentication is complete, the peer will typically
       transmit data to the network via the authenticator.  In order to
       provide assurance that the peer transmitting data is the same
       entity that successfully completed EAP authentication, the lower
       layer needs to bind per-packet integrity, authentication and
       replay protection to the original EAP authentication, using keys
       derived during EAP authentication.  Alternatively, the lower
       layer needs to be physically secure.  Otherwise it is possible
       for subsequent data traffic to be hijacked, or replayed."

s/hijacked,/hijacked/

...

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

s/by lower layer/by the lower layer/

Section 4.1:

      "Retransmitted Requests MUST be sent with the same Identifier value
      in order to distinguish them from new Requests. The contents of
      the data field are dependent on the Request Type.  The peer MUST
      send a Response packet in reply to a valid Request packet.
      Responses MUST only be sent in reply to a valid Request and never
      retransmitted on a timer."

s/The contents of the data field are/The content of the data field is/

Section 5.3.2:

   "Length

      >=40"

Is my math off today? I count the length to 20 octets or more, not 40 or more.
s/40/20/

...

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     2         |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=254    |                0 (IETF)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                3 (Nak)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=254    |                0 (IETF)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                5 (OTP)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=254    |                20 (MIT)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                6                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

s/Length/Length=28/

      An Expanded Nak Response indicating a no desired alternative would
      appear as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     2         |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=254    |                0 (IETF)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                3 (Nak)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=254    |                0 (IETF)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                0 (No alternative)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

s/Length/Length=20/

Section 5.7:

      "The Expanded Type is also used to expand the global Method Type
      space beyond the original 255 values.  A Vendor-Id of 0 maps the
      original 255 possible Types onto a namespace of 2^32-1 possible
      Types, allowing for virtually unlimited expansion. (Type 0 is only
      used in a Nak Response, to indicate no acceptable alternative)"

s/namespace/number space/
s/, allowing for virtually unlimited expansion//
(the last part of the sentence, while true, is maybe too much
elaborating the obvious?)

Section 7.4 Man-in-the-middle attacks: 

   "As noted in Section 2.1, EAP does not permit sequences of
   authentication methods.  Were a sequence of EAP authentication
   methods to be permitted, the peer might not have proof that a single
   entity has acted as the authenticator for all EAP methods within the
   sequence.  For example, an authenticator might terminate one EAP
   method, then forward the next method in the sequence to another party
   without the peer's knowledge or consent.  Similarly, the
   authenticator might not have proof that a single entity has acted as
   the peer for all EAP methods within the sequence.

   This enables an attack by a rogue EAP authenticator tunneling EAP to
   ..."

s/This enables/Tunnelling EAP within another protocol enables/

Section 7.6:

   "Where EAP runs over lower layers which are not physically secure, in
   order to protect against dictionary attacks, an authentication
   algorithm resistant to dictionary attack (as defined in Section 7.2)
   SHOULD be used."

Rewrite as: 
"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not
physically secure."

   "If an authentication algorithm is used that is known to be vulnerable
   to dictionary attack, then the conversation may be tunneled within a
   protected channel, in order to provide additional protection.
   However, as noted in Section 7.4, EAP tunneling may result in a
   man-in-the-middle vulnerability, and therefore dictionary attack
   resistant methods are preferred."

s/channel,/channel/

Section Appendix B. Changes from RFC 2284:

Add: 
"o In sections 5, 5.1 and 5.2, requirements has been added
that fields with displayable messages should contain UTF-8
encoded ISO 10646 characters."