Subject: [Emu] Review of draft-ietf-emu-eaptunnel-req

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Jul 2009 16:50:30 -0700

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