Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method

From: Sam Hartman <[email-masked]>
Date: Sat, 23 Feb 2013 20:46:46 -0500

First, the document has been improved a lot in its clarity since the
last time I read it. I'd really like to thank the editors, Jim and
everyone else who gave comments for some excellent work.

TEAP is by far the best EAP method I've ever reviewed, and I think
security of EAP conversations would be significantly improved if people
implement and deploy TEAP.

Section 3.4:

Does the server_id depend on whether the identifier is actually
authenticated?
That is, let's say the server is using a certificate but the client has
no way to validate the certificate back to a trust anchor.
However, the client uses some strong inner method and EMSK-based crypto
binding to verify the server.
Does the  subject from the server cert make its way into the server ID
in this case?

Is it important that implementations get binary identical strings for
server_id on both sides of the conversation?
I think the text in 3.4 is sufficient that you'd get the right security
properties out of the identity, but I suspect different implementations
could get slightly different encoding etc.
I have never used peer id, server id or session id, so I'm not sure if
anyone cares about that.
3.5:

old:
      tls_unique = tls_unique for the phase 1 outer tunnel as defined by
            [RFC5929].
            
new:
      tls_unique = tls_unique for the phase 1 outer tunnel at the
      beginning of phase 2 as defined by
 section 3.1 of [RFC5929].

rationale: The quantity described in section 3.1 of rfc 5929 can change
when there is TLS renegotiation.
This should avoid that.
Section 3.8-3.10:
All of these sections  involve peer services in the terms of
draft-ietf-abfabf-emu-crypto-bind.
I believe the advice in section 4.2 of  draft-ietf-emu-crypto-bind
applies quite strongly here.
In particular, the peer MUST track whether it has authenticated the
server.

There's text repeated at various points in the TEAP spec that tries to
say this, including some text in 3.8 and a hint at 3.10.

I think this needs to be more unified.
In particular I propose that:

* A new section 3.11 titled "Mutual Authentication for Peer Services" be
  added:

Several TEAP services including server unauthenticated provisioning,
PAC provisioning, certificate provisioning and channel binding depend
on the peer trusting the TEAP server.  Peers need to mutually
authenticate the server before these peer services are used.

TEAP peers MUST track whether mutual authentication has taken
place. Mutual authentication results if the peer trusts the provided
server certificate belongs to the server; typically this involves both
validating the certificate to a trust anchor andconfirming the entity
named by the certificate is the intended server. Mutual authentication
also results when the procedures of section 3.3 are used to resume a
session in which the server was previously mutually
authenticated. Alternatively, if an inner EAP method providing mutual
authentication and an Extended Master Session Key (EMSK) is executed
and cryptographic binding with the EMSK compound MAC present (section
4.2.13), then the session is mutually authenticated and peer services
can be used. TEAP implementations SHOULD Not use peer services by
default unless the session is mutually authenticated. TEAP
implementations SHOULD have a configuration where authentication fails
if mutual authentication cannot be achieved.

An additional complication arises when a
tunnel method authenticates multiple parties such as authenticating
both the peer machine and the peer user to the EAP server. Depending
on how mutual authentication is achieved, only some of these parties
may have confidence in it. For example if a strong shared secret is
used to mutually authenticate the user and the EAP server, the machine
may not have confidence that the EAP server is the authenticated party
if the machine cannot trust the user not to disclose the shared secret
to an attacker. In these cases, the parties who have achieved mutual
authentication need to be considered when evaluating whether to use
peer services.</t>

* Section 3.8-3.10 explicitly refer to this new section. Some of the
  text about server authentication already present in these sections can
  be removed.

* The channel binding TLV and the request-action TLV should also refer
  to 3.11.

Section 4.2.7:

Replace the definition of data with

The data field contains  a channel-binding message as defined in section
5.3 of RFC 6677.

Will the channel binding data (client to server) ever be outside of a
request-action TLV?
If not, it's probably worth pointing this out.

There doesn't seem to be a way for a server to request channel binding.
If that's true we should probably add the following:
Since a server cannot indicate a desire for channel binding, clients
that have channel binding data to send SHOULD include channel-binding
TLV in a request-action TLV if mutual authentication (section 3.11)
succeeded.

section 7.3:
Please update references to draft-hartman-emu-mulutal-crypto-bind to
draft-ietf-emu-mutual-crypto-bind

section 7.6:

Replace peer MUST validate with peer SHOULD validate.  3.10 is an
example where the peer SHOULDN't validate, and no one is going to make
that a MUST so let's not lie.  I'd also like to see the requirement for
implementations to support matching the realm of a NAI against a dns
name in the subjectAltName to be a MUST not a SHOULD.  I think we have
strong evidence that we need an interoperable way to name EAP servers.
Note that's MUST implement, not MUSt use.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 Feb 2013 19:39:18 -0800

