Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10

Sam Hartman <hartmans-ietf@mit.edu> Fri, 14 May 2010 18:51 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BCA3A68FC; Fri, 14 May 2010 11:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.373
X-Spam-Level:
X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MRhU7AYv8q8; Fri, 14 May 2010 11:51:28 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C3E053A687E; Fri, 14 May 2010 11:51:27 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 77048201CA; Fri, 14 May 2010 14:51:16 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 983CC43EE; Fri, 14 May 2010 14:51:14 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Tom Yu <tlyu@MIT.EDU>
References: <ldvaasggrzf.fsf@cathode-dark-space.mit.edu> <p0624084cc805e21f05f7@[10.20.30.158]> <ldvk4rhk9de.fsf@cathode-dark-space.mit.edu>
Date: Fri, 14 May 2010 14:51:14 -0400
In-Reply-To: <ldvk4rhk9de.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of "Wed, 05 May 2010 23:16:29 -0400")
Message-ID: <tslfx1uqpul.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: secdir@ietf.org, ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, iesg@ietf.org
Subject: Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2010 18:51:29 -0000

>>>>> "Tom" == Tom Yu <tlyu@MIT.EDU> writes:

    Tom> Paul Hoffman <paul.hoffman@vpnc.org> writes:
    >> At 1:23 AM -0400 5/4/10, Tom Yu wrote:
    >> 
    >>> The lengthy paragraph warning about non-key-generating EAP
    >>> methods is mostly unchanged from RFC 4306.  I do wonder if
    >>> channel bindings would help with non-key-generating EAP methods
    >>> tunneled in protected channels, but am not sufficiently familiar
    >>> with EAP to know whether this is feasible.  (non-key-generating
    >>> EAP methods might not have any way to perform the additional
    >>> necessary authentication to achieve channel binding)
    >> 
    >> Channel bindings might or might not help here, depending on the
    >> current precise definition of "channel bindings". Trying to wind
    >> this into a bis document didn't seem prudent, given the loose
    >> state of the definition.

    Tom> I just checked, and RFC 5056 ("On the Use of Channel Bindings
    Tom> to Secure Channels") deliberately chose to exclude EAP channel
    Tom> bindings from its recommendations due to the difficulty of
    Tom> meaningfully identifying the lower-level channel over which EAP
    Tom> runs.

OK, so remember that there are two different definitions of channel
bindings: EAP channel bindings and RFC 5056 channel bindings.  If you
don't know the difference, giving up now for this discussion would
probably be reasonable:-) 

EAP channel binding could be used to provide RFC 5056 channel binding
for the IKE session, assuming that you could define an RFC 5056 channel
binding data appropriate to a under-negotiation IKE session.  However,
i'm unaware of any EAP methods that do or could easily be made to
support EAP channel binding that do not produce a key.

It would be possible to use RFC 5056 channel binding (or something like
it) to bind an EAP method that did not produce a key to the IKE session
if that method produced something similar to channel binding data.
No EAP methods today do this: why not make them produce a key instead if
you were going to manage to make such a change.

In conclusion, I don't think that RFC 5056 or EAP channel binding have
much to add to EAP methods that produce no key.