> So the question is do you have to generate all possible
AMSKs and then
> delete the EMSK or can you generate the AMSKs as
needed?
>
[Joe] I understand that there may be need for caching of
certain
quantities. I think Jari explained it well in a separate
message. In
my opinion you should try to identify the applications in
use and the
keys needed as early as possible. If this is not possible
then caching
of the MSK may be necessary. Do we have examples where the
caching of
the EMSK is necessary. In the case where key caching is
used the cache
needs to be managed. If we are caching EMSKs then the
document that
describes EMSK usage must describe how key cache can be
managed.
Madjid>>I like to consider myself as an EAP keying
consumer. I don't
really know what the cryptographic requirements for MSK or
EMSK are? All
I know is that EMSK is recommended for creation of AMSK.
Hence the need
for caching EMSK for future AMSK generation instances. I
don't really
care about MSK at this point, because it is not used for
AMSKs.
> Finally I have an slight issue with the statement that
a KEY should be
> deleted so that it wont be used for other purposes. I
find that
> statements like that are an over specification. What
makes anyone
> think that making a statement that "X should/must
be deleted" is going
> to be taken more seriously then "X should/must
only be used for
> purpose X and should/must not be transported out of
Y"?
>
> I think that whether it gets deleted or not is an
implementation
> issue.
>
[Joe] The goal of the architecture is to prevent the re-use
of keys for
multiple different purposes. I agree that this is not
necessarily the
same a deletion. It is very important that keys derived
from the EMSK
don't collide purposes across applications. What happens
in a
particular AMSK branch of the key hierarchy is not
necessarily as
important since this branch is cryptographically separated
from the rest
of the system through the AMSK derivation. I think the
current text
could probably do better in motivating why it is good
practice to delete
keys.
Madjid>>Are you saying EAP keying architecture is
incapable of
supportring various keying needs? I like to have a tree with
EMSK as a
root and one per application AMSK as each branch and
hopefully
independent of other AMSKs, is that wrong?
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|