|
List Info
Thread: Strawman -10/EMSK deletion requirement?
|
|
| Strawman -10/EMSK deletion requirement? |

|
2006-03-10 16:50:41 |
Hi Rafa,
You raise a good point in the following:
> I have seen during discussions and also under my
> understanding of draft-aboba-eap-keying-extns-00.txt
that
> either 1) AMSK would be tranported from AAA server to
some
> entity or 2) AMSK could be used as a root and cached by
the
> AAA server to derive new keys which would be eventually
> transported to different entities.
>
> will that decision between both cases be specified for
> application? or would it be better to select one
approach (it
> seems people like second one)?
I have recently seen the need for both models. IMO keeping
the AMSK at
the AAA and EAP Peer and only transporting derived keys to
external
entities makes a lot of sense but consider the following:
Supposing I have an two entities E1 and E2 that received
DE-KEY(s)
derived from E-AMSK. DE-KEY(s) are used to secure the
communication
between E1 and E2.
Now E2 wants to delegate responsibility of communicate with
E1 to E3
which it trusts. E2 can pass the DE-KEY(s) to E3 but it
would be better
to derive another set of keys for that communication.
As I understand it, E2 and E1 cannot derive DE-KEY'(s) from
DE-KEY(s) --
since DE-KEY(s) are used for one purpose already and using
them for
another purpose (key derivation) will make them weak. So in
this case
the only way to achieve this tranasaction is to involve AAA
again. This
could be very expensive.
Another approach is to send E1 and E2 E-AMSK so that they
can generate
subsequent keys to deal with this scenario. Of course you
could also
send E1 and E2 DE-KEY(S) to secure their communication and
also another
key derived from E-AMSK for the purpose of generating new
keys. But is
that necessary? Why couldn't we just distribute E-AMSK.
> -----Original Message-----
> From: Rafa Marin Lopez [mailto:rafa dif.um.es]
> Sent: Friday, March 10, 2006 11:15 AM
> To: Jari Arkko
> Cc: Avi Lior; eap frascone.com
> Subject: Re: [eap] Strawman -10/EMSK deletion
requirement?
>
> Hi Jari
>
> >First of all, I think this part of the discussion
is largely just a
> >matter of vague definitions making it hard to make
exact statements.
> >E.g. where is the line between AAA as a
"transport" and as an
> >"application" that has intelligence to
make decisions and grant
> >resources such as keys?
> >
> >
> I agree on you this. In my mind the AAA server (where
EAP
> server might be co-located) is (or should be)
intelligent
> enough to manage keys from users.
>
> >Just to repeat what we have already established, I
think we have
> >consensus that (a) EMSK is generated by EAP methods
and that (b) its
> >not going to be shipped away to the access devices.
In addition, it
> >seems obvious that the document we are discussing
will not
> define how
> >AMSKs are used or transported.
> >
> >
> >So the conclusion is that the EMSK is kept
somewhere between the EAP
> >method and AAA transport layers.
> >
> >
> So far, between EAP methods and AAA transpor layers
(AAA
> server?? ) we have EAP authenticator layer and EAP
layer. An
> as specified draft-ietf-eap-keying-10.txt both layers
cannot
> cache anything. I think it does not preclude the use of
EMSK
> but it establishes limits to the creation of AMSK. That
is,
> the AMSK should be created just in the moment the EMSK
is
> exported. If EMSK wants to be cached, that part of text
> should be relaxed, no?
>
> >I would note that this means that it is, in an IETF
sense,
> within a box
> >and not transported via protocols. I don't think
it makes a lot of
> >sense to debate too long about what the internal
structure
> of the box
> >is. I'd be happy saying that it resides in the EAP
server. I
> would in
> >addition only say the following about the internal
module
> structures:
> >The EMSK is not communicated either to the lower
layer or the AAA
> >transport layer.
> >But AMSKs derived from it can be,
> >and that any such derivation would have to be
defined in future
> >documents.
> >
> >
> I have seen during discussions and also under my
> understanding of draft-aboba-eap-keying-extns-00.txt
that
> either 1) AMSK would be tranported from AAA server to
some
> entity or 2) AMSK could be used as a root and cached by
the
> AAA server to derive new keys which would be eventually
> transported to different entities.
>
> will that decision between both cases be specified for
> application? or would it be better to select one
approach (it
> seems people like second one)?
>
> Regards.
>
> --
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645 e-mail: rafa dif.um.es
> ------------------------------------------------------
>
>
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
| Strawman -10/EMSK deletion requirement? |

|
2006-03-13 21:39:00 |
Hi Avi,
please see my comments inline
Avi Lior wrote:
>Hi Rafa,
>
>You raise a good point in the following:
>
>
>
>>I have seen during discussions and also under my
>>understanding of draft-aboba-eap-keying-extns-00.txt
that
>>either 1) AMSK would be tranported from AAA server
to some
>>entity or 2) AMSK could be used as a root and cached
by the
>>AAA server to derive new keys which would be
eventually
>>transported to different entities.
>>
>>will that decision between both cases be specified
for
>>application? or would it be better to select one
approach (it
>>seems people like second one)?
>>
>>
>
>I have recently seen the need for both models. IMO
keeping the AMSK at
>the AAA and EAP Peer and only transporting derived keys
to external
>entities makes a lot of sense but consider the
following:
>
>Supposing I have an two entities E1 and E2 that received
DE-KEY(s)
>derived from E-AMSK. DE-KEY(s) are used to secure the
communication
>between E1 and E2.
>
>
What entity is the EAP peer? At least one of the entities
should be the
EAP peer no?.
or are you calling "entity" to EAP lower layer
in the EAP peer??
>Now E2 wants to delegate responsibility of communicate
with E1 to E3
>which it trusts. E2 can pass the DE-KEY(s) to E3 but it
would be better
>to derive another set of keys for that communication.
>
>
Yes, I would prefer to see E2 derives keys for the
communication between
E1 and E3
>As I understand it, E2 and E1 cannot derive DE-KEY'(s)
from DE-KEY(s) --
>since DE-KEY(s) are used for one purpose already and
using them for
>another purpose (key derivation) will make them weak.
>
I am not sure about this. Why will it make them weak? I mean
it looks
like the definition of key hierarchy. It the key hierarchy
and role of
participating entities are well defined... why is it
weaker?
> So in this case
>the only way to achieve this tranasaction is to involve
AAA again. This
>could be very expensive.
>
>Another approach is to send E1 and E2 E-AMSK so that
they can generate
>subsequent keys to deal with this scenario. Of course
you could also
>send E1 and E2 DE-KEY(S) to secure their communication
and also another
>key derived from E-AMSK for the purpose of generating
new keys. But is
>that necessary?
>
>Why couldn't we just distribute E-AMSK.
>
between E1 and E2...?I am not really sure if i get your
example :(.
Could you provide a real scenario where this is happening?
P.D: I think distributing AMSK is a possible alternative.
However if in
a future access, another AMSK is needed, AAA server should
"request"
another AMSK (derived from EMSK) to the EAP server. On the
other hand,
if AAA server already has a cached AMSK to generate more
keys, use of
EMSK is not needed (which might be an advantage if
eventually it is
decided EMSK needs to be removed). In the end, I think
application
should define its own key hierarchy from AMSK. In this way,
an
application could want to tranport AMSK derived from EMSK to
authenticator and another ones may want to use that AMSK to
create
another keys to be sent to authenticators.
--
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645 e-mail: rafa dif.um.es
------------------------------------------------------
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
| Strawman -10/EMSK deletion requirement? |

|
2006-03-14 14:58:00 |
Hi Avi,
On Fri, Mar 10, 2006 at 11:50:41AM -0500, Avi Lior wrote:
(snip)
>
> Another approach is to send E1 and E2 E-AMSK so that
they can generate
> subsequent keys to deal with this scenario. Of course
you could also
> send E1 and E2 DE-KEY(S) to secure their communication
and also another
> key derived from E-AMSK for the purpose of generating
new keys. But is
> that necessary? Why couldn't we just distribute
E-AMSK.
Actually this scenario is covered by Section 4.2.
(Transferring CBMK)
of draft-ohba-eap-channel-binding-00.txt.
Yoshihiro Ohba
>
>
> > -----Original Message-----
> > From: Rafa Marin Lopez [mailto:rafa dif.um.es]
> > Sent: Friday, March 10, 2006 11:15 AM
> > To: Jari Arkko
> > Cc: Avi Lior; eap frascone.com
> > Subject: Re: [eap] Strawman -10/EMSK deletion
requirement?
> >
> > Hi Jari
> >
> > >First of all, I think this part of the
discussion is largely just a
> > >matter of vague definitions making it hard to
make exact statements.
> > >E.g. where is the line between AAA as a
"transport" and as an
> > >"application" that has
intelligence to make decisions and grant
> > >resources such as keys?
> > >
> > >
> > I agree on you this. In my mind the AAA server
(where EAP
> > server might be co-located) is (or should be)
intelligent
> > enough to manage keys from users.
> >
> > >Just to repeat what we have already
established, I think we have
> > >consensus that (a) EMSK is generated by EAP
methods and that (b) its
> > >not going to be shipped away to the access
devices. In addition, it
> > >seems obvious that the document we are
discussing will not
> > define how
> > >AMSKs are used or transported.
> > >
> > >
> > >So the conclusion is that the EMSK is kept
somewhere between the EAP
> > >method and AAA transport layers.
> > >
> > >
> > So far, between EAP methods and AAA transpor
layers (AAA
> > server?? ) we have EAP authenticator layer and EAP
layer. An
> > as specified draft-ietf-eap-keying-10.txt both
layers cannot
> > cache anything. I think it does not preclude the
use of EMSK
> > but it establishes limits to the creation of AMSK.
That is,
> > the AMSK should be created just in the moment the
EMSK is
> > exported. If EMSK wants to be cached, that part of
text
> > should be relaxed, no?
> >
> > >I would note that this means that it is, in an
IETF sense,
> > within a box
> > >and not transported via protocols. I don't
think it makes a lot of
> > >sense to debate too long about what the
internal structure
> > of the box
> > >is. I'd be happy saying that it resides in
the EAP server. I
> > would in
> > >addition only say the following about the
internal module
> > structures:
> > >The EMSK is not communicated either to the
lower layer or the AAA
> > >transport layer.
> > >But AMSKs derived from it can be,
> > >and that any such derivation would have to be
defined in future
> > >documents.
> > >
> > >
> > I have seen during discussions and also under my
> > understanding of
draft-aboba-eap-keying-extns-00.txt that
> > either 1) AMSK would be tranported from AAA server
to some
> > entity or 2) AMSK could be used as a root and
cached by the
> > AAA server to derive new keys which would be
eventually
> > transported to different entities.
> >
> > will that decision between both cases be specified
for
> > application? or would it be better to select one
approach (it
> > seems people like second one)?
> >
> > Regards.
> >
> > --
> >
------------------------------------------------------
> > Rafael Marin Lopez
> > Faculty of Computer Science-University of Murcia
> > 30071 Murcia - Spain
> > Telf: +34968367645 e-mail: rafa dif.um.es
> >
------------------------------------------------------
> >
> >
>
____________________________________________________________
_____
> 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
|
|
[1-3]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|