Subject: RE: [HOKEY] EMSK Issue

From: Avi Lior <[email-masked]>
Date: Tue, 18 Mar 2008 17:59:22 -0400

I would prefer not to say anything at all.  But that may not be realistic.

I do understand Jari's concern that there *could* be some issues if no used correctly.

I think the main objection as I understand it is that Network Access Authentication should be decoupled for Application Authentication.  That is, if we use the EMSK derived from Network Access Authentication to derive keys for applications we are coupling the two authentications.

This can be bad as Jari puts it because those applications that are coupled to one Network may not work when the user is connect to another network.

I agree but not generally. That is, there are some applications for which coupling makes perfect sense.  Applications that strictly run within the context of a Network Access session could benefit by having their application keys bootstrapped from EMSK.

For example, Over-the-Air provisioning application and location based applications that are part of the network.

Bootstrapping the keys from EMSK creates a single-sign-on and elliminates the need to have to provision keys for each of the applications and elliminates the need to run extra messaging to create session keys etc.

Application like a web server may not be appropriate to have its keys derived from EMSK because these application are network agnostic.

So we need to say something.  But that something needs to indicate the issues so that SDOs understand when to use the EMSK thingy and when not to use it.  I do not support making blanket statements such as Application MUST not derive their keys from EMSK.

Also note that there are ways to use the EMSK even in the case of the Applications that are access network agnostic.  And we should not block this scenario.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Glen Zorn
> Sent: Tuesday, March 18, 2008 11:31 AM
> To: Charles Clancy
> Cc: [email-masked]; [email-masked]; Bernard Aboba
> Subject: Re: [HOKEY] EMSK Issue
>
> Charles Clancy <> scribbled on :
>
> > HOKEY,
> >
> > From Bernard's "walled garden" LC comments, I've created
> the following
> > issue below in the issue tracker.
>
> Some of us don't subscribe to the IETF list (due to the
> extremely poor S/N ratio).  Someone did forward me Bernard's
> original message & to me it appears to fall squarely into the
> N category (either that or it is an early April 1 RFC
> candidate).  I understand, though, that it is actually
> receiving serious discussion on the IETF list, so I'm happy
> that you are bringing some of that discussion to this forum.
> Of course, common courtesy would have required that the WG
> the work of which is being disparaged in outrageous fashion
> be included in the discussion but courtesy seems to be in
> short supply.
>
> >
> > http://www.ltsnet.net:8080/hokey/issue39
> > EMSK: applicability statement, scope
> >
> > The EMSK document, as-is, allows (or more precisely does not
> > disallow) for broader use of keys than it should.
>
> That may be somebody's claim; however, RFC 3748 says:
>
>    Extended Master Session Key (EMSK)
>       Additional keying material derived between the EAP client and
>       server that is exported by the EAP method.  The EMSK is at least
>       64 octets in length.  The EMSK is not shared with the
>       authenticator or any other third party.  The EMSK is
> reserved for
>       future uses that are not defined yet.
>
> This doesn't appear to me to constrain the uses of the EMSK;
> furthermore, since Bernard is not just one of the authors of
> 3748 but also a co-Chair of the working group that published
> it, it seems like the time & place to constrain the usage of
> the EMSK would have been during the drafting of the RFC and
> in the eap WG.
>
> > There could
> > be interoperability issues if applications require
> EAP-generated keys,
> > breaking the layering of the Internet protocol stack.
>
> What does that mean?  How can _keys_ cause layer violations?
>
> >
> > Some sort of statement regarding applicability and scoping
> of derived
> > keys is necessary for this document.
> >
> > --
> > t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> > electrical & computer engineering, university of maryland
> > _______________________________________________
> > HOKEY mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/hokey
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
>
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 18 Mar 2008 08:31:15 -0700

Charles Clancy <> scribbled on :

> HOKEY,
> 
> From Bernard's "walled garden" LC comments, I've created the
> following issue below in the issue tracker.

Some of us don't subscribe to the IETF list (due to the extremely poor
S/N ratio).  Someone did forward me Bernard's original message & to me
it appears to fall squarely into the N category (either that or it is an
early April 1 RFC candidate).  I understand, though, that it is actually
receiving serious discussion on the IETF list, so I'm happy that you are
bringing some of that discussion to this forum.  Of course, common
courtesy would have required that the WG the work of which is being
disparaged in outrageous fashion be included in the discussion but
courtesy seems to be in short supply.

      authenticator or any other third party.  The EMSK is reserved for

This doesn't appear to me to constrain the uses of the EMSK;
furthermore, since Bernard is not just one of the authors of 3748 but
also a co-Chair of the working group that published it, it seems like
the time & place to constrain the usage of the EMSK would have been
during the drafting of the RFC and in the eap WG.  

> EAP-generated keys, breaking the layering of the Internet protocol
> stack. 

> 
> Some sort of statement regarding applicability and scoping of
> derived keys is necessary for this document.
> 
> --

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 18 Mar 2008 17:26:35 -0700

FWIW, I agree with Glen's take here.  To avoid repeating myself, here
are pointers to emails that I sent in response to this thread on the
IETF list (for the benefit of those not on the list): 

http://www.ietf.org/mail-archive/web/ietf/current/msg50860.html
http://www.ietf.org/mail-archive/web/ietf/current/msg50880.html

- Vidya

> Sent: Tuesday, March 18, 2008 8:31 AM
> To: Charles Clancy

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Mar 2008 16:01:41 +1300

