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

["Hoeper Katrin-QWKN37" <[e-mail]>]

Dan,

The current text allows server-side only authentication for the tunnel,
i.e. the peer can remain anonymous during that phase and only transmit
its credential inside the tunnel. This enables peer privacy.

I think what you are talking about is mutually anonymous tunnels, i.e.
both peer and server remain anonymous during the tunnel establishment.
These types of tunnels are prone to man-in-the-middle attacks in which
the privacy of both tunnel endpoints is compromised. I don't see any
value of those anonymous tunnels. In fact they are not secure.

I strongly oppose to allowing these tunnels and believe that the current
text about this topic should be kept as is.

Best regards,
Katrin

PS: Details on the mentioned MitM attacks are in
http://portal.acm.org/citation.cfm?id=1577285



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Monday, March 01, 2010 11:53 PM
> To: Dan Harkins; [e-mail]
> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> 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
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu