Subject: RE: [Syslog] Summary of the syslog/tls issues resolving

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Mon, 17 Apr 2006 10:51:08 -0400

Miao:

The layering is not a problem. The TLS stack will expose the validated client certificate to the upper layer. That layer (syslog server app) can do whatever it wants with the certificate data.  

However, I don't think binding check should be required.  For one, this would preclude the most generic certificates. There may be too many options about how one may want to validate/use the client identity in the certificate.  For example, one could configure syslog server to allow clients which have one of the defined strings in the CN fields (could be hostnames or whatever) or it could consult a database of clients.  Alternatively (or in addition), one can check the CN content against some field in the syslog message itself. 

I think having a standard way to identify individual syslog clients using syslog-over-TLS would be very useful. This means that client identity could be extracted our of certificate.   

Possibly, all we need to do here is:

 (a) say that certificate CN MAY carry syslog client identity information
 (b) REQUIRE insertion of CN data into syslog message (relay or not)
 (c) define structured element for insertion of CN data
 (d) RECOMMEND that syslog servers provide a function to restrict access based on CN content

Thoughts?

Thanks,
Anton.    

> -----Original Message-----
> From: Miao Fuyou [mailto:[email-masked]] 
> Sent: Monday, April 17, 2006 5:10 AM
> To: Anton Okmianski (aokmians); [email-masked]
> Subject: RE: [Syslog] Summary of the syslog/tls issues resolving
> 
> 
> The confusion comes from the relationship of binding and 
> authentication. 
> 
> In TLS/SSL, authentciation is to check whether a CA trusted 
> by the checker
> in the certificate chain  is available. If there is trusted 
> CA, checker may
> check the binding of common name of certificate to something available
> locally, such as host name. But, binding check is not a step for
> authentcation by certificate's nature. 
> 
> If we consider authentication only, it will be much simple. A 
> receiver just
> check the trustship of sender's certificate without checking binding,
> regardless what entity(a host, an application, a class of device or
> application described in Anton's scenario) the certificate is 
> issued to. In
> such case, generic certificate is possible. 
> 
> When we discuss certificate/CN binding, it becomes tricky. It is not
> practical to check the binding of APP-NAME or anything from 
> syslog message,
> such as FQDN, to certificate when authentciating a sender. 
> Such binding
> check will breach the layership and modularity of tls/syslog, 
> and may impact
> efficiency badly. This point was  discussed by Balazs and me 
> on the mailing
> list( 
> http://www1.ietf.org/mail-archive/web/syslog/current/msg00918). We
> MUST rely on the information available to TLS layer to check 
> the binding of
> common name. One such information is hostname, so we are able 
> to check the
> binding of hostname to certificate when it is issued to host(host
> certificate, or unique certificate). When common name of a 
> host certificate
> is device ID or MAC etc, it is not practical to check the 
> binding because of
> inavailablity of such information to TLS. If a certificate is 
> issued to
> anything else(such as applicaiton, a class of device or 
> application), the
> similiar things may happen. So, for a lot of scenarios, 
> binding check is not
> practical!
> 
> Now the question are: Do we really need binding check? Does 
> binding check
> provides any benefit/security? If we need binding check, we 
> may only be able
> to use it with host certificate.
> 
> Miao
> 
> > -----Original Message-----
> > From: Anton Okmianski (aokmians) [mailto:[email-masked]] 
> > Sent: Friday, April 14, 2006 10:57 PM
> > To: Miao Fuyou; [email-masked]
> > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving
> > 
> > 
> > Miao:
> > 
> > >    [Issue 1]: Is it possible to use "generic certificate 
> > for different
> > >    host?  The generic certificate is for specific 
> application type. 
> > > AND
> > >    [Issue 2]: What to bind to a certificate?  Hostname, 
> Syslog APP-
> > >    NAME(generic certificate)?  APP-NAME binding makes 
> > authentication/
> > >    access control happens both in TLS handshake and Syslog message
> > >    processing, is efficiency a problem?
> > > 
> > > Tentative resolution: 1, Generic certificate may not be
> > > possible (refer to
> > > http://www1.ietf.org/mail-archive/web/syslog/current/msg00918.
> > > html). 
> > 
> > I can't support this conclusion. Of course, it is possible - 
> > used all the time. 
> > 
> > > So bind
> > > app-name is not required and possible.
> > 
> > Generic certificate does not need to be bound to anything, 
> > although it can carry some certified pieces of information. 
> > Having a format for putting known fields into certificate CN 
> > field would be nice, but not mandatory.  
> > 
> > I work on a product which manages million of consumer devices 
> > (modems, gateways, settop boxes, etc)remotely for service 
> > providers (SPs). These SPs are starting to use SSL/TLS for 
> > many CPE to back-end interactions. Some SPs use unique 
> > certificates on each device, in which case it is a device ID 
> > such as serial number or MAC address embedded in certificate 
> > CN field - not hostname. Case study, DSL Forum defines use of 
> > device ID in certificate CN field in their CWMP standard 
> > defined in TR-069 / WT-121. The same standard also allows for 
> > use of generic certificates.  
> > 
> > Some SP want to use the same cert on all devices. That 
> > generic cert identifies either manufacturer or service 
> > provider. It does not authenticate a specific CPE, but rather 
> > as a way to establish that CPE is the right kind to connect 
> > to backend systems.  Similar vendor certificates, I believe, 
> > are used in Cable industry's PacketCable VoIP standards 
> > (although they have unique ones too). In this environment, 
> > having a unique certificate on millions of devices is 
> > generally considered a serious cost factor - adds cost to 
> > CPE. Sometimes a combination of generic cert + HTTP digest 
> > authentication is used.  In syslog case, syslog payload 
> > signing could be the option that could replace HTTP digest 
> > authentication.  
> > 
> > The point of above is that generic certificates are used 
> > today, part of standards and seem to make sense to large 
> > organizations which demand their use.  So, it is certainly 
> > possible to use those and would be a good idea for syslog to 
> > support it too. 
> > 
> > > 2, We need cerficate
> > > binding to host
> > > name, operator to decide whether to check the binding. 
> > 
> > Certificate with hostname (FQDN, right?) in the CN is a 
> > decent option, but as I mentioned above, this is not what say 
> > DSL SPs use to identify devices. Hostname for unique 
> > certificate can't be a requirement IMO.  
> > 
> > I agree that it should be operator decision whether or not to 
> > check the certificate binding. 
> > 
> > > Receiver may consult
> > > DNS to get host name for a sender, while sender may just 
> > query local 
> > > configuration to get host name.
> > 
> > Not sure what you mean here. Certificates have to be 
> > generated by CA (certificate Authority) which has the private 
> > key, then installed on the host.  The sender can't just 
> > generate one by looking up the hostname. Or are you talking 
> > about hostname inserted in syslog message field?  
> > 
> > Also, why does receiver need to consult DNS?  
> > 
> > >  [Issue 4]: Shall we mandate the sender MUST be 
> > authenticated?  Most  
> > > of the Syslogd accepts messages only from configured address.
> > 
> > In TCP, restricting by source IP buys you more than in UDP 
> > where it is easy to spoof, but even in TCP it is hardly an 
> > authentication mechanism or we would not be talking about TLS 
> > auth. In case of my application with millions of devices, you 
> > would have to allow huge subnets anyway and addresses are 
> > allocated dynamically using DHCP.  
> > 
> > > Tentative resolution: It should be optional to operator, use
> > > SHOULD or MAY
> > > instead of MUST and explain security implication. I tend to 
> > > use SHOULD.
> > 
> > Sounds good.  Please state clearly what it means to 
> > authenticate the sender though. Is it a sender presenting a 
> > legitimate signed certificate (be it generic or unique)?  Or 
> > does it include checking certificate binding by comparing CN 
> > field to some field in syslog message (like FQDN)? In case of 
> > latter, the syslog would need to carry FQDN (not hostname or 
> > IP which are allowed substitutes) as well. 
> > 
> > Thanks,
> > Anton. 
> > 
> > > (Refer to
> > > 
> http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html)
> > > 
> > > Miao
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Syslog mailing list
> > > [email-masked] 
> https://www1.ietf.org/mailman/listinfo/syslog
> > > 
> > 
> 

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

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 17 Apr 2006 09:34:26 -0700 (PDT)

Hi Anton,

Your proposal seems to be overlapping syslog-sign.

I think that what the community would like (this is open for debate) is 
for a standard that will allow an existing implementation of syslog to use 
syslog/tls in a standard way right now.  The next step would be to convert 
to syslog-protocol, and the step beyond that would be to include 
syslog-sign.

On the subject of binding checks, perhaps it would be good to keep in mind 
that some syslog senders are things like printers or other devices that 
will have a certificate issued at the time it was manufactured.  Is it 
going to be worth the effort for the operations staff to install localized 
certificates, or would they be willing to accept those and just use access 
control lists?  (David Perkins mentioned this to me and said that it was 
OK for me to include him in this discussion - which is why I'm cc'ing him 
on this.)

Thanks,
Chris

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 18 Apr 2006 09:08:57 +0800

I believe now the best thing we can do is: we do not exclude certificate in
any form, generic or unique, to maximize syslog/tls deployment. We can talk
what CN is possible to be for a certificate, but we don't specify how to
process CN for sender/receiver. 

> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Tuesday, April 18, 2006 12:34 AM
> To: Anton Okmianski (aokmians)
> Cc: Miao Fuyou; [email-masked]; [email-masked]
> > The layering is not a problem. The TLS stack will expose 
> the validated 
> > client certificate to the upper layer. That layer (syslog 
> server app) 
> > can do whatever it wants with the certificate data.
> >
> > However, I don't think binding check should be required.  For one, 
> > this would preclude the most generic certificates. There may be too 
> > many options about how one may want to validate/use the client 
> > identity in the certificate.  For example, one could 
> configure syslog 
> > server to allow clients which have one of the defined 
> strings in the 
> > CN fields (could be hostnames or whatever) or it could consult a 
> > database of clients.  Alternatively (or in addition), one can check 
> > the CN content against some field in the syslog message itself.
> >
> > I think having a standard way to identify individual syslog clients 
> > using syslog-over-TLS would be very useful. This means that client 
> > identity could be extracted our of certificate.
> >
> >> In TLS/SSL, authentciation is to check whether a CA trusted by the 
> >> checker in the certificate chain  is available. If there is trusted
> >> CA, checker may
> >> receiver just check the trustship of sender's certificate without 
> >> checking binding, regardless what entity(a host, an application, a 
> >> class of device or application described in Anton's scenario) the 
> >> certificate is issued to. In
> >> practical to check the binding of APP-NAME or anything from syslog 
> >> message, such as FQDN, to certificate when authentciating a sender.
> >> Such binding
> >> Now the question are: Do we really need binding check? 
> Does binding 
> >> check provides any benefit/security? If we need binding check, we
> >> may only be able
> >>>> Tentative resolution: 1, Generic certificate may not be possible 
> >>>> (refer to 
> >>> I can't support this conclusion. Of course, it is possible - used 
> >>> all the time.
> >>>
> >>>> So bind
> >>> Generic certificate does not need to be bound to 
> anything, although 
> >>> it can carry some certified pieces of information. Having 
> a format 
> >>> for putting known fields into certificate CN field would be nice, 
> >>> but not mandatory.
> >>>
> providers 
> >>> (SPs). These SPs are starting to use SSL/TLS for many CPE to 
> >>> back-end interactions. Some SPs use unique certificates on each 
> >>> device, in which case it is a device ID such as serial 
> number or MAC 
> >>> address embedded in certificate CN field - not hostname. 
> Case study, 
> >>> DSL Forum defines use of device ID in certificate CN 
> field in their 
> >>> CWMP standard defined in TR-069 / WT-121. The same standard also 
> >>> allows for use of generic certificates.
> >>>
> generic cert 
> >>> identifies either manufacturer or service provider. It does not 
> >>> authenticate a specific CPE, but rather as a way to 
> establish that 
> >>> CPE is the right kind to connect to backend systems.  
> Similar vendor 
> >>> certificates, I believe, are used in Cable industry's PacketCable 
> >>> VoIP standards (although they have unique ones too). In this 
> >>> environment, having a unique certificate on millions of devices is
> today, part 
> >>> of standards and seem to make sense to large organizations which 
> >>> demand their use.  So, it is certainly possible to use those and 
> >>> would be a good idea for syslog to support it too.
> >>>
> >>>> 2, We need cerficate
> >>>> binding to host
> >>> Certificate with hostname (FQDN, right?) in the CN is a decent 
> >>> option, but as I mentioned above, this is not what say 
> DSL SPs use 
> >>> to identify devices. Hostname for unique certificate can't be a 
> >>> requirement IMO.
> >>>
> >>> I agree that it should be operator decision whether or 
> not to check 
> >>> the certificate binding.
> >>>
> >>>> Receiver may consult
> generated by CA 
> >>> (certificate Authority) which has the private key, then 
> installed on 
> >>> the host.  The sender can't just generate one by looking up the 
> >>> hostname. Or are you talking about hostname inserted in syslog 
> >>> message field?
> >>>
> >>> In TCP, restricting by source IP buys you more than in 
> UDP where it 
> >>> is easy to spoof, but even in TCP it is hardly an authentication 
> >>> mechanism or we would not be talking about TLS auth. In 
> case of my 
> >>> application with millions of devices, you would have to 
> allow huge 
> >>> subnets anyway and addresses are allocated dynamically using DHCP.
> >>>
> >>>> Tentative resolution: It should be optional to operator, 
> use SHOULD 
> >>>> or MAY instead of MUST and explain security implication. 
> I tend to
> >>>> use SHOULD.
> >>>
> authenticate the 
> >>> sender though. Is it a sender presenting a legitimate signed 
> >>> certificate (be it generic or unique)?  Or does it 
> include checking 
> >>> certificate binding by comparing CN field to some field in syslog 
> >>> message (like FQDN)? In case of latter, the syslog would need to 
> >>> carry FQDN (not hostname or IP which are allowed substitutes) as 
> >>> well.
> >>>
> >>> Thanks,
> >>> Anton.
> >>>
> >>>> (Refer to
> >>>>
> > [email-masked] https://www1.ietf.org/mailman/listinfo/syslog
> >
>