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

From: Joe Salowey <[email-masked]>
Date: Thu, 8 Mar 2012 21:42:50 -0800

Hi Sam,

If we added something along the following lines to the document would it be sufficient:

"When performing server certificate validation implementations MUST provide support rules in RFC 5280 for validating certificates against a known trust anchor.  In addition, implementations SHOULD support matching the realm portion of the client's NAI against a SubjectAltName of type dNSName within the server certificate.  "

I'm not sure about EKU.  I don't particularly like using the same EKU's as TLS.   If we define a new EKU then servers will need to get new certs.   Do you think we need EKUs?  

Thanks,

Joe
On Feb 17, 2012, at 2:04 PM, Sam Hartman wrote:

> 
> 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.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu