One of the motivations behind the EAP Key Management Framework document is
to analyze compliance of existing EAP/AAA RFCs and lower layer standards
(e.g. IEEE 802.11i, IEEE 802.16e, IKEv2, etc.) to the requirements
described in Guidelines for AAA Key Management,
draft-housley-aaa-key-mgmt.
Vidya, I found the model you proposed didn't fit what Dan was talking
about very well. In particular, Dan wants to focus on problems
resulting from the fact that the name of the authenticator used
between the peer and the authenticator may be different than the name
of the authenticator used
Sam,
The problem of an entity in the middle giving disparate information to
the peer and the server is in fact easier to solve than the problem
Vidya summarized. The disparate information problem has been described
in the EAP Keying Framework document and elsewhere too.
To my
There are some countries that require not just a *valid* passport, but
one which won't
expire for 6 months beyond when you visit a country. Is Prague in one
of these countries (for US citizens)?
I've heard conflicting things.
If it does have the requirement (that a passport has to be valid
http://travel.state.gov/travel/cis_pa_tw/cis/cis_1099.html
3 months is the requirement.
At 09:03 PM 2/17/2007, Radia Perlman wrote:
There are some countries that require not just a *valid* passport,
but one which won't
expire for 6 months beyond when you visit a country. Is Prague in
one
Yes, the problem of an authenticator providing different identities to
the peer and the server is the typical channel binding problem and can
be detected by simply doing a protected exchange of the identity between
the peer and server. When such a discrepancy is detected, then, keys
won't be
