Subject: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for interoperable implementation

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Feb 2012 17:04:18 -0500

Hi.
I'm writing up a draft on mutual crypto binding.
As such, I happened to glance at section 7.6 on server certificate
validation.

The advice there is entirely inadequate for interoperable
implementation and violates the tunnel method requirements:

1) .  There's a SHOULD check the server name, but there are
no mandatory-to-implement name forms.
That is, I don't know how to map something the peer is likely to have
such as the realm in a NAI to something that could be in a certificate.

2) Section 3.9 of the tunnel method requirements talks about
certificateless authentication.  this is incompatible with  MUST
verify server cert as well as the false claim that during TLS
negotiation a server always sends a certificate to a client.

I'd recommend  resolving as follows:

1) Peers and servers MUST implement certificate modes of TLS; covered
elsewhere in the doc.

2) Peers MUST implement and SHOULD validate server certs to a known
trust anchor.

3) Pick a name form. Peers MUST implement validation of names against
this name form. Describe where peers get the name to check against
(obvious options include the NAI and separate configuration).

4) Peers SHOULD default to checking the name.

5) Describe other certificate properties such as keyusage, EKU, etc or
point back to TLS if appropriate.

6) we probably need language dealing with the sort of stuff I'm writing
up when some of these shoulds need to be upgraded. For example I think
it's highly unadvisable to run channel bindings without checking the
cert and binding back to a specific name or strong mutual crypto
binding.

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 18 Feb 2012 10:05:31 -0800

There is one other item that is also worrying me about this.

In doing the check of certificates, one should be doing revocation checking.
However if one is trying to get network access, one cannot independently
download the revocation information until access is granted, and one cannot
get access granted until one has finished the EAP negotiation.

Currently there is only a limited ability to download the information inside
of the TLS exchange, but that needs to be a requirement. 

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sam Hartman
> Sent: Friday, February 17, 2012 2:04 PM
> To: [email-masked]
> Subject: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for
> interoperable implementation
> 
> 
> Hi.
validation.
> 
> The advice there is entirely inadequate for interoperable implementation
> and violates the tunnel method requirements:
> 
> 1) .  There's a SHOULD check the server name, but there are no mandatory-
> to-implement name forms.
> That is, I don't know how to map something the peer is likely to have such
as
> the realm in a NAI to something that could be in a certificate.
> 
> 
certificateless
> authentication.  this is incompatible with  MUST verify server cert as
well as
> the false claim that during TLS negotiation a server always sends a
certificate
> to a client.
> 2) Peers MUST implement and SHOULD validate server certs to a known trust
> anchor.
> 
> 3) Pick a name form. Peers MUST implement validation of names against this
> name form. Describe where peers get the name to check against (obvious
> options include the NAI and separate configuration).
> 
point
> back to TLS if appropriate.
> 
> 6) we probably need language dealing with the sort of stuff I'm writing up
> when some of these shoulds need to be upgraded. For example I think it's
> highly unadvisable to run channel bindings without checking the cert and
> binding back to a specific name or strong mutual crypto binding.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Sat, 18 Feb 2012 14:28:05 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> There is one other item that is also worrying me about this.
    Jim> In doing the check of certificates, one should be doing
    Jim> revocation checking.  However if one is trying to get network
    Jim> access, one cannot independently download the revocation
    Jim> information until access is granted, and one cannot get access
    Jim> granted until one has finished the EAP negotiation.

TLS these days has the ability to present an OCSP response inline,
right?
Wouldn't that be a eaiser-to-implement strategy?

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 18 Feb 2012 12:02:58 -0800

TLS can present an OCSP response for the end certificate,  if you have
TA->CA1->EE then you can't get it for the CA1 certificate.

Jim

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Saturday, February 18, 2012 11:28 AM
> To: Jim Schaad
> Cc: 'Sam Hartman'; [email-masked]
> Subject: Re: [Emu] draft-ietf-emu-eap-tunnel-method 7.6: inadequate for
> TLS these days has the ability to present an OCSP response inline, right?