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.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
