Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 26 Oct 2005 14:57:39 +0200

Darren, 

please let me add 

> > TLS so small as to be invisible

is probably not true. TLS uses X.509 certificates, so isn't it in that
number:

> >   14%  X.509 Certificates

Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Wed, 26 Oct 2005 14:43:35 -0400

> TLS does support mutual node authentication. The healthcare 
> world has been using mutual-node-authenticated-TLS for over 
> three years. We use it often to ensure that a X-Ray device is 
> actually talking to the Picture Archiving Service. Both 
> systems need to know that they are talking to the right 
> 'other' system. This transaction doesn't need to have user 
> authentication as the process is fully automated. Indeed we 
> don't always turn on TLS encryption. But we do always do 
> mutual-authentication. Yes this means that there is a X.509 
> certificate managed for both nodes. But this certificate 
> management is not nearly as complex as person-certificates 
> (another discussion we can have on miss-understandings due to 
> the wrong questions being asked).
> 
> Tom- this one puzzles me.  SSH has got server and client 
> authorisation defined in the I-Ds, soon to be RFCs.  Reading 
> the TLS I-Ds I see no sign of client authorisation and since 
> that is a must for SNMP, then the note I quoted earlier, to 
> the isms list, saying that SASL would needed alongside TLS 
> made perfect sense (as I would expect since it came from the 
> Security AD:-).  So where does mutual authentication come 
> from?  What RFC or I-D defines it?  Is it a proprietary 
> extension? Is it two simplex transmissions with only server 
> authentication?
> Sometimes it does matter to know what goes on under the 
> covers.  (Of course, if client authentication is not needed 
> then this is academic).

Client auth is a fundamental feature of TLS.  It is all over the TLS RFC:
http://www.faqs.org/rfcs/rfc2246.html

Search it for "client authentication" or "client certificate". There are whole sections on it. It is part of the initial SSL/TLS setup.  Server may require client-auth if configured so.   

If you don't believe that it is deployed, open you browser security settings. John mentioned that not all browsers supports client certs for SSL/TLS. Well... At least IE, Netscape, Firefox support it and had for some time.  In fact, they have pretty advanced features around client certs.  For example, you can use a different client cert with different sites. 

The real question IMO, again, is whether or not symmetric auth (password / shared secret based) is considered important. SSH has it. TLS does not.  If client certs are acceptable to people, then TLS is a perfect solution. I think certificate-based infrastructure is more secure and easier to manage in the end.  No interactive user auth is needed for syslog, as John mentioned. And if you store passwords instead of having user type them in, then you are really only one-step away from using certs.  

Thanks,
Anton. 

> <snip>
> John

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Wed, 26 Oct 2005 14:00:30 -0500

Anton, Thanks for your support. I do want to caution your enthusiasm for
the browser support. I believe that all current production browsers
implement the feature you found using HTTP-authentication, not TLS/SSL.
Trying to create a user interface for this complex concept can't be
easy, and the prevailing reason to use client certificates was for user
authentication. Thus they took the most logical short-cut.

It is my understanding that IE7 will have true TLS/SSL
client-certificate authentication. 

It is also my understanding that firefox current 1.5 has TLS/SSL
client-certificate authentication. I had seen test results that
indicated this was true. 
http://www.mozilla.org/projects/security/pki/nss/results.html

I have not been able to confirm this personally.

John

-----Original Message-----
From: Anton Okmianski (aokmians) [mailto:[email-masked]] 
Sent: Wednesday, October 26, 2005 1:44 PM
To: Tom Petch; Moehrke, John (GE Healthcare); [email-masked]
Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your
input

> covers.  (Of course, if client authentication is not needed 

Client auth is a fundamental feature of TLS.  It is all over the TLS
RFC:
http://www.faqs.org/rfcs/rfc2246.html

Search it for "client authentication" or "client certificate". There are
whole sections on it. It is part of the initial SSL/TLS setup.  Server
may require client-auth if configured so.   

If you don't believe that it is deployed, open you browser security
settings. John mentioned that not all browsers supports client certs for
SSL/TLS. Well... At least IE, Netscape, Firefox support it and had for
some time.  In fact, they have pretty advanced features around client
certs.  For example, you can use a different client cert with different
sites. 

The real question IMO, again, is whether or not symmetric auth (password
/ shared secret based) is considered important. SSH has it. TLS does
not.  If client certs are acceptable to people, then TLS is a perfect
solution. I think certificate-based infrastructure is more secure and
easier to manage in the end.  No interactive user auth is needed for
syslog, as John mentioned. And if you store passwords instead of having
user type them in, then you are really only one-step away from using
certs.  

Thanks,
Anton.

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Wed, 26 Oct 2005 15:29:06 -0400

John:

My experience is slightly different.  That client cert support in browsers has been there for years. HTTP basic/digest auth does not use certs. HTTP auth is used when you are prompted for username/password. 

But not many servers in the wild require client-certs -- no public e-commerce site would do that if it wanted to get business. It is mostly targeted at closed corporate environments at this point where employees get individual certs to authenticate to corporate servers. Same is used for mail. 

You will also notice that a bunch of public certificate authorities sell personal certificates. These are used predominantly in email clients, for message signing (end-to-end message authenticity) instead of auth to server. Although, some organizations do use client certs for authenticating to mail servers with SMTP/POP3 over TLS. 

But anyhow... I agree that the client-certs are not used as often as server-certs.  But they are a very established technology in TLS world. I think we both agree on that. 

Thanks,
Anton.    

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Moehrke, 
> John (GE Healthcare)
> Sent: Wednesday, October 26, 2005 3:01 PM
> To: [email-masked]
> Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - 
> need your input
> 
> Anton, Thanks for your support. I do want to caution your 
> enthusiasm for the browser support. I believe that all 
> current production browsers implement the feature you found 
> using HTTP-authentication, not TLS/SSL.
> Trying to create a user interface for this complex concept 
> can't be easy, and the prevailing reason to use client 
> certificates was for user authentication. Thus they took the 
> most logical short-cut.
> 
> It is also my understanding that firefox current 1.5 has 
> TLS/SSL client-certificate authentication. I had seen test 
> results that indicated this was true. 
> Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - 
> need your input
> 
>