Subject: [Syslog] Authentication, certificates, trust anchor, cipher suite and deployability for syslog/tls

From: Miao Fuyou <[email-masked]>
Date: Wed, 03 Oct 2007 11:06:50 -0700

Hi all,

Sorry for not dicussion syslog/tls document for some time. This is to trying
to start the discusion to progress the draft. Basically the open issue is
still about certificate and authentication.  It is also closely relevant to
trust anchor, cipher suite and deployability. I try to classify the
different security environment and give a simple analysis with the
information from AD, chairs and Joe.

Security sensitive environment:
The server and the client are both configured with certiifcates. The trust
anchors must be configured for both server and client, so the client and
server can validate the certificate to a common trust anchor. It is not easy
to deploy because there are a lot of work for certificate and trust anchor
configuration.
This configuration could defense all the threats identifed.

Environment where active attack is concern:
The server is configured with certificate, but the client is not to be
required to be configured with a certificate. The client can generate a
selt-signed certificate by itself. However, the client must be configured
with trust anchor, so it can validate the server certificate is trustable. 
This configuration is still difficult for deployment because there are a lot
of configuration work to be done.
This confguration could defense active attack, but is vulnerable to client
spoof.

Security insensitive environment:
Both the client and server are not required to be configured with
certificate and trust anchor. They generate self-signed certificates. 
It is very easy for deployment because almost there is no configuration
required. 
Note this configuration is vulnerable to active attack.

Which configuration should be mandatory? I seems we need not a mandatory
configuration from the PoV of implementation, right? However, we do need to
mandate the implementation (both client and server) to support certificate
configuration, trust anchor configuration, and self-signed certificate. 

We will need to specify a cipher suite (probably RSA-AES-CBC) for
inter-operatability, but probably we don't need to specify different cipher
suites for 3 various ssenarios because all the scenarios above requires
certificate for key pair generation. 

Regards,
Miao

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

---

From: "Anton Okmyanskiy (aokmians)" <[email-masked]>
Date: Wed, 3 Oct 2007 14:51:26 -0400

Miao:

> The server and the client are both configured with 
> certiifcates. The trust anchors must be configured for both 
> server and client, so the client and server can validate the 
> certificate to a common trust anchor. It is not easy to 
> deploy because there are a lot of work for certificate and 
> trust anchor configuration.
> The server is configured with certificate, but the client is 
> not to be required to be configured with a certificate. The 
> client can generate a selt-signed certificate by itself. 

Why do you need a self-signed certificate here? What purpose does it
serve?

You are not proposing using it for client authentication here, are you?

> However, the client must be configured with trust anchor, so 
> it can validate the server certificate is trustable. 
> This configuration is still difficult for deployment because 
> there are a lot of configuration work to be done.
> This confguration could defense active attack, 

What is that? Let's be more specific if you intend to put this in the
doc (same goes for names of these 3 scenarios).  I think this
configuration does two things: encryption and server authentication.

> but is 
> vulnerable to client spoof.
> 
> Both the client and server are not required to be configured 
> with certificate and trust anchor. They generate self-signed 
> certificates. 

Again, why do you need client self-signed certificate here?   

> It is very easy for deployment because almost there is no 
> configuration required. 

More specifically, this configuration provides only encryption, but no
authentication. 

> Which configuration should be mandatory? I seems we need not 
> a mandatory configuration from the PoV of implementation, 
> right? However, we do need to mandate the implementation 
> (both client and server) to support certificate 

Let's separate what is required for implementation, and what is required
for deployment. 

I think server MUST implement & be deployed with a server-based
certificates for this transport. Whether it is self-signed or CA-signed
can probably be left to a deployment choice. If it is self-signed, then
effectively no server authentication is done, just encryption. 

The other part is client authentication. I think the server MUST support
authenticating clients with certificates and client authentication is
OPTIONAL for deployment.  The minimum authentication that server MUST
support is validating the client certificate against trusted CA. 

A more secure server MAY also want to implement a mechanism which
prevents an authenticated client from masquerading as something else in
the messages that it emits. For example, 1mln certs may be signed by the
same CA, but we don't want one client with one such cert to be able to
masquerade as any of the 1mln other clients. To accomplish this, the
server need to take client identity from CN field of the certificate and
either validate it against some field in syslog message, or at least
plug the CN value into the syslog message structured data, so that admin
can do whatever validation he/she desires when needed.  

I think it is good to describe this additional client authentication
consideration, but leave it as OPTIONAL. I think we discussed
standardizing a unique CN field value before and it was not fruitful.
Standard syslog structured field name for CN value would be a good idea.

> We will need to specify a cipher suite (probably RSA-AES-CBC) 
> for inter-operatability, 

We need to specify at least 2 because one of them may become vulnerable
after standard is released and software is deployed. 

