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

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Oct 2009 16:17:48 -0400

Here is my review of the tunnel requirements document.

3.  Use Cases

   To motivate and explain the requirements in this document, a
   representative set of use cases for the EAP tunnel method are
   supplied here.  The candidate tunnel method is expected to support
   all of the use cases marked as MUST.

  The last sentence is unclear.  I would suggest saying:

   ...
   supplied here.  The candidate tunnel method is expected to support
   all of the use cases that are marked below as "MUST".

  The use of "is expected" makes it seem like it is not mandatory to
follow the following MUST requirements.  But it would be awkward to say
"it MUST support the MUSTs below".

3.1.  Password Authentication

   ...  The
   combination of the tunnel authentication and password authentication
   MUST enable mutual authentication.

  Is the restriction on the *combination*?  What is the tunnel
authentication method supports mutual authentication, and the password
authentication method does not?

  It may be better to say:

	The tunnel method MUST support mutual authentication

3.2.  Protection of Weak EAP Methods

   Some existing EAP methods have vulnerabilities that could be
   eliminated or reduced by running them inside a protected tunnel.  For
   example, a method such as EAP-MD5 does not provide mutual

  I would suggest deleting the text "a method such as".  It is redundant
with the previous "For example" phrase.

   ...  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.

  This sentence is difficult to parse.  I suggest:

   When weak methods are used, these attacks can be mitigated via
   security policies that require the method to be used only within
   a tunnel.

   ...  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.

  Is the final "and" a requirement for cryptographic bindings to be used?

3.3.  Chained EAP Methods

   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.

 Suggest replacing "he or she is using" with a passive voice "is being
used".

   ... Cryptographic binding can be used to bind the results of key
   generating methods together or to an encompassing tunnel.

  The previous sentences talk about chained methods rather than "key
generating" methods.  I suggest replacing the above sentence with:

   .. Cryptographic binding can be used to bind chained methods
   together, or to an encompassing tunnel.

3.4.  Identity Protection

   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.

  This discussion seems redundant.  Suggest replacing the text with:

   When performing an EAP authentication, the peer may want to protect
   its identity, and only disclose it to a trusted backend
   authentication server.  This process helps to maintain peer privacy.

  The following text is unclear:

   The tunnel method MUST support identity protection, ensuring that
   peer identity is not disclosed to the authenticator and any other
   intermediaries before the server that terminates the tunnel method.

  The use of "before" is ambiguous.  It could be interpreted as
"intermediaries before the server...", rather than "before the tunnel
has been terminated"

  Suggested text:

   The tunnel method MUST support identity protection, ensuring that
   peer identity is not disclosed to any intermediaries, or to the
   authenticator until the tunnel method has been completed.

  Continuing:

3.5.  Anonymous Service Access

   When network service is provided, it is sometimes desirable for any
   user to be able to gain access to the network to enable access to
   limited services emergency communication or troubleshooting
   information.

  There are a lot of "to"'s in the above sentence.  Suggested text:

   When network service is provided, it is sometimes desirable for a
   user to gain network access in order to use
   limited services emergency communication or access troubleshooting
   information.

 This paragraph contains two concepts. (1) requirements, and (2),
security analysis derived from the requirements.

   Therefore, the tunnel method SHOULD allow anonymous peers or server-
   only authentication, but still derive keys that can be used for link
   layer security.  The tunnel method MAY also allow for the bypass of
   server authentication processing on the client.  Forgoing
   authentication increases the chance of man-in-the-middle and other
   types of attacks that can compromise the derived keys used for link
   layer security.  In addition, passwords and other sensitive
   information must not be disclosed to an unauthenticated or
   unauthorized server.

  Suggested text:

   Therefore, the tunnel method SHOULD allow anonymous peers or server-
   only authentication, while still deriving keys that can be used for
   link layer security.  The tunnel method MAY also allow for the bypass
   of server authentication processing on the client.

   Forgoing user or server authentication increases the chance of
   man-in-the-middle and other types of attacks that can compromise the
   derived keys used for link  layer security.  Therefore, passwords and
   other sensitive information MUST NOT be disclosed to an
   unauthenticated server, or to a server that is not authorized to
   authenticate the user.

...

3.7.  Client Authentication During Tunnel Establishment

   In some cases the peer will have credentials usable to authenticate
   during tunnel establishment.

  I'm not sure what that sentence means.  Suggest re-wording it.

...

3.8.  Extensibility