Glen,

On 2008-03-19 04:31, Glen Zorn wrote:
...
> courtesy seems to be in short supply.

Setting aside the tone of that remark, [email-masked] *is* the recommended
forum for IETF Last Call comments (see the text of every Last Call message).
So I believe that Bernard chose the correct list to launch his opinion.
I can certainly agree that resolving this issue could be better done
on the WG list.

     Brian

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 19 Mar 2008 06:27:46 -0700

Brian E Carpenter <mailto:[email-masked]> scribbled on
Tuesday, March 18, 2008 11:02 PM:

>> Some of us don't subscribe to the IETF list (due to the extremely
>> poor S/N ratio).  Someone did forward me Bernard's original message
>> & to me it appears to fall squarely into the N category (either that
>> or it is an early April 1 RFC candidate).  I understand, though,
>> that it is actually receiving serious discussion on the IETF list,
>> so I'm happy that you are bringing some of that discussion to this
>> forum.  Of course, common courtesy would have required that the WG
>> the work of which is being disparaged in outrageous fashion be
>> included in the discussion but courtesy seems to be in short supply.
> 
> Setting aside the tone of that remark, 

Please don't.  I was brought up never to talk behind someone's back; in
that context, the 'tone of my remark' is quite restrained, I think.

> [email-masked] *is* the
> recommended forum for IETF Last Call comments (see the text of
> every Last Call message).

I don't believe that I said anything different.  There is a difference
between doing the bare minimum necessary to satisfy the rules & what is
required for simple courtesy.  Sometimes that difference is quite small,
in this case "CC: [email-masked]" but that still seems too much to
manage in this case.
  
> So I believe that Bernard chose the correct list to launch his

Attack.  I think that the word you want here is "attack".

> opinion. I can certainly agree that resolving this issue could be
> better done on the WG list.
> 
>     Brian

---

From: Charles Clancy <[email-masked]>
Date: Sun, 23 Mar 2008 22:17:41 -0400

Vidya,

 > ... do the responsible thing, which would be to clearly define the
 > applicability, along with providing an interoperable means of defining
 > the key hierarchy for those usages that want to/can use it.

This is all I'm suggesting we do.  I think we should add text to the 
document that gives guidance on the types of usages for which a USRK 
would be appropriate.  Usages should be for functions related to the 
access network to which you are connecting, and for functions where it 
is reasonable for your access network to have an interest in authorization.

For example, consider using a USRK to secure HTTP.  If your access 
provider did this to deliver firmware updates to your handset, this 
might be reasonable, but if amazon.com required it for authentication, 
this would be unreasonable.  Even if amazon.com had an agreement with 
your provider to obtain a USRK for your session, that's not the kind of 
thing for which your provider should be the authorization authority.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 23 Mar 2008 20:36:32 -0700

> this would be unreasonable.

I do not believe that either application is reasonable.   The EAP peer
has no reason to trust a third party to update its firmware merely
because they can prove possession of a key derived from the EMSK.
Given that any proxy on the path could obtain such a key, this kind
of architecture provides such flimsy security that it needs to be
restricted to use in protecting a commodity (e.g. network access)
that has virtually no value.

Existing firmware distribution models provide much higher levels of trust,
typically providing verification of the identity of the third party, as
well as demonstration that they are authorized to provide firmware
updates, and proof that the firmware itself has not been tampered with.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 24 Mar 2008 11:26:46 -0700

Charles,

> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Sunday, March 23, 2008 7:18 PM
> To: Narayanan, Vidya
> Cc: Glen Zorn; [email-masked]; [email-masked]; Bernard Aboba
>  > ... do the responsible thing, which would be to clearly 
> define the  > applicability, along with providing an 
> interoperable means of defining  > the key hierarchy for 
> those usages that want to/can use it.
> 
> This is all I'm suggesting we do.  I think we should add text 
> to the document that gives guidance on the types of usages 
> for which a USRK would be appropriate.  Usages should be for 
> functions related to the access network to which you are 
> connecting, and for functions where it is reasonable for your 
> access network to have an interest in authorization.
> 

How about the following text for applicability: 

"It must be noted that any application of EAP keying material to other
usages such as handoffs, IP mobility or other applications is only
feasible when those services are provided either by or through the
provider handling network access.  It is also only feasible when those
usages only occur over EAP-capable interfaces. Hence, deriving USRKs or
DSUSRKs for usages other than those facilitated by the network access
provider is NOT RECOMMENDED." 

Thanks,
Vidya

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 30 Mar 2008 22:33:03 -0700

Hi Vidya,

I think this is an excellent start.  I'll put some applicability and
security considerations text together for the document for discussion on
the list.  

Cheers,

Joe 

> On Behalf Of Narayanan, Vidya
> Sent: Monday, March 24, 2008 11:27 AM
> To: Charles Clancy
> define the  
> > > applicability, along with providing an interoperable means of 
> > defining  > the key hierarchy for those usages that want to/can use 
> > it.
> > 
> "It must be noted that any application of EAP keying material 
> to other usages such as handoffs, IP mobility or other 
> applications is only feasible when those services are 
> provided either by or through the provider handling network 
> access.  It is also only feasible when those usages only 
> occur over EAP-capable interfaces. Hence, deriving USRKs or 
> DSUSRKs for usages other than those facilitated by the 
> network access provider is NOT RECOMMENDED." 
> 
> Thanks,
> Vidya