Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2

From: Miao Fuyou <[email-masked]>
Date: Tue, 21 Mar 2006 18:00:04 +0800

> -----Original Message-----
> From: Balazs Scheidler [mailto:[email-masked]] 
> Sent: Tuesday, March 21, 2006 5:27 PM
> To: Miao Fuyou
> Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
> 
> 
> On Tue, 2006-03-21 at 10:54 +0800, Miao Fuyou wrote:
> > > 
> > > Not clear, what authentication is done on APP-NAME as part of
> > > "Syslog message processing".  
> > > 
> > 
> > There are difference between Host name binding and app-name binding 
> > when being checked. For host name binding, application can 
> check the 
> > binding only based on inforamtion(cert and hostname) at TLS 
> layer and 
> > check it once for the session. For app-name binding, 
> application must 
> > check information from both TLS(cert) and syslog(app-name).
> > 
> > Is app-name consistent/constant for a specific connection? If no, 
> > application must check each syslog message against the cert.
> > 
> 
> Definitely no, a single connection will be used to deliver 
> messages for multiple applications, so the ceritificate 
> should be bound to the syslog sender and not any individual 
> applications running on the sender.
> 

I infer from your sentence that "generic" certificate is not possible. Each
TLS connection is associated with only one certificate at most for each
direction. However, multiple app-name requires multiple certificate. It
conflicts TLS specification. Right?

> The question is how the receiver resolves the sender host, 
> using reverse DNS? or it simply accepts any trusted 
> certificates no matter what the name is.
> 

I don't think it is a problem, application should decide how to resolves the
sender host.

> -- 
> Bazsi

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

---

From: Balazs Scheidler <[email-masked]>
Date: Tue, 21 Mar 2006 17:11:45 +0100

> conflicts TLS specification. Right?

right.

> I don't think it is a problem, application should decide how to resolves the

If we are to propose that certificates should be bound to the name of
the sender hosts, and receivers should check that the certificates
contain a proper hostnames, then we need to propose what kind of
information it needs to compare it to.

Sure it can be a configuration item (e.g. client 10.10.10.10 should come
with a certificate assigned to logsender.domain.com), but it is
preferable to allow syslog connections from an unlisted set of hosts,
(e.g. open to anyone with a valid certificate), in which case the
configuration example I gave above does not apply.

Receiver side certificates are easier, just like for servers in HTTPS,
we have a hostname for them in the sender's configuration.

So we either leave the SSL certificate binding undefined for the
operators to decide, or we need to clarify how certificate is to be
validated.

-- 
Bazsi

---

From: Darren Reed <[email-masked]>
Date: Wed, 22 Mar 2006 05:21:04 +1100 (EST)

> operators to decide, or we need to clarify how certificate is to be

How much of this is an operational matter that varies from site to site
with local policies on such things ?

Darren

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 22 Mar 2006 07:56:59 +0100

> with local policies on such things ?

Honestly I don't know. HTTPS gives you a certificate model on the server
side as well. (e.g. use server name in subjectAltName or in CN)

I would say that the basic model is mandated by the protocol, with
overrides in the operator's hand (e.g. the "Yes, I want to continue"
button in the browser, in the case of HTTPS).

-- 
Bazsi