eap Mailing List

View Index by: Date - Thread - Author
Re: RE: channel binding
From: Yoshihiro Ohba (yohba727hotmail.com)
Date: Thu, 11 Aug 2005 15:05:14 -0400 (EDT) 

From: Nicolas Williams <Nicolas.Williams [at] sun.com>
To: Yoshihiro Ohba <yohba727 [at] hotmail.com>
CC: jsalowey [at] cisco.com, eap [at] frascone.com
Subject: Re: [eap] RE: channel binding
Date: Wed, 10 Aug 2005 14:41:25 -0500

You are correct about this: given an EAP method that provides keying but
not channel (or cryptographic) bindings it should be possible to provide
those elsewhere.

RFC3748 speaks of "a protected exchange of channel properties," but I
don't see how working these properties into key derivation departs from
the spirit of the RFC3748 description.

I.e., I don't see how what you propose is fundamentally new in regards
to EAP channel binding -- what's new in what you propose is to add
components that provide features missing from methods.

I'ts not fundamentally new because the goal is the same, but it's a different approach.


I can't help but be reminded of the stackable pseudo-mechanism notion
that we're working on in the GSS-API context at the KITTEN WG.  That is,
I think it's a good idea -- I would, of course, since I've been
promoting idea of GSS stackable and composite mechanisms ;)

I don't necessarily agree that all methods should be simplified by not
providing optional features that can be provided via composite methods.


I understand your point.

But thinking of the SECMECH BoF GUAM proposal I do agree that the core
of a mechanism could/can/should indeed be specified such that it
provides only the fundamental properties needed and the rest of the EAP
or GSS semantics can then be provided by inclusion or elsewhere.

OK. I think we are reaching some agreement on (please correct if I'm wrong):

- Channel binding mechanism in EAP-IKEv2 should not be removed (but needs some modification to carry a blob in order to avoid the IANA assignment issue.)

- Key-derivation based channel binidng solution should be specified as an extension to EAP keying framework.

Best regards,

Yoshihiro Ohba


Nico
--



Results generated by Tiger Technologies using MHonArc.