On Fri, 2006-04-14 at 10:56 -0400, Anton Okmianski (aokmians) wrote: > 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.
Although the email above was written by me, there must have been some kind of misunderstanding, probably on my side. My understanding is: 1) we should define some kind of certificate binding scheme (like subjectAltName is for HTTP) 2) we probably should allow the operator to override this mechanism and avoid having to check this. > > > 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. I think these are the exact situations when certificate binding should be turned off, or tweaked. > > > 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? The problem is with syslog that you get a connection from an IP address without any hostname information. If we are to define a certificate binding scheme that involves the name of the client's host, then we need to map the IP address to a hostname somehow. The sender is in an easy situation, we configure it to forward all logs to a specified syslog receiver, with the also specified hostname (like the hostname in the HTTPS URL). Certificate binding can be done, no problem. On the receiver side, things are a bit more difficult: it is listening for any number of clients, and these clients are not usually listed in their configuration (e.g. it is an open server like HTTPS) The problem in this case is that there is no hostname information apart from the IP. Our solution might be somewhat similar to what HTTPS has: * define a certificate binding scheme for syslog receivers (in which case it can easily be validated by the sender as it has the necessary information) * and leave it to implementations/operators for definition in the case of senders, just like client certificates in HTTPS, this way no DNS is required. > > > [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. Sometimes it is enough to validate the syslog server for secrecy and client authentication is not required. > > > 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. The problem with validating the host field in the message, that a single sender may produce several different, but still valid names: relays which receive messages from its close neighbours and send messages to a syslog center for processing. In this case the relay has a single certificate. -- Bazsi _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
