Subject: [Emu] Review of draft-simon-emu-rfc2716bis-02

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 7 Jul 2006 22:50:58 -0700

All,
Apologies for such a long delay - this review is long overdue (since I
volunteered to review 01 after Dallas)! 

The draft is mostly in good shape. I have the following
comments/questions on it (I'm trying not to cover the ones that Joe's
comments have already addressed or those that are already under
discussion). 

Technical Comments: 

1. Parts of the draft seem to be written with PPP as the EAP lower layer
in mind (e.g., Fragmentation and certificate revocation text) - given
that EAP is widely used over other lower layers now, there should
probably be some text to support that. 

2. Section 2 refers to client authentication via means other than
certificates. While client authentication is optional in TLS, when
present, isn't it always based on certs? I haven't fully read 4346bis -
perhaps something has changed there. Other TLS-based protocols will be
different EAP methods (and hence, different EAP Types) anyway, right?
So, I'm confused by the text on other peer authentication means. 

3. Towards the end of section 2.1, the following text is present "The
peer will then verify the hash in order to authenticate the EAP server."
A hash cannot be sufficient to authenticate the server. I think the
"verify_data" in the TLS finished message is a PRF - so, I'd imagine
this to be an HMAC? I'd think that either an HMAC or a signature is
required to authenticate the server. 

4. In section 2.1, the following text on server authentication failure
is present: 

"To ensure that the EAP Server receives the TLS alert message, the
   peer MUST wait for the EAP-Server to reply before terminating the
   conversation.  The EAP Server MUST reply with an EAP-Failure packet
   since server authentication failure is a terminal condition."

If the server authentication fails, I am not sure how the server can be
trusted to send an EAP-Failure packet. So, this requirement is confusing
to me. 

5. Some of the text on identity verification in section 2.4 may actually
belong in the security considerations section. For e.g., I'm not sure
what it means to say that a peer "MUST" verify the validity of the
server certificate - this is not an observable on-the-wire behavior and
hence, does not affect protocol interoperability or compliance. The goal
is to ensure good security practice by verifying the validity - it may
make more sense to talk about this in security considerations, rather
than make this a requirement on the protocol. 

6. Section 2.5 shows the MSK split (0-31 and 32-63) and explains the
usage as in RFC2548. As written, it gives the impression that the halves
are always used as described in the text (i.e., RECV and SEND encryption
keys). Since this is not always true (for e.g., no part of the MSK is
directly used for encryption in 802.11i), it would be good to have a
statement about that. 

7. Section 4.6 talks about modifiying the EAP-TLS Type field, thereby
causing a downgrade attack by forcing a different TLS-based EAP method.
I'm not sure why this needs to particularly be another "TLS-based" EAP
method. Isn't the attack on the EAP Type field (that indicates the
packet is EAP-TLS), in which case, the downgrade could potentially be to
any other EAP method (not just TLS-based)? 

Editorial Comments: 

8. Section 2 is titled "Protocol Overview" and section 3 is titled
"Detailed Description of the EAP TLS Protocol" - however, section 3 only
covers the message formats. It looks like Section 2 is the only protocol
description that is available. It would be good to name these sections
appropriately. 

9. A section on differences from RFC2716 would be useful. 

Regards,
Vidya

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu