Issue 360: EMSK Transport

After reading the text again I would be OK removing the
specifc text
about the AAA layer.  

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondetiqualcomm.com] 
> Sent: Tuesday, May 02, 2006 2:46 PM
> To: Salowey, Joe; Narayanan, Vidya; Bernard Aboba;
eapfrascone.com
> Subject: RE: [eap] Re: Issue 360: EMSK Transport
> 
> I am having a logical problem parsing "The EMSK
MUST NOT be 
> transported outside the EAP Server by the AAA
layer."
> 
> Does that allow transport of EMSK by other layers?  I
know that's not 
> the intent.
> 
> regards,
> Lakshminath
> 
> At 01:50 PM 5/2/2006, Salowey, Joe wrote:
> >The document should not discuss where the EMSK is
exported 
> to from the
> >EAP method as this may be implementation dependent.
> >
> >Here is some suggested text (should go in 1.4
instead of section 2).
> >
> >"The EMSK MUST NOT be provided to an entity
outside the EAP server or
> >    peer,  nor is it permitted to pass any quantity
to an 
> entity outside
> >    the EAP server or peer from which the EMSK
could be 
> computed without
> >    breaking some cryptographic assumption, such as

> inverting a one-way
> >    function.  The EMSK MUST NOT be transported
outside the 
> EAP Server
> >    by the AAA layer.  As noted in [RFC3748]
Section 7.10:"
> >
> >Joe
> >
> > > -----Original Message-----
> > > From: Narayanan, Vidya [mailto:vidyanqualcomm.com]
> > > Sent: Tuesday, May 02, 2006 12:07 PM
> > > To: Salowey, Joe; Bernard Aboba; eapfrascone.com
> > > Subject: RE: [eap] Re: Issue 360: EMSK
Transport
> > >
> > > Hi Joe,
> > > The text suggests that the AAA layer MUST NOT
transport 
> the EMSK, not
> > > that the AAA layer MUST NOT transport the
EMSK outside 
> the entity. To
> > > me, this implied that the EMSK MUST NOT be
transported to 
> other layers
> > > within the same entity as well.
> > >
> > > Due to the current means of key transport,
the EMSK 
> arrives at the AAA
> > > layer when the MSK arrives. But, we may (I'm
not sure yet)
> > > need the EMSK
> > > to be available to the EAP layer for further
key 
> derivation - the AAA
> > > layer is potentially not the right layer to
be deriving the
> > > keys - then,
> > > that would imply that the lower layer in the
peer is the 
> one deriving
> > > the same keys. This, apart from being
disparate, also 
> means that every
> > > lower layer now needs to define this
derivation, which seems
> > > undesirable.
> > >
> > > So, pending discussion, I'd like to not have
this statement in the
> > > current spec.
> > >
> > > Vidya
> > >
> > > > -----Original Message-----
> > > > From: Salowey, Joe [mailto:jsaloweycisco.com]
> > > > Sent: Tuesday, May 02, 2006 8:45 AM
> > > > To: Bernard Aboba; eapfrascone.com
> > > > Subject: RE: [eap] Re: Issue 360: EMSK
Transport
> > > >
> > > > I don't see the text as harmful. It may
be somewhat
> > > > redundant, but I would like to better
understand why its
> > > > presence is restrictive.  That would
seem to indicate that it
> > > > is not redundant.
> > > >
> > > > Joe
> > > >
> > > > > -----Original Message-----
> > > > > From: Bernard Aboba
[mailto:bernard_abobahotmail.com]
> > > > > Sent: Tuesday, May 02, 2006 5:54 AM
> > > > > To: eapfrascone.com
> > > > > Subject: [eap] Re: Issue 360: EMSK
Transport
> > > > >
> > > > > Since EMSK sharing is prohibited
elsewhere in the document,
> > > > the text
> > > > > to be deleted is redundant at best.
 Any objections to
> > > > accepting the
> > > > > proposed change?
> > > > >
> > > > >
> > > >
> > > 
>
------------------------------------------------------------
---------
> > > > > Issue 360: EMSK Transport
> > > > > Submitter name: Vidya Narayanan
> > > > > Submitter email address: vidyanqualcomm.com Date
> > > Submitted: May 1,
> > > > > 2006
> > > > > Reference: 
> http://lists.frascone.com/pipermail/eap/msg04230.html
> > > > > Document: KEYING-12
> > > > > Comment type: 'T'echnical
> > > > > Priority: '1' Should fix
> > > > > Section: 2
> > > > > Rationale/Explanation of issue:
> > > > >
> > > > > The section says "The EMSK
MUST NOT be transported by the
> > > > AAA layer."
> > > > > Given that the EMSK usage is
currently undefined, it is not
> > > > clear if
> > > > > it will be the AAA layer that
derives further keys from the
> > > > EMSK. In
> > > > > fact, doing so will create
disparate behavior at the peer
> > > > and server,
> > > > > since the peer does not have a AAA
layer. Although 
> this topic is
> > > > > pending discussion, it seems
restrictive to say MUST NOT
> > > > here. It does
> > > > > make sense, however, to say that
the EMSK MUST NOT be
> > > > transported to
> > > > > additional parties.
> > > > >
> > > > >     Requested change:
> > > > >
> > > > > Delete the sentence "The EMSK
MUST NOT be transported 
> by the AAA
> > > > > layer".
> > > > >
> > > > >
> > > > > 
>
____________________________________________________________
_____
> > > > > 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
> > > >
> > >
>
>________________________________________________________
_________
> >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

Issue 360: EMSK Transport

Thread: Issue 360: EMSK Transport