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

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Nov 2006 14:35:30 -0500

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 17 Nov 2006 09:22:04 -0500

---

From: Michael Ye <[email-masked]>
Date: Mon, 20 Nov 2006 10:42:58 +0800

Hi Blumenthal,

see below,

BR,
Michael  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blumenthal, Uri
> Sent: Friday, November 17, 2006 10:22 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> I don't think this is a problem - GENERATION of EMSK is 
> compulsoty as spelled out in RFC 3578.

Michael=>>Really, people were talking about it. Yes,  it is compulsory in
RFC3578.

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

 Michael=>> I agree.
> First - do you know all the applications that use 
> key-generating EAP methods? But really - who cares? 

Michael=>> As far as know, it is so.
> 
> >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.

Michael=>>Blumenthal, I think, it is discussions'intention that some
upcoming solutions become better.  people express themselive opinions here,
so different opinions are common.

> 
> (I'm proud of my restraint - not even once using a term 
> "B*S*" :-) _______________________________________________
> Hokeyp mailing list
> [email-masked]

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 21 Nov 2006 08:43:06 -0800

I agree with Uri, We should not worry about non-compliant implementations,
that is the implementor's problem. 
3748 and EAP keying did not define use of EMSK, but they did forbid export
of EMSK last time I read the keying spec. Fortunately, Hokey is now
chartered to define usage of EMSK through deliverable 2 (generation of
USRK). So if there is a place where people are to use EMSK is supposed to
use, I guess the place to go get the spec is hokey.

I have kind of lost track of what this thread was trying to do, but as far
as use in Hokey, I think we can assume that the EAP method generates the
EMSK. The question in hokey is whether we use MSK or EMSK? And why? Or maybe
that was not the intention of the thread.

R,

Madjid

-----Original Message-----
Sent: Friday, November 17, 2006 6:22 AM

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 21 Nov 2006 08:50:46 -0800

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,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 19 Nov 2006 08:36:25 -0500

Hi Madjid,

The problem we are facing with EMSK is that the key and its usage were
not defined *at one time".  For this reason, I don't agree with
mandating the use of EMSK for all implementations.  Only making use of
EMSK optional makes sense to me, regardless of how it is going to be
used.

Yoshihiro Ohba

---

From: David Mitton <[email-masked]>
Date: Sat, 25 Nov 2006 00:28:41 -0500

I haven't had time to join this discussion prior to this, but
I'll just pick this response out of the stream and make a comment or two:

>lock for your car."  Make sense??

The current specification require that a method generate EMSK, but 
then tell you not to show it to anyone.
So to paraphrase the age old question, if an EAP method generates an 
EMSK in a forest and nobody hears it, does it comply with RFC3748?

Until there is a standard API, or a definition of how a method 
exports an EMSK, or even uses an EMSK to produce a publicly visible 
result, this issue is a moot question, because there is no 
consequence of not producing an EMSK and saying that you did.  The 
method is still a black box with this respect.

In any case, when something does get defined that makes it matter, 
only then will method implementers have to make it happen.   And it 
will require the modules to be updated to meet the new requirements, 
there's no other way.

Dave.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Nov 2006 07:32:47 -0800

On Friday 17 November 2006 11:35, Yoshihiro Ohba wrote:
> 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.

I think this is exactly the other way around.

*Mandating* generation of EMSK without having defined 
its usage when it was introduced make it possible to 
later define how it should be used, and use it.

That's why it's been *mandated* :)

--julien

ietf.org with esmtp (Exim 4.43)
	id 1GoYjo-0005xy-Lu; Mon, 27 Nov 2006 00:09:04 -0500
From: Julien Laganier <[email-masked]>
To: [email-masked]
Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
Date: Thu, 23 Nov 2006 07:32:47 -0800
Cc: [email-masked], "Blumenthal, Uri" <[email-masked]>

On Friday 17 November 2006 11:35, Yoshihiro Ohba wrote:
> 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.

I think this is exactly the other way around.

*Mandating* generation of EMSK without having defined 
its usage when it was introduced make it possible to 
later define how it should be used, and use it.

That's why it's been *mandated* :)

--julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 28 Nov 2006 16:19:32 -0800

Hi Yoshi,

Sorry for the very late response. I think the issue was whether methods
generate EMSK or not, there was not a discussion of usage.
Now, some method do generate EMSK and some don't. The same way that some EAP
method did one-way authentication and some did mutual authentication.

It is the job of the security engineer to pick the right EAP method, more
clearly, if he/she needs EMSK and the method does not give it, he/she picks
something else, there is no rocket science here.

R,

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Sunday, November 19, 2006 5:36 AM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; 'Blumenthal, Uri'; [email-masked];
[email-masked]

Hi Madjid,

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 29 Nov 2006 22:56:19 -0800

Hi Dave, 

Thanks for singling out my response. I am choosing to feel good about it:)
Your point about the need for an API is really a good one that nobody is
discussing in this lengthy thread and the other thread going on in Hokey. I
alluded to it several times in EAP WG list, here and on hokey list.
Yes, the fact that EMSK is not to be exported, is a scream in the forest,
well guess what, For a while people wanted to even throw EMSK cache away, so
we managed to get that out of the system:) 
Now, hokey and others want to use EMSK to generate usage specific root keys
(USRK). Once those specs are out, implementers must implement EMSK and some
sort of API as follows:

If EMSK never gets to the AAA layer, then the AAA layer cannot generate the
USRK from EMSK itself. AAA layer must after authorizing a usage, ask EAP
layer (who holds the EMSK) to generate a USRK for a specific usage. So this
basically means a logical module acting as the EAP server that holds EMSK,
must have an API to the AAA module to receive a request for USRK generate it
and then send it back. 

R,

Madjid

-----Original Message-----
From: David Mitton [mailto:[email-masked]] 
Sent: Friday, November 24, 2006 9:29 PM
To: [email-masked]
Subject: RE: [Hokeyp] [Emu] Re: MSK but no EMSK

Dave.