Review of draft-ietf-emu-eaptunnel-req-03
Here is my review of -03. There are still quite a few issues in this
document, including vague or unnecessary requirements. As a result,
the document isn't ready for the IESG yet.
Section 2
" Because this specification is an informational specification (not
able to directly use [RFC2119]),"
Since a large number of Informational RFCs reference RFC 2119 and use
normative language, this statement seems odd. Perhaps what it
is trying to say is that the terms don't mean the same
thing in this document as they do in RFC 2119? If that is the
case, language such as that from RFC 2989 Section 1.1 might make
sense:
Please note that the requirements specified in this document are to
be used in evaluating protocol submissions. As such, the
requirements language refers to capabilities of these protocols; the
protocol documents will specify whether these features are required,
recommended, or optional. For example, requiring that a protocol
support confidentiality is NOT the same thing as requiring that all
protocol traffic be encrypted.
A protocol submission is not compliant if it fails to satisfy one or
more of the MUST or MUST NOT requirements for the capabilities that
it implements. A protocol submission that satisfies all the MUST,
MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
said to be "unconditionally compliant"; one that satisfies all the
MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
requirements for its protocols is said to be "conditionally
compliant."
As it is, the MUST, MUST NOT, SHOULD, SHOULD NOT, etc. definitions are
confusing.
Section 3.1 Password Authentication
" Many legacy systems only support user authentication with passwords.
Some of these systems require transport of the actual username and
password to the authentication server. The tunnel method MUST support
this use case."
As currently worded, this statement is somewhat vague.
Is this statement implying that a tunnel method must support
password-only authentication (e.g. no certificates)? If so, is there
a requiremnent to support weak passwords or just pre-shared keys?
Would a tunnel method utilizing a server certificate to
create a tunnel, and doing password authentication within the tunnel
meet this requirement? What about a tunnel method utilizing a
pre-shared key ciphersuite?
" However, it MUST NOT expose the username and password to parties in
the communication path between the peer and the EAP Server and it
MUST provide protection against man-in-the-middle and dictionary
attacks."
Does this requirement apply to provisioning or just to ongoing password
authentication?
Section 3.2
" In
particular, when weak methods are used, security policies enforcing
that such methods can only be executed inside a tunnel but never
outside one are required to mitigate the attack."
The requirement that methods only be executed within a tunnel is necessary
even for strong methods, if crypto-binding isn't used.
" On the other hand,
a technical solution (so-called cryptographic bindings) can be used
whenever the inner method is not susceptible to attacks outside a
tunnel and derives keying material."
Cryptographic binding can be used whenever the inner method generates
keys. If this isn't used, then even methods not susceptible to attack
outside the tunnel should be prohibited from use outside the tunnel, or
else MiTM attacks would still be feasible.
Section 3.3
" Several circumstances are best addressed by using chained EAP
methods. For example, it may be desirable to authenticate the user
and also authenticate the device that he or she is using."
This requirement can be met by support for cryptographic binding, without
chaining of EAP methods. For example, the combination of TLS and
an inner method can support user/device auth. Given that, why is
support for chained methods a must, and not device/user auth
support?
Section 3.4
" When performing an EAP authentication, the peer may want to protect
its identity, only disclosing its identity to a trusted backend
authentication server. This helps to maintain the privacy of the
peer's identity."
Within tunneled authentication, there are a number of identities
involved. This includes the identity included in the EAP-Request/Identity,
identities used in TLS (subject and subjectAltName fields), and
identities used in the inner EAP method. To which identities does
this requirement apply?
Section 3.5
" When wireless VOIP service is provided, some regulations require any
user to be able to gain access to the network to make an emergency
telephone call."
Which regulations are being referred to? In a number of places, support
for anonymous authentication is actually being removed, not added:
http://www.ietf.org/mail-archive/web/ecrit/current/msg06378.html
Section 4.1.1
" The tunnel method MUST meet all the MUST and SHOULD requirements
relevant to EAP methods contained in the EAP Key Management Framework
[RFC5247] or its successor. The tunnel method MUST include MSK and
EMSK generation. This will enable the tunnel method to properly fit
into the EAP key management framework, maintaining all of the
security properties and guarantees of that framework."
The primary aspects of [RFC5247] that apply to EAP methods is the
generation of the Peer-Id, Server-Id and Session-Id. Why not just
spell out those requirements specifically?
" The tunnel method MUST meet the SHOULD and MUST requirements
pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962].
This includes: cryptographic algorithm independence; strong, fresh
session keys; replay detection; keying material confidentiality and
integrity; confirm cipher suite selection; and uniquely named keys."
The key naming requirement is handled by generation of the Session-Id,
so it needn't be mentioned specifically.
With respect to some of these issues, NIST 800-120 provides more
detailed and specific requirements.
Section 4.1.2
" Several existing tunnel methods are already in widespread usage: EAP-
FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP."
The definitive reference for the PEAP protocol is:
http://msdn.microsoft.com/en-us/library/cc238354(PROT.10).aspx
Section 4.2.1
" The tunnel based method MUST support TLS version 1.2 [RFC5246] and
SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to
enable the possibility of backwards compatibility with existing
deployments."
I am not sure how to interpret this requirement. Is it sufficient for
a proposal to enable negotiation of TLS 1.2 between a peer and server
that support it? Or does the protocol actually have to require that
both the peer and server implement TLS 1.2? If the former, is the
requirement really just properly supporting TLS version negotiation?
Section 4.2.1.1.2
"See Part 1 of the NIST Recommendation for
Key Management [NIST SP 800-57] for a discussion of the relative
strengths of common algorithms."
Why not reference the NIST SP 800-120 requirements here?
Section 4.2.1.1.3
" A tunnel method MUST provide unidirectional authentication from
authentication server to EAP peer or mutual authentication between
authentication server and EAP peer."
Is this really an or? For example, would a tunnel method that only
supports undirectional authentication satisfy the requirement?
"o One-way key derivation
o Cryptographically separated keys.
o Cryptographically separated entities.
o Identity binding
o Context binding
o Key lifetime
o Mutual implicit key authentication
o Key freshness"
Given that this document assumes a TLS-based tunnel method, the text
on requirements can be made considerably more specific and actionable
based on TLS properties and the specific requirements of NIST 800-120.
As it stands, a number of these requirements either don't apply to
EAP methods at all (e.g. context binding, key lifetime) but rather to other
elements of the system, or are automatically provided by TLS
(e.g. key freshness, Identity binding).
So these requirements need to be made actionable and specific. The ones
that don't apply to the problem at hand (e.g. TLS-based tunnel euth) should be
removed.
Section 4.2.1.3
" In order to meet the requirements in this document TLS extensions MAY
be used. For example, TLS extensions may be useful in providing
certificate revocation information via the TLS OCSP extension (thus
meeting the requirement in Section 4.5.1.3)."
Why is it necessary to include optional requirements in this document?
Presumably the selection will only be influenced by MUST and SHOULD
requirements, right?
Section 4.2.1.4
" A tunnel protocol MUST support peer privacy. This requires that the
username and other attributes associated with the peer are not
transmitted in the clear or to an unauthenticated, unauthorized
party. If applicable, the peer certificate is sent confidentially
(i.e. encrypted)."
Does a username of "anonymous" need to be encrypted? Or does this
requirement only apply to the tunnel method-specific identities?
Is there an issue with transmission of dientities to authenticated
and authorized parties (e.g. the NAS)? In some regulatory jurisdictions
this is also a concern.
Section 4.2.3
"If modification of this information can cause
vulnerabilities, the tunnel method MUST provide protection against
modification of this data."
This seems a bit vague. Why not just require secure confirmation of the
protocol version and/or type code, either implicitly or explicitly?
Section 4.3.3
" The payload MUST support marking of mandatory and optional
attributes, as well as an attribute used for rejecting mandatory
attributes."
Why is it necessary for mandatory and optional attributes to be explicitly
marked? Is it be sufficient for the attributes to be divided into
standardized and vendor-specific spaces, with the latter optional?
Section 4.3.6
" The payload MAY provide a standard attribute format that supports
international strings. This attribute format MUST support encoding
strings in UTF-8 [RFC3629] format. Any strings sent by the server
intended for display to the user MUST be sent in UTF-8 format and
SHOULD be able to be marked with language information and adapted to
the user's language preference."
If UTF-8 is supported, is it necessary to also mark the language?
Why is language negotiation a SHOULD?
EAP methods such as Identity & Notification don't support this.
Section 4.5
"These typically
require the password in its original text form in order to
authenticate the peer, hence they require the peer to send the clear
text user name and password to the EAP server."
One of the issues with support for cleartext passwords are the potential
attacks against the AAA backend (e.g. User-Password attribute) in split
authentication scenarios. Is it worth calling this out?
Section 4.5.2
" The password authentication exchange MUST support user names and
passwords in international languages. It MUST support encoding of
user name and password strings in UTF-8 [RFC3629] format. Any
strings sent by the server during the password exchange and intended
for display to the user MUST be sent in UTF-8 format and SHOULD be
able to be marked with language information and adapted to the user's
language preference.
"
Why is it useful to mark usernames and passwords with language
information on the wire?
Section 4.5.3
" The password authentication exchange MUST support additional
associated meta-data which can be used to indicate whether the
authentication is for a user or a machine. This allows the EAP
server and peer to request and negotiate authentication specifically
for a user or machine. This is useful in the case of multiple inner
authentications where the user and machine both need to be
authenticated.
"
Why is it necessary to support meta-data to indicate whether authentication
is for a user or machine? Few authentication protocols support this today
and don't seem to miss it. For example, does Kerberos or PKI distinguish
explicitly between user and machine credentials?
Section 4.6.2
" The tunnel method MUST support the chaining of multiple EAP methods.
The tunnel method MUST allow for the communication of intermediate
result and verification of compound binding between executed inner
methods when chained methods are employed.
"
Given that the basic use case (machine + user auth) doesn't require
chaining of EAP methods, why is this a MUST?
Section 4.6.5
" The tunnel method MUST allow for the communication of additional data
associated with an EAP method. This can be used to indicate whether
the authentication is for a user or a machine. This allows the EAP
server and peer to request and negotiate authentication specifically
for a user or machine. This is useful in the case of multiple inner
EAP authentications where the user and machine both need to be
authenticated.
"
Again, why is meta-data necessary? Can't the basic need for machine + user
auth be met without this?
Section 6.3
" The tunnel method will use data that is outside the TLS tunnel such
as the EAP type code or version numbers. If an attacker can
compromise the protocol by modifying these values the tunnel method
MUST protect this data from modification."
Why is it necessary to protect the data from modification in order to
address the attacks? For example, if the key derivation is unique to
an EAP type, then modifying the type would cause proof of key possession
to fail. Wouldn't this be sufficient?
EMAILING FOR THE GREATER GOOD
Join me
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
