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.
> -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 18, 2006 12:34 AM > To: Anton Okmianski (aokmians) > Cc: Miao Fuyou; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > > > 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 > > > On Mon, 17 Apr 2006, Anton Okmianski (aokmians) wrote: > > > 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 PROTECTED] > >> Sent: Monday, April 17, 2006 5:10 AM > >> To: Anton Okmianski (aokmians); [EMAIL PROTECTED] > >> 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 PROTECTED] > >>> Sent: Friday, April 14, 2006 10:57 PM > >>> To: Miao Fuyou; [EMAIL PROTECTED] > >>> 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 protected] > >> https://www1.ietf.org/mailman/listinfo/syslog > >>>> > >>> > >> > > > > _______________________________________________ > > Syslog mailing list > > [email protected] https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