Sam,

My responses are inline.  May not agree with the authors however.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sam Hartman
> Sent: Saturday, February 23, 2013 5:47 PM
> To: [email-masked]
> Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
> 
> 
> 
> First, the document has been improved a lot in its clarity since the last
time I
> read it. I'd really like to thank the editors, Jim and everyone else who
gave
> comments for some excellent work.
> 
> 
security of
> EAP conversations would be significantly improved if people implement and
> deploy TEAP.
> 
> Section 3.4:
> 
> That is, let's say the server is using a certificate but the client has no
way to
> validate the certificate back to a trust anchor.
> Does the  subject from the server cert make its way into the server ID in
this
> case?
server_id
> on both sides of the conversation?
properties
> out of the identity, but I suspect different implementations could get
slightly
> different encoding etc.
anyone
> cares about that.

I would expect that the id from the certificate would be returned if the
inner method provided mutual authentication and the crypto bindings were
successful.  At that point one would have a statement about the certificate
that says it matches that of any server id stated inside of the tunnel.  The
certificate would be the one presented by the certificate - could not change
without TLS failing.  The channel binding would give you validation of the
tunnel and mutual auth would give you validation of the server.

I don't know what it would be to have binary identical strings on both
sides.  Only the peer side would get server ids and only the server side
would get peer ids.  

As with you I have never used the ids - so I would not know what they are
used for in general either.

>       beginning of phase 2 as defined by  section 3.1 of [RFC5929].
> 
> 
when
> there is TLS renegotiation.
> This should avoid that.
> Section 3.8-3.10:

This is a reasonable change.

> All of these sections  involve peer services in the terms of
draft-ietf-abfabf-
> emu-crypto-bind.
> I believe the advice in section 4.2 of  draft-ietf-emu-crypto-bind applies
quite
> strongly here.
server.
> 
> There's text repeated at various points in the TEAP spec that tries to say
this,
> including some text in 3.8 and a hint at 3.10.
> 
> Several TEAP services including server unauthenticated provisioning, PAC
> provisioning, certificate provisioning and channel binding depend on the
peer
> trusting the TEAP server.  Peers need to mutually authenticate the server
> before these peer services are used.
> 
> TEAP peers MUST track whether mutual authentication has taken place.
> Mutual authentication results if the peer trusts the provided server
> certificate belongs to the server; typically this involves both validating
the
> certificate to a trust anchor andconfirming the entity named by the
certificate
> is the intended server. Mutual authentication also results when the
> procedures of section 3.3 are used to resume a session in which the server
> was previously mutually authenticated. Alternatively, if an inner EAP
method
> providing mutual authentication and an Extended Master Session Key
> (EMSK) is executed and cryptographic binding with the EMSK compound
> MAC present (section 4.2.13), then the session is mutually authenticated
and
> peer services can be used. TEAP implementations SHOULD Not use peer
> services by default unless the session is mutually authenticated. TEAP
> implementations SHOULD have a configuration where authentication fails if
> mutual authentication cannot be achieved.
> 
> An additional complication arises when a tunnel method authenticates
> multiple parties such as authenticating both the peer machine and the peer
> user to the EAP server. Depending on how mutual authentication is
> achieved, only some of these parties may have confidence in it. For
example
> if a strong shared secret is used to mutually authenticate the user and
the
> EAP server, the machine may not have confidence that the EAP server is the
> authenticated party if the machine cannot trust the user not to disclose
the
> shared secret to an attacker. In these cases, the parties who have
achieved
> mutual authentication need to be considered when evaluating whether to
> use peer services.</t>
> 
> 
request-
> action TLV?
> Since a server cannot indicate a desire for channel binding, clients that
have
> channel binding data to send SHOULD include channel-binding TLV in a
> request-action TLV if mutual authentication (section 3.11) succeeded.

If this is true - then I agree it is a flaw.  

I think that one could send a channel-binding TLV with no data to request
that a client send channel binding data back.  This should not cause any
significant problems.

One could then have
Channel-binding server->peer - no data
Channel-binding peer->server - here is my data
Channel-binding server->peer - here is my data

However I believe that the client can initiate this by just sending the
channel binding TLV in the clear and not in a request if the client wants to
initiate it.

> Replace peer MUST validate with peer SHOULD validate.  3.10 is an example
> where the peer SHOULDN't validate, and no one is going to make that a
> MUST so let's not lie.  I'd also like to see the requirement for
> implementations to support matching the realm of a NAI against a dns name
> in the subjectAltName to be a MUST not a SHOULD.  I think we have strong
> evidence that we need an interoperable way to name EAP servers.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu