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 protected]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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

Reply via email to