Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04

["Joseph Salowey (jsalowey)" <[e-mail]>]

Thanks Dan,

I haven't seen any responses on the list yet so I provided some inline
below. 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
Dan
> Harkins
> Sent: Monday, November 30, 2009 12:57 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu