|
List Info Thread: Issue 349: Yet more NITs
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Issue 349: Yet more NITs |
|
List Info Thread: Issue 349: Yet more NITs
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
internaut.com
Date Submitted: April 12, 2006
Reference:
Document: Keying-11
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:
Move from Section 5 to Section 1.2:
" The terms "Cryptographic binding",
"Cryptographic separation",
"Key strength" and "Mutual
authentication" are
defined in [RFC3748] and are used with the same
meaning in this document."
In Section 1.2 change "frequently" to
"also frequently"
Add the following definition of "Secure Association
Protocol":
An exchange that occurs between the EAP peer and
authenticator
in order to manage the creation and deletion of unicast and
multicast security associations.
In Section 2.1, change:
"directly from the MSK, as described in [RFC2716].
This method
is NOT RECOMMENDED, since were PPP to support caching, this
could result in stale TSKs. As a result, once the PPP
session"
To:
"directly from the MSK, as described in [RFC2716].
This method
is NOT RECOMMENDED, since if PPP were to support caching,
this
could result in TSK reuse. As a result, once the PPP
session"
In Section 2.2, change:
" This specification does not impose constraints on
the architecture of
the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. For
example, it is
possible for multiple base stations and a
"controller" (e.g. WLAN
switch) to comprise a single EAP authenticator. In such
a situation,
the "base station identity" is irrelevant to
the EAP method
conversation, except perhaps as an opaque blob to be used
in Channel
Bindings. Many base stations can share the same
authenticator
identity. As a result, lower layers need to identify EAP
peers and
authenticators unambiguously, without incorporating
implicit
assumptions about peer and authenticator
architectures."
To:
" This specification does not impose constraints on
the architecture of
the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. As a
result, lower
layers need to identify EAP peers and authenticators
unambiguously,
without incorporating implicit assumptions about peer and
authenticator architectures.
For example, it is possible for multiple base stations
and a
"controller" (e.g. WLAN switch) to comprise a
single EAP
authenticator. In such a situation, the "base
station identity" is
irrelevant to the EAP method conversation, except perhaps
as an
opaque blob to be used in Channel Bindings. Many base
stations can
share the same authenticator identity."
In Section 2.2.1, change:
" The EAP method conversation is between the EAP
peer and server, as
identified by the Peer-ID and Server-ID. The
authenticator identity,
if considered at all by the EAP method, is treated as an
opaque blob
for the purposes of Channel bindings. However, the
Secure
Association Protocol conversation is between the peer and
the
authenticator, and therefore the authenticator and peer
identities
are relevant to that exchange, and define the scope of
use of the EAP
keying material passed down to the lower layer."
To:
" The EAP method conversation is between the EAP peer
and server, as
identified by the Peer-ID and Server-ID. The
authenticator identity,
if considered at all by the EAP method, is treated as an
opaque blob
for the purposes of Channel Bindings (see Section 5.12).
However,
the Secure Association Protocol conversation is between
the peer and
the authenticator, and therefore the authenticator and
peer
identities are relevant to that exchange, and define the
scope of use
of the EAP keying material passed down to the lower
layer."
There is redundancy between Section 2.2.1 and Section 5.5,
which says:
" In order to enable key binding and authorization of
all parties, it
is RECOMMENDED that the parties use a set of identities
that are
consistent between the conversation phases."
In Section 2.2.1, Change:
"In order to ensure that lower layer identifies are
securely verified by all
parties, it is recommended that lower layers:"
To:
"In order to ensure that lower layer identities are
securely verified by all
parties, it is RECOMMENDED that the parties use a set of
identities that are
consistent between the conversation phases.
This can be achieved by:"
Delete the above paragraph from Section 5.5.
In Section 2.2.2 change:
" "virtual authenticators", the EAP peer
and authenticator may not be able
to
agree on the scope of the EAP keying material, creating
a security vulnerability. For"
To:
" "virtual authenticators", a number of
security
vulnerabilities may arise if the peer and authenticator
are not correctly identified. For "
Change:
"Several measures are recommended to address these
issues:"
To:
"in order to address these issues:"
In Section 3, change:
"key derivation, but not key management. While EAP
methods may derive keying material, EAP
does not provide for the management of exported or derived
keys."
To:
"key derivation, but does not provide for the
management of exported or
derived keys."'
In Section 3.1, delete:
"As shown in Figure 3, both the peer and authenticator
may have more
than one physical or virtual port, and as a result SHOULD
identify
themselves in a manner that is independent of their attached
ports."
This is redundant because Section 2.2.1 already states:
" Since an authenticator may have multiple ports,
the authenticator
identifier used within the Secure Association Protocol
exchange
SHOULD be distinct from any port identifier (e.g. MAC
address).
Similarly, where a peer may have multiple ports, and
sharing of EAP
keying material and parameters between peer ports of
the same link
type is allowed, the peer identifier used within the
Secure
Association Protocol exchange SHOULD also be distinct
from any port
identifier."
In Section 3.1 [b], add: "Identity verification is
discussed in Section
2.2.1."
Change:
"Use of the key naming mechanism described in this
document is RECOMMENDED."
to
"Use of the key naming mechanism described in Section
1.4.1 is RECOMMENDED."
In Section 3.1 [g] Change:
"Key resynchronization."
To:
"Key state resynchronization"
In Section 3.1 [j], add:
"See [RFC3748] Section 2.4 for more discussion."
In Section 3.4, change:
"re-key TEKs during a conversation."
To:
"re-key TEKs during an EAP conversation."
There is redundancy between Section 3.5 and Section 5.7,
which states:
" As described in [RFC3580] Section 3.17, When sent
in an Access-
Accept along with a Termination-Action value of
RADIUS-Request, the
Session-Timeout attribute specifies the maximum number
of seconds
of service provided prior to re-authentication.
[IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit
the maximum
time that EAP keying material may be cached."
In Section 3.5, change:
" On the authenticator, where EAP is used for
authentication, the
Session-Timeout value represents the maximum session
time prior to
re-authentication, as described in [RFC3580]. Where
EAP is used
for pre-authentication, the session may not start until
some future
time, or may never occur. Nevertheless, the
Session-Timeout value
represents the maximum time after which transported EAP
keying
material, and all keys calculated from it, will have
expired on the
authenticator. If the session subsequently starts, re-
authentication will be initiated once the Session-Time
has expired.
If the session never started, or started and ended, by
default keys
transported by AAA and all keys calculated from them
will be
expired by the authenticator prior to the future time
indicated by
Session-Timeout. Note that in future additional
attributes may be
specified to control the lifetime of cached keys; these
attributes
may modify the meaning of the Session-Timeout attribute
in specific
circumstances."
To:
" On the authenticator, where EAP is used for
authentication, the
Session-Timeout attribute represents the maximum
session time prior
to re-authentication. As described in [RFC3580]
Section 3.17, when
sent in an Access-Accept along with a
Termination-Action value of
RADIUS-Request, the Session-Timeout attribute specifies
the maximum
number of seconds of service provided prior to
re-authentication.
Where EAP is used for pre-authentication, the session
may not start
until some future time, or may never occur.
Nevertheless, the
Session-Timeout value represents the maximum time after
which
transported EAP keying material, and all keys
calculated from it,
will have expired on the authenticator. If the session
subsequently starts, re-authentication will be
initiated once the
Session-Time has expired. If the session never started,
or started
and ended, by default keys transported by AAA and all
keys
calculated from them will be expired by the
authenticator prior to
the future time indicated by Session-Timeout; this
feature is
utilized by [IEEE-802.11i]. Note that in future
additional
attributes may be specified to control the lifetime of
cached keys;
these attributes may modify the meaning of the
Session-Timeout
attribute in specific circumstances."
Delete the above paragraph from Section 5.7.
Combine sections 5.1 and 5.
In Section 5, Move [2] to [10] and renumber the other
threats.
Add the following additional bullets:
[8] An attacker may attempt a man-in-the-middle attack in
order to gain
access
to the network.
[9] An attacker may launch a denial of service attack
against the EAP
peer, authenticator or backend authentication server.
In Section 5.11, change:
"see [I-D.arkko-eap-service-identity-auth]."
To:
"see the discussion in Section 1.4 as well as
[I-D.arkko-eap-service-identity-auth]."
Add the following non-normative reference:
[RFC4372]
Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
Chargeable User Identity", RFC 4372, January 2006.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit: