Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 22 Nov 2006 06:46:56 -0500

Hi Uri,

On Wed, Nov 22, 2006 at 09:41:03AM -0500, Blumenthal, Uri wrote:
> >The problem we are facing with EMSK is that the key and its usage were
> >not defined *at one time".  
> 
> True, definition of EMSK has been done in advance, PRIOR to its usage -
> so that by the time EMSK usage is defined, all the compliant methods
> already have implemented EMSK generation and have it available. This is
> not a problem.   
> 
> Especially since it is likely that most real-life implementations are
> modular enough to allow component upgrades.

For any method, how a compliant implementation and a non-compliant
implementation can be distinguished?  If they are indistinguishable,
then there will be an interoperability problem.  

For a future method that will be defined after we define an EMSK
usage, I agree that we can definetly mandate use of EMSK.  But
ignoring the existing implementations does not make sense, considering
the fact that some of them are already part of Wi-Fi certificate.

Yoshihiro Ohba

> 
> The problem is shortsightedness of some implementors, whose logic is "if
> I don't need this feature NOW, no way I'll spend resources implementing
> it".
> 
> >For this reason, I don't agree with
> >mandating the use of EMSK for all implementations. 
> 
> We cannot mandate what has not been defined yet. This is why we have
> mandated only EMSK generation, not EMSK usage.
> 
> Note the grammatic form of the verb: it IS a done deal, RFC 3578 IS a
> standard.
> 
> > Only making use of
> >EMSK optional makes sense to me, regardless of how it is going to be
> >used.
> 
> There is no use of EMSK currently defined, neither optional nor
> mandatory. So no need to make it anything.
> 
> It is mandatory to generate EMSK and make it available for applications.
> 
> How many times does is this dead horse going to be beaten?
> 
> 
> Yoshihiro Ohba
> 
> On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote:
> > Hi Yoshi,
> > 
> > I don't quite agree with this. Defining the full functionality of a
> new EAP
> > method (including how it spits out MSK and EMSK) should be the job the
> EAP
> > method designer. 3748, EAP keying framework and hokey specs then
> define how
> > MSK or EMSK is used. This is modular design. People who use EMSK then
> do not
> > have to worry about the crypto behind EMSK generation.
> > Using your analogy is "go buy the key and lock" but then wait to see
> which
> > door you want to install it on:)
> 
> > I as a home owner do not need to know how to make locks.
> > 
> > R,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[email-masked]] 
> > Sent: Friday, November 17, 2006 11:36 AM
> > To: Blumenthal, Uri
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> > 
> > Hi Uri,
> > 
> > I have a different view.  Mandating generation of EMSK without having
> > defined its usage *when it was introduced* seems not much different
> > from not having defining it at all.  It looks like selling a key
> > without a lock, make the lock later and say "You MUST use this key and
> > lock for your car."  Make sense??
> > 
> > Yoshihiro Ohba
> > 
> > 
> > 
> > On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote:
> > > >The discussion focuses on the problem EMSK is optional or
> mandatory.
> > > 
> > > I don't think this is a problem - GENERATION of EMSK is compulsoty
> as
> > > spelled out in RFC 3578.
> > > 
> > > The problem is non-compliance. Some, er, people seem to think "the
> > > standard says do A, but since I don't use A at the moment - I won't
> > > bother."
> > > 
> > > >RFC3578 defined EMSK is mandatory, 
> > > 
> > > And that should be the end of discussion.
> > > 
> > > >                     but it is not used at all. 
> > > 
> > > First - do you know all the applications that use key-generating EAP
> > > methods? But really - who cares? 
> > > 
> > > >If EMSK must be used, it is mandatory. if no, I think, 
> > > >it may be better that it is optional.
> > > 
> > > VERY strongly disagree. Mandatory is what is explicitly specified as
> > > mandatory, period. Otherwise many would implement just those pieces
> and
> > > features of the standard that his particular product needs today.
> > > 
> > > (I'm proud of my restraint - not even once using a term "B*S*" :-)
> > > _______________________________________________
> > > Hokeyp mailing list
> > > [email-masked]
> > > http://www.opendiameter.org/mailman/listinfo/hokeyp
> > > 
> > 
> > _______________________________________________
> > Emu mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/emu
> > 
> > 
> 
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 22 Nov 2006 09:35:46 -0800

>then there will be an interoperability problem.

This is not rocket science!  I have some second-hand experience with 
IPsec interoperability; if implementation X does not interoperate 
with implementation Y, people then figure out which one is 
non-compliant and have that implementation fixed.

>usage, I agree that we can definetly mandate use of EMSK.

This is moot.  EMSK derivation is already defined as mandatory.  Are 
you proposing something stronger than a MUST?

Lakshminath

>But

---

From: Tom Wan <[email-masked]>
Date: Thu, 23 Nov 2006 09:05:01 +0800

Hi,Yoshi:

I am new to this topic. So if I ask some naive questions, forgive me please.
I would like to know whether the implementations you told us are widely 
deployed or not?
Are they prototypes or widely deployed by the operators?

Thank you very much. You answer is appreciated.

BR
Tom

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 22 Nov 2006 09:07:09 -0500

> non-compliant and have that implementation fixed.

A HOKEY compliant implementation should be able to revert to the
legacy mode of operation (i.e., use of MSK in the current way) so that
it still interoperates with a HOKEY non-compliant implementation
without ending up with a communication failure or changing the HOKEY
non-compliant implementation.  Note that a HOKEY non-compliant
implementation is still RFC3748 compliant as long as it generates MSK
and EMSK even if it does not use EMSK.

> you proposing something stronger than a MUST?

"EMSK derivation is a MUST" does not mean that "use of EMSK is MUST".

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 22 Nov 2006 18:29:07 -0800

I don't disagree with your latest statements.  Those are generally 
the assumptions I am working with.  What I don't understand is the 
link between those statements and your previous statements.  The 
current EAP authentication model is the default mode of operation if 
something fails or if the new capabilities are not supported.  By 
that logic there shouldn't really be a blanket statement say one MUST 
"use" EMSK.  Of course, some access technologies may decide to 
specify MUST try/use EMSK in the first round or something like that, 
but that is not going to be in an RFC.

Anyway, that's my current thinking.  We are early in the process here 
and when the design is complete, we can think further about what makes sense.

In the meanwhile, let's stick to what we have in other RFCs.

Happy thanksgiving weekend to all

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 22 Nov 2006 22:12:37 -0500

> but that is not going to be in an RFC.

These are along with my opinion.  

Regarding the link between my previous and latest statements, the
ability to revert to the default mode of operation if something fails
or if the new capabilities are not supported is equivalent to the
ability to dintinguish HOKEY compliant and non-compliant
implementations.  I think we are in convergence.

Regards,
Yoshihiro Ohba

---

From: "Charles Clancy" <[email-masked]>
Date: Sun, 26 Nov 2006 09:14:42 -0500 (EST)

> and EMSK even if it does not use EMSK.

Let me point this out again.  In order to support HOKEY, EAP
implementations MUST change to implement the reauth protocols.  Thus, I
don't understand why fixing broken methods to export the EMSK at the same
time is such a big deal.

I'm not convinced by the certification arguments.  EAP implementations
will all have to be recertified by whomever to check HOKEY compatability
anyway.  Proper use of the EMSK would be tested then.

I'm also not convinced by the versioning arguments, since you'd never need
to use the EMSK if you weren't executing some HOKEY reauth protocol.  If
an implementation didn't derive/export the EMSK, then it has no business
executing a reauth.  By executing a reauth, an implementation is
implicitly signaling that it can derive EMSKs for the originally-executed
method.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 26 Nov 2006 13:14:27 -0500

> don't understand why fixing broken methods to export the EMSK at the same

If the reauth protocols require changes to all peers, authenticators
and servers, then isn't it a big deal?  I can't realistically assume
that such upgrade can be done at one time.

> anyway.  Proper use of the EMSK would be tested then.

That is certainly possible, but my argument was that HOKEY-compliant
implementations must interoperate with HOKEY non-compliant (but still
RFC3748-compliant and some of them are WFA-certified) implementations
regardless of whether HOKEY will be WFA-certified or not.

> implicitly signaling that it can derive EMSKs for the originally-executed

In my reading of the existing reauth proposal, implicit signaling for
reauth capability discovery is made based on whether the peer,
authenticator and server understand a new Code which will be siliently
discarded by the recipient that do not understand it.  This means that
reauth implementations based on the existing proposal would need to
rely on timeouts to detect implementations that do not support reauth.
Relying on timeouts will significantly affect handover performance.
Of course, other solution would be possible to detect
reauth-unsupported implementations without relying on versioning or
timeouts, but versioning were the simplest way for capability
discovery.

Yoshihiro Ohba

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 22 Nov 2006 09:41:03 -0500

Yoshihiro Ohba

new EAP
EAP
define how
do not
which

mandatory.
as
and