The text of issue 394 is enclosed below. The proposed
resolution is as
follows:
In Section 5.1, replace:
" Requirement: In the event that an authenticator is
compromised or
stolen, an attacker may gain access to the network
through that
authenticator, or may obtain the credentials required for
the
authenticator/AAA client to communicate with one or more
backend
authentication servers. Similarly, if a peer is
compromised or
stolen, an attacker may obtain credentials required to
communicate
with one or more authenticators. Compromise of a single
peer MUST
NOT compromise keying material held by any other peer
within the
system, including session keys and long-term keys, with
the possible
exception of group keys. Likewise, compromise of a
single
authenticator MUST NOT compromise keying material held by
any other
authenticator within the system. In the context of a key
hierarchy,
this means that the compromise of one node in the key
hierarchy must
not disclose the information necessary to compromise
other branches
in the key hierarchy. Obviously, the compromise of the
root of the
key hierarchy will compromise all of the keys; however, a
compromise
in one branch MUST NOT result in the compromise of other
branches.
There are many implications of this requirement; however,
two
implications deserve highlighting. First, the scope of
the keying
material must be defined and understood by all parties
that
communicate with a party that holds that keying material.
Second, a
party that holds keying material in a key hierarchy must
not share
that keying material with parties that are associated
with other
branches in the key hierarchy."
With:
" Requirement: In the event that an authenticator is
compromised or
stolen, an attacker can gain access to the network
through that
authenticator, or can obtain the credentials needed for
the
authenticator/AAA client to communicate with one or more
backend
authentication servers. Similarly, if a peer is
compromised or
stolen, an attacker can obtain credentials needed to
communicate with
one or more authenticators. As noted in
[I-D.housley-aaa-key-mgmt]
Section 3:
Compromise of a single peer MUST NOT compromise keying
material
held by any other peer within the system, including
session keys
and long-term keys. Likewise, compromise of a single
authenticator MUST NOT compromise keying material held
by any
other authenticator within the system. In the context
of a key
hierarchy, this means that the compromise of one node
in the key
hierarchy must not disclose the information necessary
to
compromise other branches in the key hierarchy.
Obviously, the
compromise of the root of the key hierarchy will
compromise all of
the keys; however, a compromise in one branch MUST NOT
result in
the compromise of other branches. There are many
implications of
this requirement; however, two implications deserve
highlighting.
First, the scope of the keying material must be
defined and
understood by all parties that communicate with a
party that holds
that keying material. Second, a party that holds
keying material
in a key hierarchy must not share that keying material
with
parties that are associated with other branches in the
key
hierarchy.
Group keys are an obvious exception. Since all
members of the
group have a copy of the same key, compromise of any
one of the
group members will result in the disclosure of the
group key."
In Section 5.2, replace:
" Requirement: The ability to negotiate cryptographic
algorithms
resilience against compromise of a particular algorithm.
This is
usually accomplished by including an algorithm identifier
and
parameters in the protocol, and by specifying the
algorithm
requirements in the protocol specification. While highly
desirable,
the ability to negotiate key derivation functions (KDFs)
is not
required. For interoperability, at least one suite of
mandatory-to-
implement algorithms MUST be selected. The selection of
the "best"
cryptographic algorithm SHOULD be securely confirmed.
The mechanism
SHOULD detect attempted roll back attacks."
with:
" Requirement from [I-D.housley-aaa-key-mgmt] Section
3:
The AAA key management protocol MUST be cryptographic
algorithm
independent. However, an EAP method MAY depend on a
specific
cryptographic algorithm. The ability to negotiate the
use of a
particular cryptographic algorithm provides resilience
against
compromise of a particular cryptographic algorithm.
Algorithm
independence is also REQUIRED with a Secure
Association Protocol
if one is defined. This is usually accomplished by
including an
algorithm identifier and parameters in the protocol,
and by
specifying the algorithm requirements in the protocol
specification. While highly desirable, the ability to
negotiate
key derivation functions (KDFs) is not required. For
interoperability, at least one suite of
mandatory-to-implement
algorithms MUST be selected... The selection of the
"best"
ciphersuite SHOULD be securely confirmed. The
mechanism SHOULD
detect attempted roll back attacks."
In Section 5.3, replace:
" Requirement: Each party in the EAP, AAA and Secure
Association
Protocol conversations MUST be authenticated to the other
parties
with whom they communicate. Authentication mechanisms
MUST maintain
the confidentiality of any secret values used in the
authentication
process. When a Secure Association Protocol is used to
establish
session keys, the parties involved in the secure
association protocol
MUST identify themselves using identities that are
meaningful in the
lower layer protocol environment that will employ the
session keys.
While preserving algorithm independence, confidentiality
and
integrity of all keying material MUST be
maintained."
With:
" Requirement: Each party in the EAP, AAA and Secure
Association
Protocol conversations MUST be authenticated to the
other parties
with whom they communicate. As noted in
[I-D.housley-aaa-key-mgmt]
Section 3:
Authentication mechanisms MUST maintain the
confidentiality of any
secret values used in the authentication process.
When a secure association protocol is used to
establish session
keys, the parties involved in the secure association
protocol MUST
identify themselves using identities that are
meaningful in the
lower layer protocol environment that will employ the
session
keys. In this situation, the authenticator and peer
can be known
by different identifiers in the AAA protocol
environment and the
lower layer protocol environment, making authorization
decisions
difficult without a clear key scope. If the lower
layer
identifier of the peer will be used to make
authorization
decisions, then the pair of identifiers associated
with the peer
MUST be authorized by the authenticator and/or the AAA
server.
Authentication mechanisms MUST NOT employ plaintext
passwords.
Passwords may be used provided that they are not sent
to another
party without confidentiality protection... While
preserving
algorithm independence, confidentiality and integrity
of all
keying material MUST be maintained."
In Section 5.4, replace:
" Requirement: Keying material MUST be bound to the
appropriate
context. Any party with legitimate access to keying
material can
determine its context. In addition, the protocol MUST
ensure that
all parties with legitimate access to keying material
have the same
context for the keying material. This requires that the
parties are
properly identified and authenticated, so that all of the
parties
that have access to the keying material can be
determined. The
context includes the following:
o The manner in which the keying material is expected
to be used.
o The other parties that are expected to have access
to the keying
material.
o The maximum lifetime of the keying material. The
maximum
lifetime of a child key SHOULD NOT be greater than the
maximum
lifetime of its parent in the key hierarchy."
With:
" Requirement from [I-D.housley-aaa-key-mgmt] Section
3:
Keying material MUST be bound to the appropriate
context. The
context includes the following:
o The manner in which the keying material is expected
to
be used.
o The other parties that are expected to have access
to
the keying material.
o The expected lifetime of the keying material.
Lifetime
of a child key SHOULD NOT be greater than the
lifetime of
its parent in the key hierarchy.
Any party with legitimate access to keying material
can determine
its context. In addition, the protocol MUST ensure
that all
parties with legitimate access to keying material have
the same
context for the keying material. This requires that
the parties
are properly identified and authenticated, so that all
of the
parties that have access to the keying material can be
determined.
The context will include the peer and NAS identities
in more than
one form. One (or more) name form is needed to
identify these
parties in the authentication exchange and the AAA
protocol.
Another name form may be needed to identify these
parties within
the lower layer that will employ the session
key."
In Section 5.5, replace:
" Requirement: Peer and authenticator authorization
MUST be performed.
These entities MUST demonstrate possession of the
appropriate keying
material, without disclosing it. Authorization is
REQUIRED whenever
a peer associates with a new authenticator. The
authorization
checking prevents an elevation of privilege attack, and
it ensures
that an unauthorized authenticator is detected.
Authorizations
SHOULD be synchronized between the EAP peer, server, and
authenticator. Once all protocol exchanges are complete,
all of
these parties should hold a common view of the
authorizations
associated the other parties. The Secure Association
Protocol (phase
2) conversation may utilize different identifiers from
the EAP
conversation (phase 1a), so that binding between the EAP
and Secure
Association Protocol identities is REQUIRED."
With:
" The Secure Association Protocol (phase
2) conversation may utilize different identifiers from
the EAP
conversation (phase 1a), so that binding between the EAP
and Secure
Association Protocol identities is REQUIRED."
As noted in [I-D.housley-aaa-key-mgmt] Section 3:
Peer and authenticator authorization MUST be
performed. These
entities MUST demonstrate possession of the
appropriate keying
material, without disclosing it. Authorization is
REQUIRED
whenever a peer associates with a new authenticator.
The
authorization checking prevents an elevation of
privilege attack,
and it ensures that an unauthorized authenticator is
detected.
Authorizations SHOULD be synchronized between the
peer, NAS, and
backend authentication server. Once the AAA key
management
protocol exchanges are complete, all of these parties
should hold
a common view of the authorizations associated the
other parties.
In addition to authenticating all parties, key
management
protocols need to demonstrate that the parties are
authorized to
possess keying material. Note that proof of
possession of keying
material does not necessarily prove authorization to
hold that
keying material. For example, within an IEEE 802.11i,
the 4-way
handshake demonstrates that both the peer and
authenticator
possess the same EAP keying material. However, by
itself, this
possession proof does not demonstrate that the
authenticator was
authorized by the backend authentication server to
possess that
keying material. As noted in [RFC3579] Section 4.3.7,
where AAA
proxies are present, it is possible for one
authenticator to
impersonate another, unless each link in the AAA chain
implements
checks against impersonation. Even with these checks
in place, an
authenticator may still claim different identities to
the peer and
the backend authentication server. As described in
[RFC3748]
Section 7.15, channel binding enables the peer to
verify that the
authenticator claim of identity is both consistent and
correct."
In Section 5.6, replace:
" Requirement: Exchanges MUST be replay protected,
including AAA, EAP
and Secure Association Protocol exchanges. Replay
protection allows
a protocol message recipient to discard any message that
was recorded
during a previous legitimate dialogue and presented as
though it
belonged to the current dialogue."
With:
" Requirement from [I-D.housley-aaa-key-mgmt] Section
3:
The AAA key management protocol exchanges MUST be
replay
protected, including AAA, EAP and Secure Association
Protocol
exchanges. Replay protection allows a protocol
message recipient
to discard any message that was recorded during a
previous
legitimate dialogue and presented as though it
belonged to the
current dialogue."
In Section 5.7, replace:
" Requirement: While preserving algorithm
independence, session keys
MUST be strong and fresh. A session key SHOULD be
considered
compromised if it remains in use beyond its authorized
lifetime.
Each session deserves an independent session key;
disclosure of one
session key MUST NOT aid the attacker in discovering any
other
session keys. Fresh keys are required even when a long
replay
counter (that is, one that "will never wrap")
is used to ensure that
loss of state does not cause the same counter value to be
used more
than once with the same session key. A fresh
cryptographic key is
one that is generated specifically for the intended use.
In this
situation, a secure association protocol is used to
establish session
keys. The AAA protocol and EAP method MUST ensure that
the keying
material supplied as an input to session key derivation
is fresh, and
the secure association protocol MUST generate a separate
session key
for each session, even if the keying material provided by
EAP is
cached."
With:
" Requirement: A session key SHOULD be considered
compromised if it
remains in use beyond its authorized lifetime. As noted
in [I-
D.housley-aaa-key-mgmt] Section 3:
While preserving algorithm independence, session keys
MUST be
strong and fresh. Each session deserves an
independent session
key. Fresh keys are required even when a long replay
counter
(that is, one that "will never wrap") is
used to ensure that loss
of state does not cause the same counter value to be
used more
than once with the same session key.
Some EAP methods are capable of deriving keys of
varying strength,
and these EAP methods MUST permit the generation of
keys meeting a
minimum equivalent key strength. BCP 86 [RFC3766]
offers advice
on appropriate key sizes. The National Institute for
Standards
and Technology (NIST) also offers advice on
appropriate key sizes
in [SP800-57].
A fresh cryptographic key is one that is generated
specifically
for the intended use. In this situation, a secure
association
protocol is used to establish session keys. The AAA
protocol and
EAP method MUST ensure that the keying material
supplied as an
input to session key derivation is fresh, and the
secure
association protocol MUST generate a separate session
key for each
session, even if the keying material provided by EAP
is cached. A
cached key persists after the authentication exchange
has
completed. For the AAA/EAP server, key caching can
happen when
state is kept on the server. For the NAS or client,
key caching
can happen when the NAS or client does not destroy
keying material
immediately following the derivation of session keys.
Session keys MUST NOT be dependent on one another.
Multiple
session keys may derived from a higher-level shared
secret as long
as a one-time value, usually called a nonce, is used
to ensure
that each session key is fresh. The mechanism used to
generate
session keys MUST ensure that the disclosure of one
session key
does not aid the attacker in discovering any other
session keys."
In Section 5.8, replace:
" Requirement: Following the principle of least
privilege, parties MUST
NOT have access to keying material that is not needed to
perform
their role. A party has access to a particular key if it
has access
to all of the secret information needed to derive it.
Any protocol
that is used to establish session keys, MUST specify the
scope for
session keys, clearly identifying the parties to whom the
session key
is available."
With:
" Requirement from [I-D.housley-aaa-key-mgmt] Section
3:
Following the principle of least privilege, parties
MUST NOT have
access to keying material that is not needed to
perform their
role. A party has access to a particular key if it
has access to
all of the secret information needed to derive it.
Any protocol that is used to establish session keys,
MUST specify
the scope for session keys, clearly identifying the
parties to
whom the session key is available."
In Section 5.9, replace:
" Requirement: A robust key naming scheme is REQUIRED,
particularly
where key caching is supported. The key name provides a
way to refer
to a key in a protocol so that it is clear to all parties
which key
is being referenced. Objects that cannot be named cannot
be managed.
All keys MUST be uniquely named, and the key name MUST
NOT directly
or indirectly disclose the keying material. If the key
name is not
based on the keying material, then one can be sure that
it cannot be
used to assist in a search for the key value."
With:
" Requirement from [I-D.housley-aaa-key-mgmt] Section
3:
AAA key management proposals require a robust key
naming scheme,
particularly where key caching is supported. The key
name
provides a way to refer to a key in a protocol so that
it is clear
to all parties which key is being referenced. Objects
that cannot
be named cannot be managed. All keys MUST be uniquely
named, and
the key name MUST NOT directly or indirectly disclose
the keying
material. If the key name is not based on the keying
material,
then one can be sure that it cannot be used to assist
in a search
for the key value."
=================
Issue 394: Guidelines Sync
Submitter name: Bernard Aboba
Submitter email address: aboba internaut.com
Date Submitted:
Reference:
Document: KEYING-18
Comment type: Technical
Priority: S
Section: 5
Rationale/Explanation of issue:
Keying-08 was based on the -06 version of the Guidelines for
AAA Key
management document, which is now at -09. When the
Guidelines for AAA Key
Management document is approved for publication as an RFC,
the requirements
text in Section 5 of the EAP Key Management Framework
document will need to
be updated to reflect the changes to the Guidelines
requirements.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
