ietf
[Top] [All Lists]

RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

2006-11-17 10:20:24
Hi Russ,

And how would we apply this to EAP? There is no authenticator ID known to
EAP peer, yet they share an MSK.

I believe that this is being addressed in draft-ietf-eap-keying.

Can you please provide a pointer? 

It has peer-id and server-ids defined. But even that has issues, as these
are EAP-method exports, and not always available. 

            o  The expected lifetime of the keying material.

Does it make sense to mention something like "Lifetime of a child key
MUST
NOT be greater than the lifetime of its parent in the key hierarchy."?

This is a very good principle, but I think SHOULD NOT is more appropriate.

I'm wondering why we open the door for children keys living longer than the
parent key.
 
         For this reason, EAP methods SHOULD
         provide a mechanism for identity protection of EAP peers, but
         such protection is not a requirement.


"SHOULD" and "not a requirement" seem to clash. We should either make it
a
"MAY", or remove the ",but ...".

All methods do not have to have a mechanism for identity protection,
but we encourage them to have one.

I understand. What is the affect of "SHOULD but not a requirement"? Is this
like a "SHOULD-"? I mean, what do we lose if we drop the "but such a
protection is not a requirement"? 

Regards,

Alper




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>