[Emu] draft-ietf-emu-tls-eap-types-06 comments

[Heikki Vatiainen <[e-mail]>]

Please find below my comments. I think the draft can move forward. The
comments below are clarifications and minor fixes. The list is quite long
but I think there aren't any functional changes.


Naming things
+++++++++++
Should the EAP type names named consistently? For example, always use
EAP-FAST and EAP-TTLS because those are the IANA registered names. PEAP and
TEAP already use just one form.

Using 'EAP peer', and when unambiguous, 'peer', as much as possible: now
the draft uses also 'client' and 'supplicant' sometimes. Client should
remain when the discussion is about general TLS client behaviour, though.

Similarly 'EAP server' could be used sometimes to clarify which server is
discussed.


2.3 FAST (change to EAP-FAST)
+++++++++++++++++++++++++
Typo: resumptuion


2.4 TTLS (change to EAP-TTLS)
+++++++++++++++++++++++++
Paragraph 2: Incorrect case: 'Ms-CHAP'

Paragraph 3 starts with 'When PAP or CHAP are used ..'. I think this should
also include MS-CHAP because it works similarly to CHAP. MS-CHAP-V2 has an
extra round trip because of -V2 part, but I don't think MS-CHAP differs
from CHAP apart from password change. I'd say the typical case is that
MS-CHAP and CHAP get terminated similarly. Their definitions in EAP-TTLS
RFC are very similar too.

Paragraph 3: first instance of 'server' is clearer as 'EAP server'. Change
to '... opportunity for the EAP server to send ...'.

Paragraph 3: '... response from the EAP peer MUST ...'. Change 'EAP peer'
to 'EAP server'.

Paragraph 4 starts as 'Where TLS session tickets are enabled, the response
from the EAP peer ...'. The response is from 'EAP server', not 'EAP peer'.

Paragraph 5, first sentence: '.. EAP peers always send ...'. Change 'EAP
peers' to 'EAP servers'.

Paragraph 5: The second sentence in the draft is shwn below with my
suggested text following:
'When the supplicant attempts to use the ticket, the peer can simply
request a full reauthentication.'
'When the EAP peer attempts to use the ticket, the EAP server can simply
request a full authentication.'
This clarifies naming, roles and simply says 'authentication' because it's
not going to be reauthentication any longer.

Paragraph 6 starts with 'Supplicants MUST continue ...'. Change
'Supplicants' to 'EAP peers'.

Paragraph 6, second sentence: change 'PAP or CHAP' to 'PAP, CHAP or
MS-CHAP'. Same reason as with paragraph 3.


2.5 PEAP
+++++++
Paragraphs 1 and 2 in the draft are shown below followed by suggested
version:

   When PEAP uses crypto binding, it uses a different key calculation
   defined in [PEAP-MPPE] which consumes inner method keying material.
   The pseudo-random function (PRF+) used here is not taken from the TLS
   exporter, but is instead calculated via a different method which is
   given in [PEAP-PRF].  That derivation remains unchanged in this
   specification.

   However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which
   is defined as:


   When PEAP uses crypto binding, it uses a PEAP-specific key derivation
   defined in [PEAP-MPPE] which consumes inner EAP method keying material.
   The pseudo-random function (PRF+) used in [PEAP-MPPE] is not TLS
   exporter, but it is a different function which is
   given in [PEAP-PRF].  That function remains unchanged in this
   specification.

   The pseudo-random function (PRF+) uses a PEAP Tunnel Key [PEAP-TK] which
   is defined as:

The idea is to clarify what 'here' refers to (PEAP-MPPE) and to use
'derivation' instead of 'calculation' for matching terminology. My
understanding that 'different' means 'different than what is specified
section 2.1 in this draft', therefore it was switched to PEAP-specific to
be clear what it refers to. Attempt is also made to clarify that what
remains unchanged is 'PRF+' function. Term 'method' is used just once so
that PRF calculation method won't be confused by 'inner EAP method'.

Paragraph 3 starts with "We note that this text does not define
Key_Material". Change 'this text' to '[PEAP-TK]' to clarify that 'this
text' does not refer to this draft.


