Subject: RE: [eap] Re: Issue 352: Channel Binding Issue

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 2 May 2006 16:23:22 -0700

Hmmm... 

Peer gets MSK from EAP and mixes it with Y to get MSKY 
Authenticator gets mixed MSKY in exisitng AAA attribute, since this is
an exisitng attribute it thinks it is just the MSK and mixes it with Y
to get MSKYY.  MSKY and MSKYY don't match.

It seems to me a separate attribute would really be better. 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, May 02, 2006 3:58 PM
> To: [email-masked]; Salowey, Joe
> Cc: [email-masked]
> Subject: Re: [eap] Re: Issue 352: Channel Binding Issue
> 
> Right.  The method just outputs the MSK/EMSK.  As long as the 
> same MSK is 
> outputted on both the EAP peer and server, the authenticator 
> doesn't need to 
> know what channel bindings were mixed in.
> 
> 
> >From: Yoshihiro Ohba <[email-masked]>
> >To: "Salowey, Joe" <[email-masked]>
> >CC: Bernard Aboba <[email-masked]>, 
> [email-masked],      
> >   [email-masked]
> >Subject: Re: [eap] Re: Issue 352: Channel Binding Issue
> >Date: Tue, 02 May 2006 18:55:29 -0400
> >
> >On Tue, May 02, 2006 at 03:21:19PM -0700, Salowey, Joe wrote:
> > > I'm not sure that carrying "mixed" MSKs in existing 
> attributes is such a
> > > good idea,  how does the authenticator know what it is getting?
> >
> >I don't think the authenticator needs to know whether the 
> received key
> >is the MSK or mixed MSK, as long as both the peer and authenticator
> >obtains the same key.
> >
> >Yoshihiro Ohba
> >
> >
> > >
> > > > -----Original Message-----
> > > > From: Bernard Aboba [mailto:[email-masked]]
> > > > Sent: Tuesday, May 02, 2006 12:27 PM
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: Re: [eap] Re: Issue 352: Channel Binding Issue
> > > >
> > > > >Thank you for reading the document.  And the answer is, if the
> > > > >generated "mixed" MSKs are carried in the existing AAA 
> attributes
> > > > >instead of carrying the MSKs, then no AAA attributes 
> or communication
> > > > >flow is required for EAP keying.
> > > >
> > > > It might be worth saying a few words about this in the
> > > > paragraph.  Overall,
> > > > I'm not sure whether the Channel Binding text in the document
> > > > is all that
> > > > consistent/comprehesive.
> > > >
> > > >
> > > > 
> _________________________________________________________________
> > > > To unsubscribe or modify your subscription options, 
> please visit:
> > > > http://lists.frascone.com/mailman/listinfo/eap
> > > >
> > > > Arhives: http://lists.frascone.com/pipermail/eap
> > > >
> > >
> > >
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 May 2006 19:22:37 -0400

> to get MSKYY.  MSKY and MSKYY don't match.

There is some misunderstanding.  If the authenticator is supposed to
further mix Y to get MSKYY from MSKY, then the peer is also supposed
to further mix Y to get MSKYY from MSKY.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 May 2006 17:25:51 +0300

>to further mix Y to get MSKYY from MSKY.
Yes, but the question is how do the peer and the AAA server
know that they are doing this? This is a change from the
current procedures, so presumably to make this all work there
needs to be negotiation somewhere that its turned on.

Wearing my AD hat:

Anyway, as I said in another e-mail, I really don't want
the EAP keying framework to pick a channel binding solution.
If it helps, we could drop all discussion of implementation
approaches for channel bindings, and just focus on the
desired behaviour.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 May 2006 10:04:21 -0700

>approaches for channel bindings, and just focus on the

We definitely should focus on describing the security problem (not sure 
we've done a good job with this yet), and the behavior.   The proposals 
could be referenced, but I don't think we can pick a solution at this time, 
if only because we don't have implementations in the field yet as far as I 
know.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 08 May 2006 16:01:01 -0400

> needs to be negotiation somewhere that its turned on.

Yes, and this is described in the first bullet of Section 7 "EAP
Method Requirements" of draft-ohba-eap-channel-binding-00.txt.

Yoshihiro Ohba