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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > Behalf Of Alan DeKok > Sent: Tuesday, October 27, 2009 3:18 PM > To: emu@ietf.org > Subject: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt > > > 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". [KH] Agree that your version clarifies this. > > > 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 [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. > > 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. > > [KH] OK > ... 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. > [KH] Sounds good. > > ... 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? [KH] Yes. > > 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". [KH] OK > > ... 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. [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. > > 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. > [KH] OK > 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. [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 :) > > 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. > [KH] OK > 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. > > ... [KH] Sounds good! > > 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. > [KH] It refers to a mutually authenticated tunnel, i.e. the peer authenticates already during the tunnel phase. > ... > > 3.8. Extensibility > > ... > One example of a application for extensibility is credential > > Suggest "an application" [KH] OK > > > ... 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" [KH] OK > > ... 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" > > ... [KH] OK > > ... 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? [KH] OK. See Section 4.2.1, i.e. TLS is required. > > 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. [KH] OK > > 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. [KH] TLS is the tunnel protocol that MUST be used by all EAP tunnel-based method candidates.... > > > 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? [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...... > > ... 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? [KH] It MUST be a TLS tunnel. > > 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? [KH] Currently the draft requires a TLS-bases method! > > 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 ... [KH] OK. > > > 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/ [KH] OK > > 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". [KH] OK > > 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. [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. > > 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. [KH] I guess manipulated covers downgrading. > > 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, [KH] OK > > 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. [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... > > ... > > 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. [KH] Yes we are...and I guess this has not been clear enough ;) > > 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. [KH] good catch. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
