Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-06

[Yaron Sheffer <[e-mail]>]

Hi Brian,

thanks for your review. I accept all of your comments, with the 
exception of the last one: I consider channel binding as an important 
capability, which implies that it needs to be provided in an 
interoperable manner. There is no standard set of channel binding 
properties yet, but I expect that eventually we will have one. 
http://tools.ietf.org/html/draft-clancy-emu-aaapay-04 presents one 
viable direction for doing that, and I have asked the authors of that 
draft to add a section that describes how their proposal can integrate 
with EAP-EKE. In other words, the Channel Binding Value payload should 
not be seen as a "vendor ID", but rather as a placeholder for a 
standardized solution.

Thanks,
	Yaron

On 05/26/2010 02:19 AM, Brian Weis wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This document describes a new EAP method based on the Encrypted Key
> Exchange (EKE) protocol. The well-defined EKE exchange is preceded by a
> new crypto policy negotiation exchange, several of the payloads are
> protected by authenticated encryption, and a cryptographic confirmation
> that both the server and peer have seen identical messages has been added.
>
> The document and Security Considerations are comprehensive, and I see no
> issues that need to be addressed. I do have the following suggestions
> for improvement.
>
> Section 3.1. The schematic of the EAP-EKE messages (bottom of page 6)
> defines a number of terms for the first time, without explanation. The
> single sentence following it (top of page 7) seems intended to point the
> reader to Section 5 to find those terms. It ought to be a little more
> descriptive. At a minimum, I suggest something like "Section 5 explains
> the various cryptographic values and how they are derived."
>
> Section 5.1. The strength of x_s is significantly determined by the
> choice of randomness method deriving x_s. It seems that a weak source of
> randomness would be a significant implementation flaw for EAP-EKE. This
> section does refer to RFC 4086 for randomness recommendations, which
> should certainly be helpful to implementors. But perhaps also
> referencing some well-known methods (e.g., NIST SP 800-90) would be even
> better.
>
> Section 7.3. The sentence following the table seems to be trying to
> define a PRF as something with a "K" and an "S", but doesn't define what
> those values mean. This should either be clarified, or have the section
> point to a better external definition of a PRF.
>
> Section 7.6. Defining a registry without any standardized values (other
> than a "reserved" value of 0x0) isn't very useful for interoperability.
> If the expectation is that private use values will be mainly used,
> perhaps the channel binding value should be treated as a vendor-id
> payload rather than a registry.
>
> Brian