Balazs: I don't think DNS lookup for validating clients will work in all cases. If syslog clients are NAT'ed (and many CPEs are), it does not make sense for them to have a hostname. You will not see the real source IP on syslog server. So, if we recommend it as basic standard binding its use will be limited.
I agree that server validation is different. In this case you have the ultimate source IP and hostname lookup helps. You are validating that the certificate the server presented is not just signed by right CA, but also authenticates the server you intended to connect to. In case of authenticating clients, I see two uses for it: (a) restricting access to server to a subset of clients; this can be accomplished by CPE presenting a generic certificate signed by a given CA (say my organization CA); if further granularity of access control is needed, some data from certificate needs to be compared against a list or a database - this is where "binding check" comes in, if you want to call it that; this should be allowed; (b) establishing the real identity of the sender, so you can trust its messages; here you don't necessarily care to limit access to the server, but rather care to have an indication about client identity that generated a given message; this is where insertion of CN data into message helps - it helps you understand who really sent the message; in case of generic certificate you may decide to trust what the client says in syslog message as long as it presented a valid generic certificate. I can't think of a good standard binding check for clients (I don't mind us recommending it if we can come up with one), but I can see the value of standard way to identify the authenticated source in the message by inserting CN/CA field. Thanks, Anton. > -----Original Message----- > From: Balazs Scheidler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 19, 2006 2:26 PM > To: Anton Okmianski (aokmians) > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > > 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