The client MUST advertise support of cipher suite X & Y.  Server will
select the appropriate one based on its configuration for the TLS
session. Server should not be forced to select one of those two. I don't
think there is any server requirement here.  

As for specific cipher suites, it will probably be a religious debate.
Maybe IETF has a policy on this?  I have seen one other standard require
these two:

* RSA_WITH_3DES_EDE_CBC_SHA
* RSA_WITH_RC4_128_SHA

My only concern would be that at least one of them (or better both) is
popular enough to be in most of today's major TLS implementations. 

Regards,
Anton. 

> but probably we don't need to 
> specify different cipher suites for 3 various ssenarios 
> because all the scenarios above requires certificate for key 
> pair generation. 
> 
> Regards,
> Miao
> 
> 
>

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 03 Oct 2007 14:37:08 -0700

Hi Anton, 

Thanks for your feedback!

> > required to be configured with a certificate. The client 
> can generate 
> > a selt-signed certificate by itself.
> 
> Why do you need a self-signed certificate here? What purpose 
> does it serve?

The client MAY use a self-signed certificate. 

> You are not proposing using it for client authentication 

Not exactly. This is to explore various possible options with regard to
certificate, perhaps it is not necessary to appear in the specification.

> 
> What is that? Let's be more specific if you intend to put 
> this in the doc (same goes for names of these 3 scenarios).  
> I think this configuration does two things: encryption and 
> server authentication.

Active attack involves an attempts to change information by contrast with
passive attack. To be more specific, it is man-in-the-middle attack is this
case. 

> More specifically, this configuration provides only 
> encryption, but no authentication. 
> 
> > Which configuration should be mandatory? I seems we need not a 
> > mandatory configuration from the PoV of implementation, right? 
> > However, we do need to mandate the implementation (both client and 
> > server) to support certificate configuration, trust anchor 
> > configuration, and self-signed certificate.
> 
> Let's separate what is required for implementation, and what 
> is required for deployment. 
> 
> I think server MUST implement & be deployed with a 
> server-based certificates for this transport. Whether it is 
> self-signed or CA-signed can probably be left to a deployment 
> choice. If it is self-signed, then effectively no server 
> authentication is done, just encryption. 
> 
> The other part is client authentication. I think the server 
> MUST support authenticating clients with certificates and 
> client authentication is OPTIONAL for deployment.  The 
> minimum authentication that server MUST support is validating 
> the client certificate against trusted CA. 

OK.

> 
> A more secure server MAY also want to implement a mechanism 
> which prevents an authenticated client from masquerading as 
> something else in the messages that it emits. For example, 
> 1mln certs may be signed by the same CA, but we don't want 
> one client with one such cert to be able to masquerade as any 
> of the 1mln other clients. To accomplish this, the server 
> need to take client identity from CN field of the certificate 
> and either validate it against some field in syslog message, 
> or at least plug the CN value into the syslog message 
> structured data, so that admin can do whatever validation 
> he/she desires when needed.  
> 
> I think it is good to describe this additional client 
> authentication consideration, but leave it as OPTIONAL. I 
> think we discussed standardizing a unique CN field value 
> before and it was not fruitful.

Good idea, but I tend to not mix the content with its tranport. BTW, TLS
transport is hop-by-hop protocol rather than an end-to-end protocol, so it
will have difficulties to decide the content when the client is just a
relay. 

> > inter-operatability,
> We need to specify at least 2 because one of them may become 
> vulnerable after standard is released and software is deployed. 
> 
> The client MUST advertise support of cipher suite X & Y.  
> Server will select the appropriate one based on its 
> configuration for the TLS session. Server should not be 
> forced to select one of those two. I don't think there is any 
> server requirement here.  
> 
> Maybe IETF has a policy on this?  I have seen one other 
> standard require these two:
> 

RC4 is for stream application, does it apply to Syslog/TLS? 

RFC4346 mandates TLS_RSA_WITH_3DES_EDE_CBC_SHA, however, I think 3DES is a
interim algorithm. Actually TLS 1.2 draft mandates
TLS_RSA_WITH_AES_128_CBC_SHA.

> 
> My only concern would be that at least one of them (or better 
> both) is popular enough to be in most of today's major TLS 
> implementations. 
> 
> Regards,
> Anton. 
> 
> > specify different cipher suites for 3 various ssenarios because all 
> > the scenarios above requires certificate for key pair generation.
> > 
> > Regards,
> > Miao
> > 
> > 
> >

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 15 Oct 2007 11:39:39 -0700 (PDT)

Hi Folks,

I have not seen any further discussion on this but we still have some open 
issues.

I like the idea of describing the cases for the clients and servers to 
have (or not have) certificates.  For high deployability, I believe that 
the client would not need one at all.  At the other extreme, for high 
security, the clients and servers would need common trust points and 
certificates.

Please pitch in on this discussion.

Thanks,
Chris