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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 1 Mar 2010 21:52:53 -0800

Thanks Dan,

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

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

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Tue, 2 Mar 2010 10:03:48 -0500

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

> Joseph Salowey (jsalowey)
> Sent: Monday, March 01, 2010 11:53 PM
> To: Dan Harkins; [email-masked]
> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> Thanks Dan,
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 2 Mar 2010 17:09:40 -0800 (PST)

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.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 3 Mar 2010 10:00:00 -0500

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.

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Tuesday, March 02, 2010 7:10 PM
> To: Hoeper Katrin-QWKN37
> Cc: Joseph Salowey; Dan Harkins; [email-masked]
> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> 
>   Hi Katrin,
> 
> >> > From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >> mentioned somewhere in the document.  What is the harm in
mentioning
> > it
> >> >     That seems like a huge stretch of the work we are chartered
to
> > do.
> >> >     the requirements for a protocol to direct the working group
how
> >> >     "that the working group had consensus to use existing work
and
> > so
> >> >     [cipher suite negotiation] requirements" then what's the
point
> > of
> >> >     Please restate the requirement to say something along the
lines
> > of
> >> "Other specifications may define uses of the tunnel method the
build
> > on
> >> " TLS provides sufficient replay protection to meet this
requirements
> > as

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 3 Mar 2010 09:53:31 -0800 (PST)

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.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 3 Mar 2010 13:25:34 -0500

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

> Sent: Wednesday, March 03, 2010 11:54 AM
> To: Hoeper Katrin-QWKN37
> Cc: Dan Harkins; Joseph Salowey; [email-masked]
Behalf
> >> >> [Joe] While, it is true that carrying NEA protocols should be
met
> > by
> >> >> that NEA use case is pertinent to the tunnel method work and
should
> > be
> >> >> >     this "requirement", and so could 8 bits of RESERVED-- set
to
> >> > zero
> >> >> >     interesting point without addressing my comment. That
other
> >> >> >     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
> >> >> >     This is a nonsense statement. Either it's unidirectional
or
> > it's
> >> >> >     Additionally, it says "mandatory to implement cipher
suites
> > MUST
> >> >> >     credential provisioning requirement (which is a MUST by
the
> >> > way).
> >> >> >     "if an anonymous TLS ciphersuite is used by the outer
tunnel
> >> > then
> >> >> building on top of the tunnel method.   I can see how the
existing
> >> > text

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 3 Mar 2010 11:19:31 -0800 (PST)

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.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 3 Mar 2010 15:31:57 -0500

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

