|
List Info Thread: Re: secdir review of draft-ietf-eap-keying-18.txt (part 1)
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Re: secdir review of draft-ietf-eap-keying-18.txt (part 1) |
|
List Info Thread: Re: secdir review of draft-ietf-eap-keying-18.txt (part 1)
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
exchange.microsoft.com
To: "iesg
),
but difficult to categorize. It is not clear to me whether
this is a
tutorial on how EAP fits into (or should fit into) other
protocols, or
prescriptive as to how future EAP methods should be
specified and what the
specifications should include, or whether it is primarily
about specifying
additional characteristics of existing EAP methods (in
Appendix A). It has
elements of each. I also could not figure out whether
"Secure Association
Protocol" was a defined thing (like EAP), a way of
looking at several
layer-specific mechanisms in a uniform way, or a
recommendation for
something new to be developed. It would be nice if the
introduction could
sort all this out.
I found nothing objectionable from a security perspective.
I did find some things confusing; these might be symptoms of
real problems,
might be candidates for better explanations, or might just
be a reflection
of my density:
P12 section 1.4.1. The peer and server names define the
scope of the
exported parameters, but some existing EAP methods do not
provide such
names (or technically provide null strings). What does this
imply about the
scope of those parameters?
[BA] The presence of a null Peer-Id or Server-Id implies
that in the
process of key generation, a method-specific identity of
either the
peer, server or both was not securely confirmed.
There are potential situations in which this could occur:
1. The method does not provide for authentication of a peer
or
server method-specific identity. An example of such a
method
is EAP OTP, which only authenticates the peer identity
provided
in the EAP-Response/Identity, but does not support either a
peer
or server method-specific identity.
2. The method does not support mutual authentication.
An example would be a method utilized for emergency calling
which
only supported server authentication. In this case the
method
might provide a Server-Id (as determined from the server
certificate)
but not a Peer-Id since the identity of the peer was not
authenticated.
3. The method supports mutual authentication, but the peer
and server
identities are not securely bound to the keys generated by
the method.
An example would be a method that utilizes server-only
authentication to
establish a TLS tunnel, then completes an additional
authentication within
the tunnel, but does not mix keying material generated in
the inner
authentication with keying material from the outer
authentication in
generating the EAP method keying material (EAP/MSK). Such a
method
would have provide a Server-Id, but a null Peer-Id, since
the identity
of the peer entity contributing to the keying material was
not
securely confirmed. Note that the absence of a Peer-Id in
this case
does not necessarily imply a man-in-the-middle
vulnerability; it
may be possible for the method to prove mutual possession of
both
inner and outer keying material without actually utilizing
both to
determine the EAP method keying material.
4. The method supports mutual authentication via password or
shared
secret, but only the Peer provides a method-specific
identity. In
this case, the server is confirmed to possess the password
or
shared secret, but the server identity may not be provided.
Note
that even if the server provides its identity, the peer will
not
be able to confirm it, as would be possible if server-side
certificate
authentication was used. Nevertheless, where the server
provides its
identity and proves possession of a shared secret or
password, the
method is capable of providing a Server-Id.
In terms of clarification, I would propose to change the
text in
Section 1.4 from:
" EAP methods supporting key derivation and mutual
authentication
SHOULD export a method-specific EAP conversation
identifier known as
the Session-Id, as well as one or more peer identifiers
(Peer-Id(s))
and MAY export one or more method-specific server
identifiers
(Server-Id(s)). EAP methods MAY also support the import
and export
of channel binding parameters. EAP method specifications
developed
after the publication of this document MUST define the
Peer-Id,
Server-Id and Session-Id. The combination of the
Peer-Id(s) and
Server-Id(s) uniquely specifies the endpoints of the EAP
method
exchange when they are provided. For existing EAP
methods the Peer-
Id, Server-Id, and Session-Id are defined in Appendix
A."
To:
" EAP methods supporting key derivation and mutual
authentication
SHOULD export a method-specific EAP conversation
identifier known as
the Session-Id, as well as one or more peer identifiers
(Peer-Id(s))
and MAY export one or more method-specific server
identifiers
(Server-Id(s)). EAP methods MAY also support the import
and export
of channel binding parameters. EAP method specifications
developed
after the publication of this document MUST define the
Peer-Id,
Server-Id and Session-Id. The Peer-Id(s) and
Server-Id(s), when
provided, identify the entities involved in generating
the
keying material exported by the EAP method. For
existing
EAP methods the Peer-Id, Server-Id and Session-Id are
defined in
Appendix A."
In Section 1.4.1, change the following text from:
" Each key created within the EAP key management
framework has
a name (a unique identifier),
as well as a scope (the parties to whom the key is
available).
The scope of exported keying material and TEKs is defined
by the
authenticated
peer identities (Peer-Id(s)) and the authenticated server
identities
(Server-Id(s)), where available. Where an EAP method
that derives
keys does not provide a Server-Id,
the EAP peer will not know the identity of the EAP server
with which it
derived EAP keying material. Where an EAP method that
derives keys
does not provide a Peer-Id, the EAP server will not know
the identity
of the EAP peer with which it derived EAP keying
material."
To:
" Each key created within the EAP key management
framework has
a name (a unique identifier), as well as a scope (the
parties to whom
the key is available). The scope of exported keying
material and TEKs is
defined by the authenticated peer identities (Peer-Id(s))
and the
authenticated server identities (Server-Id(s)), where
available.
Where an EAP method that derives keys does not provide a
Server-Id,
the EAP peer will not know the identity of the EAP server
with which it
derived EAP keying material. Where an EAP method that
derives keys
does not provide a Peer-Id, the EAP server will not know
the identity
of the EAP peer with which it derived EAP keying
material.
An EAP method that satisfies the [RFC4017] mandatory
security
requirements will typically provide a non-null Peer-Id;
however
it is possible for an EAP method to satisfy the [RFC4017]
mandatory
security requirements while providing a null Server-Id.
In an EAP method where EAP keying material is generated
solely based on
a TLS exchange involving server-only certificate
authentication,
the Peer-Id would be the null string and the Server-Id(s)
would be
determined
from the server certificate. Even where
Peer-Id(s)/Server-Id(s) are
exported by an inner EAP method, if keying material
derived from the
inner exchange is not incorporated into EAP keying
material exported
by the tunnel method, then the inner identities are not
relevant for the
purpose of determining the tunnel method's
Peer-Id(s)/Server-Id(s).
This is true even if the tunnel method proves that a
single peer
or server participated in the inner and outer
authentications.
If a server identity is not claimed, the Server-Id is the
null string.
However, if a server identity is claimed and
authenticated, then a
Server-Id can be provided, even if the server only proves
possession
of a shared secret or password. For example, a method
providing
for exchange of method-specific peer and server
identities can prove
that both the peer and server possess a shared secret or
password.
In this case both a Peer-Id and Server-Id can be
provided, even
though the server identity was not confirmed as it would
be where
server certificate authentication is supported."
P13 section 1.5, 3rd paragraph: NAS-Identifier is
introduced. Is this a
fourth ID to come out of the EAP protocol (along with
Peer-ID, Server-ID,
and Session-ID), or is it something else? NAS-Identifier is
used many times
later in the document, but never appears to be defined wrt
how it relates
to EAP.
[BA] The NAS-Identifier is a Channel Binding parameter that
is treated as
an opaque blob by EAP methods. This is described in
Sections 1.4 and
5.3.3.
[Charliek]
P18 section 2.1 re: IKEv2: I believe that what EAP calls the
Peer-ID must
match what IKEv2 calls IDi.
[BA] What IKEv2 calls IDi corresponds to the
EAP-Response/Identity;
this may not be the same as the Peer-Id.
RFC 3748 notes that the contents of the
EAP-Response/Identity should only
used for routing purposes, and similar considerations apply
to IDi.
For example, the EAP-Response/Identity might be a
"decorated NAI"
as defined in RFC 4284, such as
"microsoft.com!charliek