...
   One example of a application for extensibility is credential

  Suggest "an application"

   ... Another
   use for extensibility is support for authentication frameworks other
   than EAP.

  I presume that this is "within the EAP tunnel".  Otherwise, it would
seem that the above sentence would permit replacing the tunneled method
with non-EAP methods.

4.1.1.  RFC Compliance
...
   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.

  Suggest replacing "its successor" with "any successor"

   ... 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.

  Suggest adding a qualifier after the first "This".  This... what.. ?

  Maybe "This requirement", or "The above requirement"

...

   ... This includes
   algorithms used with certificates presented during tunnel
   establishment.

  Again, this ... what?  Perhaps the following text:

   among an extensible set of cryptographic algorithms, such as
   algorithms used with certificates presented during tunnel
   establishment.

...

4.2.  Tunnel Requirements

   The following section discusses requirements for TLS Tunnel
   Establishment.

  Suggest qualifying this text.  Is a TLS method required, or simply
suggested?

4.2.1.  TLS Requirements

   The tunnel based method MUST support TLS version 1.2 [RFC5246] and
   may support earlier versions to enable the possibility of backwards
   compatibility.  The following section discusses requirements for TLS
   Tunnel Establishment.

  Suggest deleting the last sentence.  It's a repeat of the sentence
starting off Section 4.2.

   All versions of TLS meet these requirements as long as the cipher
   suites used provide strong authentication, key establishment and data
   integrity protection.

  Are we making a statement here that TLS is OK?  If the document is a
tunnel requirements document only, it may be prudent to avoid making
statements about which protocols meet the requirements.

4.2.1.1.3.  Tunnel Authentication and Key Establishment

   A tunnel method MUST provide unidirectional authentication from
   authentication server to EAP peer and mutual authentication between
   authentication server and EAP peer.

 How do these requirements interact with requirements in Section 3.5 for
anonymous network access?  Do we want to say that the tunneled method
SHOULD provide for a standardized "anonymous" user and server?

   ... The tunnel method MUST provide
   at least one mandatory to implement cipher suite that provides
   certificate-based authentication of the server and provides optional
   certificate-based authentication of the client.  Other types of
   authentication MAY be supported.

  Does this requirement for certificate-based authentication apply
*only* when TLS methods are used?  Or is it a wider requirement that the
tunneled method MUST support TLS and certificate-based methods?

  This requirement should be clarified.

4.2.1.2.  Tunnel Replay Protection

   In order to prevent replay attacks on a tunnel protocol, the message
   authentication MUST be generated using a time-variant input such as
   timestamps, sequence numbers, nonces, or a combination of these so
   that any re-use of the authentication data can be detected as
   invalid.  TLS makes use of an 8 byte sequence number to protect
   against replay.

  I'm not sure what is the purpose of the last sentence.  An example of
how to meet the requirements?  Something else?

  It may be simplest to just delete the last sentence.

4.2.1.4.  Peer Identity Privacy

  Is this section necessary?  Section 3.4 already mandates identity
protection.  I suggest moving this text into Section 3.4, or rephrasing
it so that it does not overlap with Section 3.4.

4.2.1.5.  Session Resumption

   The tunnel method MUST support TLS session resumption as defined in
   [RFC5246].

  ... if we choose a TLS-based method.  If we don't, must it still
support TLS session resumption?

  This comment is just being nit-picky to ensure that particular
solutions are not mandated by being written into the requirements document.

4.2.3.  Protection of Data External to Tunnel

   An attacker in the middle

 ... of what?  Suggest rephrasing like:

   A MitM attack can modify ...

4.3.3.  Mandatory and Optional Attributes

   The payload MUST support marking of mandatory and optional
   attributes, as well as an attribute used for rejecting mandatory
   attributes.  Mandatory attributes are attributes sent by the
   requester that the responder is expected to understand and MUST
   respond to.

  Given the uncertainty in Diameter about the meaning of "mandatory"
attributes, it would be good to be extremely clear in this document.
This document should specify the behavior carefully.  e.g. "Requestor"
and "responder".  Does that mean only the peer can mark attributes as
mandatory, and the authenticator cannot?

  The next sentence references a "NAK attribute", without previously
defining it.  The previous discussion uses the NAK attribute to reject
mandatory attributes.  If the attributes are mandatory, why are they
being rejected?  If a responder MUST respond to a mandatory attribute,
is the response marked mandatory, too?  What kind of response is adequate?

  While I can guess the intent, it may be better to rephrase the discussion.

  Suggested text:

