Thanks Dan, I haven't seen any responses on the list yet so I provided some inline below.
> -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Dan > Harkins > Sent: Monday, November 30, 2009 12:57 PM > To: emu@ietf.org > Subject: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Hello, > > I made some of these comments at the mic in Hiroshima but was > asked to submit them to the list. > > - I get the feeling that this document is being written to > ensure some end-game and not simply as a protocol requirements > document. > > I mentioned that it would be nice if the tunneled method > described a way to establish an EAP-TLS -style connection, > either anonymous or server-side-auth-only, and then allow > for subsequent authentication using another EAP method (or > using specific TLVs for some password authentication) or > EAP methods chained together by the tunnel. Pasi said that > is the intention but it sure doesn't seem that way. > [Joe] Currently the scope of the work does not include anonymous authentication. I think this could be follow-on work to the tunnel method. I don't think the current document should prohibit anonymous cipher suites from being used in follow-on specifications. See the response to 4.2.1.1.3 for some suggested text. > - section 3.4 states that the tunnel method MUST ensure "that > peer identity is not disclosed to the authenticator and any > other intermediaries before the server that terminates the > tunnel method." > > EAP is supposed to be a 2 party protocol that, for optimization, > can have functionality split between a pass-thru authenticator > and a EAP method-terminating server. But it seems wrong to > put forth the optimization as if it's a requirement for the > tunnel method. > > Please change this to something like "the identity of the peer > used for authentication purposes MUST NOT be obtainable by any > entity other than the EAP server terminating the tunnel method." > [Joe] OK > - 3.6 seems somewhat pointless. "The tunnel method SHOULD support > carrying of NEA protocols" and "these protocols may be required > to be carried in an EAP method." > > Since the tunneled EAP method can tunnel EAP methods then this > "requirement" should just naturally flow out of another requirement. > Please remove section 3.6. > [Joe] While, it is true that carrying NEA protocols should be met by either the extensibility or carrying EAP method requirements, I believe that NEA use case is pertinent to the tunnel method work and should be mentioned somewhere in the document. What is the harm in mentioning it here? > - 3.7 describes "credentials [that] may only partially authenticate > the identity of the peer". > > Huh? What kind of credentials are these? Please describe these > credentials. > [Joe] OK > Additionally, "the tunnel may be used to communicate additional > data". > > This is so vague as to be meaningless. A nonce could satisfy > this "requirement", and so could 8 bits of RESERVED-- set to zero > before transmitting and ignored upon receipt-- for that matter. > Please remove this. > [Joe] Removed > - 3.8 mentions a use of "extensibility is support for authentication > frameworks other than EAP." > > That seems like a huge stretch of the work we are chartered to do. > I suggest that line be removed. > [Joe] Alan had a similar comment that this text is confusing. The suggest text is: " Another use for extensibility is support for alternate authentication frameworks within the tunnel." > - 4.1.2 is inappropriate. It is not the purpose of a document describing > the requirements for a protocol to direct the working group how to > evaluate potential protocols against those requirements. > > When I brought this up in Hiroshima a response was (I paraphrase), > "that the working group had consensus to use existing work and so > this is just a restatement of that consensus." Which raises another > interesting point without addressing my comment. That other point is > that if there is working group consensus then it is not necessary to > have section 4.1.2 then. The fact that 4.1.2 is in the document leads > one to believe that perhaps there is a fear that such support might > have evaporated. > > The working group does not need to be constrained in its decision- > making process. The process is defined and understood and it is > inappropriate for a _protocol requirements document_ to say, "hey > remember way back when a sample of active participants seemed to > agree on a vague concept, well now you SHOULD select one of the two > candidates here." > > Please remove 4.1.2. > [Joe] Needs more discussion. > - 4.2.1.1.1 if TLS is required and "[a]ll versions of TLS meet > [cipher suite negotiation] requirements" then what's the point of > this section? > > Please remove section 4.2.1.1.1. > [Joe] I think the comment is still relevant, suggested text: " TLS provides protected cipher suite negotiation as long as all the cipher suites supported provide strong authentication, key establishment and data integrity protection." > - 4.2.1.1.3 begins saying "A tunnel method MUST provide unidirectional > authentication from authentication server to EAP peer and mutual > authentication between authentication server and EAP peer." > > This is a nonsense statement. Either it's unidirectional or it's > mutual, it can't be both. > > Additionally, it says "mandatory to implement cipher suites MUST NOT > include...mutually anonymous authentication...." > > Seeing as how this subsection is under 4.2.1 and 4.2.1.1.1 describes > these as TLS cipher suites then I really think this should be changed. > An anonymous TLS cipher suite negotiated by the EAP tunnel method > will be extremely valuable when combined with something like EAP-pwd > as the inner method. That would provide a way to securely satisfy the > credential provisioning requirement (which is a MUST by the way). > > Please restate the requirement to say something along the lines of > "if an anonymous TLS ciphersuite is used by the outer tunnel then an > inner method providing mutual authentication MUST be used." > [Joe] I agree that anonymous cipher suites might be useful in the context you describe. I do not that this is the main purpose of the tunnel method work. I think this would be done in a separate document building on top of the tunnel method. I can see how the existing text might be a bit problematic, but your suggested text makes me a bit nervous because it may require more consideration. How about something along the lines of: "Other specifications may define uses of the tunnel method the build on anonymous cipher suites. These specifications must take care to address the security issues inherent in anonymous cipher suites. " > - 4.2.1.2 requires replay protection and then goes on to say that TLS > (which is required by 4.2.1) satisfies this requirement. > > Please remove 4.2.1.2 since it does not add a new requirement. > [Joe] Suggested Text: " TLS provides sufficient replay protection to meet this requirements as long as strong cipher suites are used." > regards, > > Dan. > > > > > _______________________________________________ > 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
