Subject: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1

From: "Glen Zorn" <[email-masked]>
Date: Sun, 26 Apr 2009 10:51:08 +0700

General comments:

There are several instances of the pernicious practice of treating
references to references as if they were something other than pointers;
among the most glaring of which are found in 4.2.1.1.3: "NIST publication
[NIST SP 800-57p3] can be consulted for a list of acceptable TLS v1.0, v1.1
and v 1.2 cipher suites and NIST publication [NIST SP 800-108] for
additional information on secure key derivation."  Do these NIST
publications have names?  If so, please use them (or an appropriately
shortened version thereof), along with providing a pointer to the reference
itself.

Hyphenation needs to be checked; for example, "certificate based
authentication" makes no sense, but "certificate-based authentication" does.

Section 3.1, first paragraph, last two sentences say:

   The tunnel method MUST support this use case.
   However, it MUST NOT expose the username and password to untrusted
   parties and it MUST provide protection against man-in-the-middle and
   dictionary attacks.  The combination of the tunnel authentication and
   password authentication MUST enable mutual authentication.

By whom (or what) are the "untrusted patties" referred to not trusted?  For
example, the AAA proxies in a visited network are certainly trusted _by that
network_ (and by inference, the home network) but they may not be trusted
(at least as much) as similar entities in the home network _by the user_.
Some clarification of the trust model seems to be necessary here, especially
given the specification of absolute requirements in the text.

Same section, last paragraph, says:

   Since EAP authentication occurs before network access is granted the
   tunnel method SHOULD enable an inner exchange to provide support for
   minimal password management tasks including password change, "new PIN
   mode", and "next token mode" required by some systems.

"New token mode" and "new PIN mode" refer to the proprietary SecureID system
from RSA.  I don't know why we should be giving RSA free advertising ;-),
nor why their system deserves explicit mention.  Suggestion:

CHANGE:
change, "new PIN mode", and "next token mode" required by some systems.
TO
change and other "housekeeping" functions required by some systems.

This might also be a good place to mention that certain data related to
authorization may need to be communicated to the peer; it is forbidden to do
this in an EAP Success message, but there is no such constraint (yet) upon
the TLS tunnel.

In section 3.2, first paragraph, third sentence, 
CHANGE
special type of man-in-the-middle attacks
TO
special type of man-in-the-middle attack

Section 3.3, last sentence:
CHANGE
on the method chaining.
TO
on method chaining.

The meaning of section 3.7 isn't clear to me: what, exactly, is meant by
"client" here?  Is it the EAP peer, the client machine, both or neither?  Is
it the user?  If so, then that would seem to make a tunneled method
unnecessary, except possibly for transmitting other data.

Section 3.8, first sentence of first paragraph says:

   The tunnel method MUST provide extensibility so that additional types
   of data can be carried inside the tunnel in the future.  

This statement seems awfully broad to me.  Do we really mean _any_
"additional types of data" or is it "additional types of security-related
data" or maybe "additional types of data related to network access"?

Section 4.1.1, third paragraph says:

   The tunnel method MUST meet all the EAP method requirements 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.

While it is undoubtedly tempting to simply require compliance with RFC 5247,
given the rather incredible amount of drivel and nonsense present in that
RFC, it might be a better idea to be specific about precisely what
requirements need to be satisfied.

Same section, last paragraph: same comment as the last, but in spades.  Just
one example that leaps out: Section 4.1.1, 4th paragraph of the draft in
question says "The tunnel method MUST NOT be tied to any single
cryptographic algorithm." and the last paragraph says "The tunnel method
MUST meet requirements pertinent to EAP method contained in Section 3 of RFC
4962 [RFC4962].  This includes: cryptographic algorithm independence..." but
the subsection on algorithm independence in Section 3 of RFC 4962 says
"...an EAP method MAY depend on a specific cryptographic algorithm."  While
this specific contradiction might be addressed by adding a sentence stating
that conflicts are resolved in favor of this draft other, more subtle
problems might not.

~gwz

Play assigns meaning to human activity--work erases it.
  -- P.L. Wilson