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

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

Hi Dan,

It is not secure, even *with* cryptographic bindings.

The very least a MitM attacker can do is get the identities of both
parties exchanged inside the tunnel -> i.e. breaking the privacy of both
parties and thus rendering the anonymous tunnel useless. This is
*always* possible!

If the inner method derives no keys or has a weak key establishment,
then the MitM can break the entire session, deriving all keys and
staying undetected while listening to the rest of the session.

Considering the attack, I don't see what mutually anonymous tunnels can
achieve what a server-authenticated tunnels couldn't.
I guess you need to convince me of the value of mutually anonymous
tunnels in which an MitM can get all exchanged identifiers in order to
change my mind :)

The attack is described in the reference I provided in my last email.
NIST SP 800-120 does no permit mutually anonymous tunnels for exactly
that reason.

And our requirements draft shouldn't either. 

Katrin

PS: If you want to talk about using certified pseudonyms, that is a
different story.

------------------------------------------------------------------------
-
Details of the attack (for a complete discussion, please read the paper)

The MitM attacker establishes a tunnel with the peer and another one
with the server using a mutually anonymous tunnel protocol. 
The peer authentication and server authentication now takes place inside
the two tunnel segments. The MitM needs to decrypt and re-encrypt all
messages in order to forward a message from one tunnel into the other
tunnel. Server and peer would not notice. 
The MitM does *not* impersonate any party but has full access to all
information inside the tunnel, including the exchanged identifiers.

Let's say crypto bindings are used. Only if the derived inner key IK
cannot be derived by the MitM, i.e. the key derivation algorithm is
cryptographically strong, the attack will be detected. However, by then
the MitM is already in possession of the identifiers that have been
"anonymously" exchanged inside the tunnel. Besides, many inner methods
only have weak inner key derivations (that's why they are tunneled) or
do not derive a key at all. In these cases, the attacker is able to
derive the cryptographic bindings for both tunnel segments and keep
fooling peer and server.




> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Tuesday, March 02, 2010 7:10 PM
> To: Hoeper Katrin-QWKN37
> Cc: Joseph Salowey; Dan Harkins; [e-mail]
> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> 
>   Hi Katrin,
> 
>   Section 4.6.3 will address a man-in-the-middle attack against an
> anonymous TLS tunnel followed by a mutually-authenticating and key
> generating EAP method, like EAP-pwd. The keying material from both
> the anonymous tunnel and the tunneled EAP method will be mixed
> together (according to 4.6.3) to derive an MSK and EMSK.
> 
>   The value is that such a technique can be used for initial
credential
> provisioning. And it is secure. Please reconsider your opposition to
> allowing this technique.
> 
>   regards,
> 
>   Dan.
> 
> On Tue, March 2, 2010 7:03 am, Hoeper Katrin-QWKN37 wrote:
> > 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
> >
>