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

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

Dan,

OK, I understand that the tunnel provides all these other feats.

But why can't the server authenticate during the tunnel protocol? I
still don't understand the use case for mutually anonymous tunnels.

If the server has a certificate why can't it send it to the peer before
or during the tunnel establishment?
If the peer and server share a secret, than this could be used to
establish the tunnel.

What I am saying is what kind of server authentication credentials could
be used inside an anonymous tunnel that could not be used to
authenticate the server in the tunnel protocol? (given that privacy is
not the issue)

Katrin

> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Wednesday, March 03, 2010 1:20 PM
> To: Hoeper Katrin-QWKN37
> Cc: Dan Harkins; Joseph Salowey; [e-mail]
> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> 
>   Hi Katrin,
> 
>   The tunneled method for which these requirements are being defined
> will do more than simply authentication. Sections 3.6 and 3.8 are a
> good example. It is not possible to do these things with an EAP method
> that, while generating a strong secret and being resistant to
dictionary
> attack, just does authentication (viz, EAP-pwd).
> 
>   So the existence of the tunnel is being leveraged to do all this
other
> stuff: "additional data related to authentication, authorization
> and network access can be carried inside the tunnel". That's the
benefit.
> It's the tunnel, not the anonymity of the tunnel. And since all this
> extra stuff will be protected by a key generated per section 4.6.3
then
> we have security and utility (at the modest cost of a potential loss
of
> identity).
> 
>   regards,
> 
>   Dan.
> 
> On Wed, March 3, 2010 10:25 am, Hoeper Katrin-QWKN37 wrote:
> > Dan,
> >
> > So you say that there are use cases for mutually anonymous tunnels
> > besides providing privacy (b/c as we have established they don't
provide
> > that).
> >
> > You use credential provisioning as an example. However, in your
example,
> > a server's certificate does not need to be pre-installed on a peer,
> > instead a root certificate of the CA is sufficient to be able to
verify
> > the server's certificate. How does the mutually anonymous tunnel
address
> > the problem of installing root certificates? Certificates can be
send
> > outside tunnels if privacy is no concern.
> >
> >
> > OK, let's assume there are valid use cases, then the conditions for
the
> > inner methods must be:
> >
> > -strong mutual authentication
> > -strong key establishment
> >
> >
> > Among other things, strong implies there can't be any OFF-LINE
> > dictionary attacks.
> >
> > Most importantly, such an inner method does not need to be protected
by
> > a tunnel!
> >
> > I still don't understand what good this anonymous tunnel does for
> > credential provisioning.
> >
> > Katrin
> >
> >
> >> -----Original Message-----
> >> From: Dan Harkins [mailto:[e-mail]]
> >> Sent: Wednesday, March 03, 2010 11:54 AM
> >> To: Hoeper Katrin-QWKN37
> >> Cc: Dan Harkins; Joseph Salowey; [e-mail]
> >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> >>
> >>
> >>   Hi Katrin,
> >>
> >>   Let's not consider methods that derive no keys or do weak key
> >> establishment. We can make say that you MUST use an exchange that
> >> performs mutual authentication, generates a strong key, and is
> >> resistant to dictionary attack.
> >>
> >>   So all that's left is an "attack" that learns the identities used
> >> in the exchange, that is all. Identity protection may be important
to
> >> some people but it may not be important to some other people. More
> >> importantly, potentially exposing one's identity may be a
completely
> >> reasonable price to pay to get the value this combination supplies.
> >> It would be prudent to mention the lack of identity protection when
> >> using an anonymous tunnel + strong inner EAP method but forbidding
it
> >> because someone else may not want their identity known is overkill.
> >>
> >>   Credential provisioning is currently a MUST in the draft. How
does
> >> one do initial credential provisioning? Do we always assume that
> >> a trusted certificate of the server has been properly installed on
> >> the client's computer prior to initial authentication for this
> >> "credential provisioning" to work? That assumption has not worked
at
> >> all in the past (which is why there's a "do not verify server cert"
> >> checkbox in the GUI of the OS with 90+% of the market) and there is
> >> no reason to assume it will start working now.
> >>
> >>   A better course would be to not have unrealistic assumptions.
Have
> >> realistic assumptions and state them. I suggest:
> >>
> >>   - if an anonymous tunnel is established an inner method MUST
perform
> >>     mutual authentication, generates keys and be resistant to
> > dictionary
> >>     attack.
> >>   - a man-in-the-middle attack would fail upon completion of the
> >>     inner method but the identities exchanged inside the anonymous
> >>     tunnel would be known to an attacker.
> >>
> >>   We should not let the good be the enemy of the best. Security is
> > about
> >> risk management and we should allow people to manage their risk.
> >>
> >>   regards,
> >>
> >>   Dan.
> >>
> >> On Wed, March 3, 2010 7:00 am, Hoeper Katrin-QWKN37 wrote:
> >> > 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
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>