4.3.3.  Mandatory and Optional Attributes

   The payload MUST support marking of mandatory and optional
   attributes, as well as a "NAK" attribute used to communicate
   disagreements about received attributes.

   Mandatory attributes are attributes that a receiver MUST process as
   per the specification.  Optional attributes are attributes that a
   receiver MAY ignore.

   A receiver MUST process mandatory attributes before optional ones.
   After an attribute has been processed, it SHOULD be marked as no
   longer being mandatory.  If a receiver does not process a mandatory
   attribute, it MUST ignore everything else in a request, and it MUST
   send a NAK attribute in response.  Similarly, if a receiver expects
   a mandatory attribute and does not receive one in a request, it MUST
   send a NAK attribute in the response that contains the set of
   attributes it expected to receive.

   A peer that either sends or receives a NAK attribute MUST treat
   the session as failing authentication.

   The NAK attribute MUST support a description of which mandatory
   attribute is either required, or is not supported.  The NAK attribute
   MUST be otherwise treated as an optional attribute, and it MUST NOT
   contain a NAK of the NAK attribute, in order to prevent infinite
   recursion.

...
4.3.4.  Vendor Specific Support

   The payload MUST support communication of an extensible set of
   vendor-specific attributes.  These attributes will be segmented into
   uniquely identified vendor specific name spaces.  They can be used
   for experiments or vendor specific features.

  I would suggest adding that vendor-specific attributes SHOULD NOT be
marked as being mandatory.  Or maybe even MUST NOT be marked as mandatory.

4.3.6.  Internationalization of Display Strings

   The payload MAY provide a standard attribute format that supports
   international strings.

  I would suggest changing the MAY to a SHOULD.  Not having displayable
strings is a problem of great vexation to many administrators.

4.4.  EAP Channel Binding Requirements

   The tunnel method MUST be capable of meeting EAP channel binding
   requirements described in [I-D.clancy-emu-chbind].

  Having a normative reference to an I-D is problematic.  I'm not sure
that there is any way of avoiding this, however.

4.5.1.  Security

   Many internal EAP methods have the peer send its password in the
   clear To the EAP server.

  s/To/to/

4.5.1.2.  Authentication of Server

   The EAP server MUST be authenticated before the peer can send the
   clear text password to the server.

  Suggest replacing "can send" with "sends".

4.5.1.3.  Server Certificate Revocation Checking

  Does this section apply only when TLS && certificate methods are used,
or for any method, even non-TLS, and non-certificate?  (Just to be
nit-picky again)

4.6.  Requirements Associated with Carrying EAP Methods

   The tunnel method MUST be able to carry inner EAP methods without
   modifying them.  EAP methods MUST NOT be redefined inside the tunnel.

  I would like clarification on the last sentence.  Perhaps rephrasing
it as a requirement would be good:

   EAP methods carried inside of the tunnel MUST be identical in nearly
   all respects to the same method when carried outside of the tunnel.
   The only permissible difference is that random nonces in a tunneled
   method SHOULD be calculated instead by cryptographic methods which
   bind the inner method to the outer tunnel.

4.6.1.  Method Negotiation

   The tunnel method MUST support the protected negotiation of the inner
   EAP method.  It MUST NOT allow the inner EAP method negotiation to be
   downgraded or manipulated by intermediaries.

  What is the definition of a "downgraded" EAP method?  Perhaps just
deleting that word, and leaving it as "manipulated by" would be best.

4.6.3.  Cryptographic Binding with the TLS Tunnel

  While this section is already a bit long, I think it could use
additional clarification.  It is specifying key derivation functions,
and as such, holds the possibility for interoperability issues.

   ... In
   particular, all derived keys MUST have a lifetime assigned that does
   not exceed the lifetime of any key higher in the key hierarchy, and
   MUST prevent domino effects where a compromise in one part of the
   system leads to compromises in other parts of the system.

  This is the first mention of "lifetime".  Should we state that there
is a requirement to exchange key lifetimes, too?

  The MUST comment could also be specified in a positive sense:

   ... In
   particular, all derived keys MUST have a lifetime is strictly less
   than the lifetime of any key higher in the key hierarchy,

  I'm also unsure as to how to prevent domino effects.  Is the previous
discussion on CTK_n enough of a specification to prevent domino effects?
 If not, should the definitions of CTK_n be extended?  If so, is the
following phrase necessary:

   ... and
   MUST prevent domino effects where a compromise in one part of the
   system leads to compromises in other parts of the system.

...

6.1.  Cipher Suite Selection

   TLS supports ...
   ... Since a tunnel method uses the TLS tunnel to transport
   data, ...

  Again, are we mandating TLS?  If so, this should be clarified earlier
in the document.

6.4.  Separation of TLS Tunnel and Inner Authentication Termination
...
   ... This
   may not meet the security policy of many environments."

  There is a stray " in the document.

  Alan DeKok.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 28 Oct 2009 19:27:00 -0400

Alan,

Thanks for your very thorough review. See my comments in-line. (I left a
few comments for the other authors ;))

Katrin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alan DeKok
> Sent: Tuesday, October 27, 2009 3:18 PM
> To: [email-masked]
> Subject: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt
> 
> 

[KH] Agree that your version clarifies this.
> 	The tunnel method MUST support mutual authentication

[KH] Yes, we wanted to explicitly say that the *combination* (yes,
emphasis on combination) of tunnel authentication and password
authentication MUST enable mutual authentication. I don't see any
problem with this sentence. Password-based authentications typically
provide only peer authentication, whereas tunnel protocols typically
only server authentication. A tunnel-based EAP method compliant with the
draft, MUST enable mutual authentication if password-based
authentication is used as an inner method. Password-based
authentications are especially highlighted here because there are one of
the primary use cases of tunneled authentications.

> with the previous "For example" phrase.
[KH] OK
>    security policies that require the method to be used only within
[KH] Sounds good.
>   Is the final "and" a requirement for cryptographic bindings 
[KH] Yes.
>  Suggest replacing "he or she is using" with a passive voice "is being
[KH] OK
>    together, or to an encompassing tunnel.

[KH] I think "...Cryptographic bindings can be used to bind key
generating chained methods together, or to an encompassing tunnel" is
more accurate because cryptographic bindings are only effective when
applied to key generating methods.
>    authentication server.  This process helps to maintain 
[KH] OK
>    authenticator until the tunnel method has been completed.

[KH] As far as I remember, "before" actually referred to the physical
location of an intermediary device on the communication path.
In any case, I prefer your suggested text :)

>    limited services emergency communication or access troubleshooting
[KH] OK

>    unauthenticated server, or to a server that is not authorized to
[KH] Sounds good!
>   I'm not sure what that sentence means.  Suggest re-wording it.
[KH] It refers to a mutually authenticated tunnel, i.e. the peer
authenticates already during the tunnel phase.
>    One example of a application for extensibility is credential
[KH] OK
>   Suggest replacing "its successor" with "any successor"
[KH] OK
>   Maybe "This requirement", or "The above requirement"
[KH] OK
>   Suggest qualifying this text.  Is a TLS method required, or simply

[KH] OK. See Section 4.2.1, i.e. TLS is required.
> starting off Section 4.2.

[KH] OK
> statements about which protocols meet the requirements.

[KH] TLS is the tunnel protocol that MUST be used by all EAP
tunnel-based method candidates....
> SHOULD provide for a standardized "anonymous" user and server?

[KH] Anonymous server authentication is prohibited. Anonymous peer
authentication is OK in the tunnel as long as the peer later
authenticates inside the tunnel. I don't see any conflicts here......
> tunneled method MUST support TLS and certificate-based methods?

[KH] It MUST be a TLS tunnel.
> support TLS session resumption?

[KH] Currently the draft requires a TLS-bases method!
>    A MitM attack can modify ...

[KH] OK.
>    Many internal EAP methods have the peer send its password in the
[KH] OK
>   Suggest replacing "can send" with "sends".

[KH] OK
>    bind the inner method to the outer tunnel.

[KH] I don't understand the last sentence. The cryptographic binding is
computed by the tunnel-based EAP method not by the inner method. So
calculating cryptographic bindings should not require modifications to
an inner method.
> deleting that word, and leaving it as "manipulated by" would be best.

[KH] I guess manipulated covers downgrading.
>    than the lifetime of any key higher in the key hierarchy,

[KH] OK
>    system leads to compromises in other parts of the system.
[KH] May be change to "the compromise of a key in the key hierarchy
should not affect any keys higher or at the same level in the key
hierarchy." Need to look into this...
>   Again, are we mandating TLS?  If so, this should be 

[KH] Yes we are...and I guess this has not been clear enough ;)
>   There is a stray " in the document.

[KH] good catch.
> 
>   Alan DeKok.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>