3 Application data
++++++++++++++
The draft says:

   The NewSessionTicket message SHOULD also be sent along with other
   application data, if possible.  Sending that message alone prolongs
   the packet exchange to no benefit.

I fully agree with the above. Experimenting shows that, for example,
eapol_test from wpa_supplicant supports a lone NewSessionTicket message by
sending back an PEAP ack when it receives just the tickets instead of
EAP-Identity/Request+keys after TLS handshake completion. However, another
EAP peer implementation responds nothing and stops the authentication
process when it receives just a NewSessionTicket message without the
expected EAP-Identity/Request.

To summarise, in addition to prolonging the packet exchange, it can also
lead to non-interoperable implementations. Seems that the smallest number
of messages allowed by the TLS and EAP method specifications is the way to
go. Not just with PEAP but with other EAP methods too.


3.1 Identities
++++++++++
Paragraph 5 'Implementation MUST NOT ...' has lower case 'eap'. Change to
'EAP'.

Paragraph 7 'In general, routing identifiers' has repeated a 'with with'.
Change to 'with'.


4. Resumption
+++++++++++
The paragraph in the draft could benefit from a small sentence reordering
and rewording. The original is followed by the suggested version:

   Note that if resumption is performed, then the EAP server MUST send
   the protected success result indicator (one octet of 0x00) inside the
   TLS tunnel as per [RFC9190].  If either peer or server instead
   initiates an inner tunnel method, then that method MUST be followed,
   and resumption MUST NOT be used.  The EAP peer MUST in turn check for
   the existence the protected success result indicator (one octet of
   0x00), and cause authentication to fail if that octet is not
   received.

   Note that if resumption is performed, then the EAP server MUST send
   the protected success result indicator (one octet of 0x00) inside the
   TLS tunnel as per [RFC9190].  The EAP peer MUST in turn check for
   the existence the protected success result indicator (one octet of
   0x00), and cause authentication to fail if that octet is not
   received.  If either peer or server instead
   initiates an inner tunnel method, then that method MUST be followed,
   and inner authentication MUST NOT be skipped.

The rewording changes 'resumption MUST NOT be used' to what's shown above.
My understanding is that if TLS resumption is done, then the choice is
either to:
- use protected success result indication 0x00; or
- do full inner authentication; but not both


6. Security Considerations
++++++++++++++++++++
The last sentence of paragraph 3 is shown below with the suggested change
following:

   However, the TLS protocol may send one or more NewSessionTicket after
   receiving the TLS Finished message from the client, and therefore
   before the user is authenticated.

   However, the TLS protocol may send one or more NewSessionTicket messages
after
   receiving the TLS Finished message from the EAP peer, and therefore
   before the user is authenticated.

The changes add 'messages' and change 'client' to 'EAP peer'.

The next paragraph ends with these two sentences. The suggested sentences
follow:

   Malicious clients can begin a session and receive a
   NewSessionTicket.  The malicious client can then abort the
   authentication session, and the obtained NewSessionTicket to "resume"
   the previous session.

   Malicious EAP peers can begin a session and receive a
   NewSessionTicket.  The malicious EAP peer can then abort the
   authentication session, and use the obtained NewSessionTicket to "resume"
   the previous session.

The changes use 'EAP peer' instead of 'clients' and add missing verb 'use'.


6.1 Protected Success and Failure indicators
++++++++++++++++++++++++++++++++++
Paragraph 5 says '... TTLS with inner PAP or CHAP.'. I'd change the inner
protocols to 'PAP, CHAP or MS-CHAP'.

Paragraph 7 says '... do not provided protected ...'. Change 'provided' to
'provide'.

Paragraph 7 also suggests replacements for PAP and CHAP to ensure protected
indicators can be used. A replacement for MS-CHAP could be EAP-MSCHAP-V2 or
possibly EAP-MD5?


8. References
+++++++++++
[PEAP-MPPE], [PEAP-PRF] and [PEAP-TK] point to different parts of [MSPEAP].
It might be useful to clarify that this is the case in order to minimise
the problem with broken links.


--
Heikki Vatiainen
[e-mail]