> Sent: Wednesday, March 03, 2010 1:20 PM
> To: Hoeper Katrin-QWKN37
> >> > parties exchanged inside the tunnel -> i.e. breaking the privacy
of
> > both
> >> > Considering the attack, I don't see what mutually anonymous
tunnels
> > can
> >> > tunnels in which an MitM can get all exchanged identifiers in
order
> >> > cryptographically strong, the attack will be detected. However,
by
> >> > only have weak inner key derivations (that's why they are
tunneled)
> >> >> provisioning. And it is secure. Please reconsider your
opposition
> >> >> > The current text allows server-side only authentication for
the
> >> > tunnel,
> >> >> > I think what you are talking about is mutually anonymous
tunnels,
> >> > i.e.
> >> >> > 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
> >> >> > I strongly oppose to allowing these tunnels and believe that
the
> >> > current
> >> >> >> I haven't seen any responses on the list yet so I provided
some
> >> > inline
> >> >> >> cipher suites from being used in follow-on specifications.
See
> >> >> >> >     Please change this to something like "the identity of
the
> >> > peer
> >> >> >> >     used for authentication purposes MUST NOT be obtainable
by
> >> > any
> >> >> >> >     Since the tunneled EAP method can tunnel EAP methods
then
> >> > this
> >> >> >> either the extensibility or carrying EAP method requirements,
I
> >> >> > believe
> >> >> >> >     Huh? What kind of credentials are these? Please
describe
> >> > these
> >> >> >> >     The working group does not need to be constrained in
its
> >> >> > decision-
> >> >> >> " TLS provides protected cipher suite negotiation as long as
all
> >> >> >> >     authentication from authentication server to EAP peer
and
> >> > mutual
> >> >> >> >     these as TLS cipher suites then I really think this
should
> > be
> >> >> >> changed.
> >> >> >> >     An anonymous TLS cipher suite negotiated by the EAP
tunnel
> >> >> > method
> >> >> >> >     as the inner method. That would provide a way to
securely
> >> >> > satisfy
> >> >> >> [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
> >> >> >> might be a bit problematic, but your suggested text makes me
a
> > bit
> >> >> >> anonymous cipher suites.  These specifications must take care
to
> >> >> > address
> >> >> >> >   - 4.2.1.2 requires replay protection and then goes on to
say
> >> > that

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 3 Mar 2010 13:39:08 -0800 (PST)

Hi Katrin,

> still don't understand the use case for mutually anonymous tunnels.

  Because it doesn't have the right credential.

> or during the tunnel establishment?

  If the server has a certificate then sending it to the peer
would not really solve any problem. The peer would still need to
have a reason to trust it and we're back to the problem of putting
a trusted certificate in some certificate store. A global PKI to
solve all of our certificate issues still has not materialized.

> If the peer and server share a secret, than this could be used to

  If the peer and server share a secret they could use one of the PSK
ciphersuites for TLS but those are susceptible to a dictionary attack
and are therefore inappropriate.

  The tunnel is being established with EAP-TLS so we are limited to
TLS ciphersuites and the authentication they provide. If a TLS ciphersuite
was appropriate always and everywhere then we would not need any other
EAP methods, we'd just do EAP-TLS. But that is not the case. Also it is
a requirement to tunnel additional EAP methods inside the tunnel so
obviously there are EAP methods that provide something that a TLS
ciphersuite does not.

> authenticate the server in the tunnel protocol? (given that privacy is

  A low-entropy password that can easily be remembered and entered by a
human with low probability of error.

  Dan.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 3 Mar 2010 16:45:16 -0500

See inline.
> Sent: Wednesday, March 03, 2010 3:39 PM
> To: Hoeper Katrin-QWKN37
[KH] I asked what kind of SERVER credentials not peer credentials.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 3 Mar 2010 14:13:58 -0800 (PST)

Since they both use the same low-entropy password to perform their
mutual authentication it is not, strictly speaking, just the peer's
credential.

  Dan.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 3 Mar 2010 17:27:58 -0500

How does that authenticate the server if a user enters a password?

If the server says, yes that was the right password?

> Sent: Wednesday, March 03, 2010 4:14 PM
> To: Hoeper Katrin-QWKN37
> >> EAP methods, we'd just do EAP-TLS. But that is not the case. Also
it
> >> > What I am saying is what kind of server authentication
credentials
> > could
> >> > authenticate the server in the tunnel protocol? (given that
privacy
> > is
> >> > not the issue)
> >>
> >>   A low-entropy password that can easily be remembered and entered
by

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 3 Mar 2010 17:33:04 -0500

Sorry Dan,

Is EAP-pwd using the password for mutual authentication? 

> Hoeper Katrin-QWKN37
> Sent: Wednesday, March 03, 2010 4:28 PM
> To: Dan Harkins
> Cc: [email-masked]
> > >> > But why can't the server authenticate during the tunnel
protocol?
> > >> > If the server has a certificate why can't it send it to the
peer
> > > before

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 3 Mar 2010 15:30:04 -0800 (PST)

Hi Katrin,

  Yes, EAP-pwd uses the password for mutual authentication. If the
server doesn't know the password the exchange will fail. The key
differentiator (from, say, EAP-GPSK) is that it uses a zero knowledge
proof and is resistant to off-line dictionary attack.

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 3 Mar 2010 20:05:09 -0800

Hi Dan,

The document currently states anonymous cipher suites MUST NOT be
mandatory to implement for the tunnel method.  I think the is the
appropriate stance for the document to take for the base tunnel method.
I also do not think this prevents a follow-on specification defining how
to use anonymous tunnel securely.

Cheers,

Joe

Dan
> Harkins
> Sent: Wednesday, March 03, 2010 3:30 PM
> To: Hoeper Katrin-QWKN37
> Cc: [email-masked]
> >> > >> > If the peer and server share a secret, than this could be
used
> > to
> >> > >> > establish the tunnel.
> >> > >>
> >> > >>   If the peer and server share a secret they could use one of
the
> >> PSK
> >> > >>   The tunnel is being established with EAP-TLS so we are
limited
> >> > >> was appropriate always and everywhere then we would not need
any
> >> > >> a requirement to tunnel additional EAP methods inside the
tunnel