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

From: Brian Weis <[email-masked]>
Date: Tue, 25 May 2010 16:19:04 -0700

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

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 May 2010 15:21:15 +0300

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:
> 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.
>
> 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.
>
> 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."
>
> 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.
>
> 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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 May 2010 14:30:47 -0400

>>>>> "Yaron" == Yaron Sheffer <[email-masked]> writes:

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

I've agreed to take over editorship of draft-ietf-emu-chbind.  My role
in this is part of a larger client engagement.  Currently, I'm schedule
to write up my understanding of some open issues with this document
including a discussion I had with Glenn at the last IETF in early June
and to get a new draft out by the cutoff.

One of the specific discussions that came up was the importance of
making sure we have a consistent strategy across EAP methods for
including channel binding values.  I'll be happy to take a look at EKE
when I take a look at other methods for the emu-chbind update.