Subject: Re: [Syslog] -transport-tls-12, section 4.2.3 (fingerprints)

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 8 May 2008 22:06:55 +0200

> > > -----Original Message-----
> > > From: Rainer Gerhards
> > > Sent: Thursday, May 08, 2008 3:07 PM
> > > To: [email-masked]
> > > Subject: -transport-tls-12, section 4.2.3 (fingerprints)
> > > 
> > > Joe,
> > > 
> > > I am implementing fingerprint authentication. I have some trouble 
> > > understanding this text:
> > > 
> > > ===
> > > Both client and server implementations MUST make the certificate 
> > > fingerprint available through a management interface.  If 
> no other 
> > > certificate is configured, both client and server 
> > implementations MUST 
> > > support generating a key pair and self-signed certificate.
> > > ===
> > > 
> > > Especially the "If no other certificate is configured..." 
> > part puzzles 
> > > me. Does that mean that if no certificate is configured, 
> the syslogd
> > is
> > > responsible for generating a self-signed certificate 
> automatically?
> > > 
> > > If so, I have concerns if that is the right thing to do. I think 
> > > certificates should always be generated by an operator.
> > > 
> > > Or does it mean that there must be a management interface 
> > to generate 
> > > self-signed certificates? If so, I assume that this management 
> > > interface may reside outside of the core syslogd. In 
> > rsyslog, I will 
> > > provide some tools to generate self-signed certificates and 
> > obtain the 
> > > fingerprints (you may want to look at the rough prototypes 
> > if I made 
> > > myself not clear enough:
> > http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools/gnutls;h=
> > 1abb246805
> > 546ebd2f1f008a3cf256d5c76b7cbc;hb=HEAD ).
> > > 
> [Joe] I don't know that we need to restrict this to a particular
> implementation.  I think it would be good to provide a management
> interface to do the generation.  It seems that it would be an 
> acceptable
> implementation to auto-generate it as well. 

[Rainer] As long as the syslogd is not required to auto-generate certs,
I am happy enough ;)

However, I wonder why it would be useful to auto-generate certs.
Probably I am overlooking somehting obvious. But: isn't cert
auto-generation equal to no authentication? After all, if a
*self-signed* cert is generated by the remote peer AND we accept it,
doesn't that essentially mean we accept any peer because the peer can
put whatever it likes into the cert? I do not see why this is any better
than having no cert at all...

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

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 9 May 2008 06:20:02 -0700 (PDT)

Hi,

On Thu, 8 May 2008, Rainer Gerhards wrote:
<some elided for brevity>
> than having no cert at all...

It minimally protects against masquerade and disclosure, two of the 
threats we agreed upon.  It will also provide a TCP-based transport for 
anyone who wishes/needs to have a mechanism to throttle the flow of 
packets for congestion control - something that you cannot do with the UDP 
transport.

Those are the reasons I can think of.  You do raise a good point by 
questioning this and I'd like to see some discussion from the WG.  Are 
these reasons sufficient to keep self-signed certs in the specification? 
If so, should specific comments be made about their use?

WG Chair Hat sort'a on, sort'a off: I'm thinking that a self-signed cert 
is the method of least effort to provide congestion control for syslog and 
it should be included in the document just for that reason.  This was the 
objection raised by the Transport ADs when they saw that 
syslog-transport-udp was the only REQUIRED transport.  I agree that 
self-signed certs don't really provide good protection and that should be 
noted in the Security Considerations Section.  If you don't agree with 
this, please object now.

If you do agree with this, does the following text work:
===
(Perhaps as a third paragraph in Section 4.2.4)

Self-signed certificates will provide minimal protection against 
modification and disclosure.  Their use will not provide effective 
protection against masqeurade unless they are used with certificate 
fingerprint authorization lists.  The use of self-signed certificates 
without certificate fingerprint authorization lists is NOT RECOMMENDED. 
However since tls is a tcp-based protocol, enabling tls, even with 
self-signed certificates, will effectively enable congestion control in 
the network.  See Section 8.6 of [syslog-protocol].

And perhaps merge the first three sentences of the above with the second 
paragraph in Sec Considerations section 5.1.  Current:
    The use of self-signed certificates with certificate fingerprint
    authorization lists provides more protection from masquerade and man-
    in-the-middle attacks than forgoing certificate validation and
    authorization.
===

Thanks,
Chris

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 9 May 2008 09:40:18 -0700

<snip>
> > acceptable implementation to auto-generate it as well.
> 
> [Rainer] As long as the syslogd is not required to 
> auto-generate certs, I am happy enough ;)
> 
> *self-signed* cert is generated by the remote peer AND we 
> accept it, doesn't that essentially mean we accept any peer 
> because the peer can put whatever it likes into the cert? I 
> do not see why this is any better than having no cert at all...
> 
[Joe] When I was thinking of auto-generation I was expecting the
certificate to be persistent and the fingerprint would be available to
be communicated out of band to the verifier.  If you generate a new cert
each time the process starts and the other side does not know the
fingerprint then what you say is true.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 9 May 2008 18:56:24 +0200

Joe and Chris,

the mailing list processor seems to be a bit slow these days. I sent a
long note this morning telling that I see value in automatically
generated self-signed certs. That mail also outlines when and why.

Please let me know if you did not receive it.

Thanks,
Rainer

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Friday, May 09, 2008 6:40 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: RE: -transport-tls-12, section 4.2.3 (fingerprints)
> 
> 
> <snip>

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 9 May 2008 11:07:17 -0700 (PDT)

Hi Rainer,

I'm also seeing the list behave slowly.  I don't think that I saw any 
message like that.  Can you check the archive and let us know if it's in 
there?

Thanks,
Chris

---

From: [email-masked]
Date: Fri, 9 May 2008 14:08:21 -0400

I like Rainer's proposal.  I had forgotten about the IESG desire for an 
out of box acceptable security.  I find this mechanism a bit dubious, but 
specifying a reasonably secure default configuration as a separate policy 
section could work.  How about a structure like this:

In the protocol section, since this is TLS and TLS is certificate 
oriented, we have the following requirements:

 - The TLS negotiation SHALL be configurable to verify certificates based 
on the following rules:
    - The local side shall negotiate based on a local certificate store. 
The local certificate store contains a list of certificate/server pairs.
    - The local side shall verify the remote side matches certificates 
found in one of three stores:
       - Specific certs where Certificate X is accepted for remote X. 
(This is oriented toward self-signed certs)
       - (optional) Signing certs, where Remote Y is accepted if its cert 
was signed by Certificate Y.  No chain of trust.
       - (optional) Signing certs, where Remote Z is accepted if its cert 
was signed by Certificate Z.  Chain of trust is accepted.

 Implementations may add other additional rules for other situations where 
connections are accepted, but these shall not be the default 
configuration. 

I made the use of signed certs optional because it pulls in all the other 
issues around revocation, etc.  I'm not too worried about having a server 
manage CRLs, updates, etc. but it could be a problem demanding that all 
clients also manage that.  I do worry about all the issues that come up in 
terms of preserving syslog function during serious network disruptions.  I 
do not want to see my problem reporting facility (syslog) fail just 
because I lost the PKI servers.  I'm think of cases where those servers 
had been physically destroyed, but 80% of the network still exists, e.g., 
Katrina.

In the policy section,

  - By default, if verification fails then the connection will be refused.
  - Other rules may be added, but shall not be the out of box default.

  - There shall be a maintenance method to create a self-signed cert. 
There shall be a maintenance method to import a self cert into any of the 
cert stores.
  - There may be a maintenance method for adding and removing certs in the 
other two kinds of cert stores.
  - There may be other authentication and authorization methods.

This then enables a reasonably useful default behavior.  With proper 
instructions a skilled home user could follow these rules.  It also 
enables direct implementation of many enterprise rules, although not all 
of them.  It can encourage developers to split their implementation so 
that new policy structures do not cause problems with the underlying 
protocol implementation.

The default home user scenario expectation is the following:

 - Installing a server:
   - Home user generates a self-signed certificate for the server, files 
it into the server local certificate store, and saves it for making copies 
for clients.  The corresponding private key lives somewhere in local 
configuration files and the user can be instructed that they should never 
ever give that information to other people.

 - Installing a client:
   - Home user generates a self-signed certificate for the client, files 
it into the client local certificate store, and saves it for making copies 
for servers.  Again, private key remains secret in configuration files 
somewhere.
   - Home user copies the client self-signed certificate into the server's 
specific certs for remotes.
   - Home user copies the server self-signed certificate into the client's 
specific certs for remotes.

This default does not scale to the large enterprise.  Adding the two kinds 
of signed cert stores extends the default configuration to support many, 
but not all, enterprise policies.  There will be other enterprise oriented 
methods.

This default does meet the needs of a small enterprise or skilled home 
user.  By making the default the use of self-signed certificates you avoid 
all the problems resulting from the absence of syslog oriented PKI 
infrastructures.  Even when there are suitable PKI infrastructures for 
identity management, these are not generally suitable for applications 
authentication management.  Introducing a PKI dependency will effectively 
delay the use of syslog-tls for many more years.

Using self-signed certificates leaves the home user with the need to copy 
around these certificates.  Moving files from here to there is something 
that can be handled by media, web aps, etc.  This is simplified by the 
lack of security requirements.  All you need is fingerprint display if you 
have reason to question the copying.  It will overwhelm the unskilled home 
user, but they probably won't be configuring syslog.  Someone who is 
setting up syslog can probably handle instructions for copying 
certificates from place to place.  Self-signed certs may take a few 
minutes to generate, but they are something that is not overly burdensome 
for syslog maintenance programs.

This also scales to the needs of many service providers.  If a service 
provider is installing thousands of dumb remote systems to unsupported 
locations (i.e., unskilled home user systems), they can preconfigure the 
dumb remote with self-signed certificates.  Since the rules only require 
matching, the service provider does not need to try to match hostnames, IP 
addresses, etc.  I would base the cert on the device serial number.  This 
would not be perfect security.  I could break into the dumb remote and 
steal the private key.  But it is a huge improvement over the current 
situation.  It does force me to break in, and none of the PKI structures 
protect against that.  Revocation is a bigger administrative problem but 
you can manage revocation of self-signed certificates for simple 
situations like this even at the service provider scale.

Kind Regards,

Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 
07660-2199, United States
http://www.agfa.com/healthcare/
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 9 May 2008 22:34:34 +0200

Hi Chris,

I just checked that archive. The message is scrambled there:

http://www.ietf.org/mail-archive/web/syslog/current/msg01861.html
http://www.ietf.org/mail-archive/web/syslog/current/msg01862.html

The complete one is containend in my blogpost at
http://rgerhards.blogspot.com/2008/05/more-on-syslog-tls-policies-and-ie
tf.html

Rainer 

> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Friday, May 09, 2008 8:07 PM
> To: Rainer Gerhards
> Cc: Joseph Salowey (jsalowey); [email-masked]
> Subject: Missing email? was: Re: [Syslog] -transport-tls-12, 
> section 4.2.3 (fingerprints)
> 
> Hi Rainer,
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 11 May 2008 21:51:15 -0700

Hi Robert,

I think this mostly makes sense. Some questions inline below: 
> 
> I like Rainer's proposal.  I had forgotten about the IESG 
> desire for an out of box acceptable security.  I find this 
> mechanism a bit dubious, but specifying a reasonably secure 
> default configuration as a separate policy section could 
> work.  How about a structure like this:
> 
> In the protocol section, since this is TLS and TLS is 
> certificate oriented, we have the following requirements:
> 
>  - The TLS negotiation SHALL be configurable to verify 
> certificates based on the following rules:
>     - The local side shall verify the remote side matches 
> certificates found in one of three stores:
>        - (optional) Signing certs, where Remote Y is accepted 
> if its cert was signed by Certificate Y.  No chain of trust.
>        - (optional) Signing certs, where Remote Z is accepted 
> if its cert was signed by Certificate Z.  Chain of trust is accepted.
>
[Joe] I'm not sure what the different between the last two are.  The
capability to chain certificates is indicated in the basic constraints
extension of a CA certificate and is validated by standard certificate
path validation (RFC 5280), is there a reason why this is not
sufficient?  Perhaps we can collapse the second two into one. 
 
>  Implementations may add other additional rules for other 
> situations where connections are accepted, but these shall 
> not be the default configuration. 
> 
[Joe] I believe that the ability to match a Subject name field should be
at least RECOMMENDED. 

> I made the use of signed certs optional because it pulls in 
> all the other issues around revocation, etc.  I'm not too 
> worried about having a server manage CRLs, updates, etc. but 
> it could be a problem demanding that all clients also manage 
> that.  I do worry about all the issues that come up in terms 
> of preserving syslog function during serious network 
> disruptions.  I do not want to see my problem reporting 
> facility (syslog) fail just because I lost the PKI servers.  
> I'm think of cases where those servers had been physically 
> destroyed, but 80% of the network still exists, e.g., Katrina.

[Joe] I think having just one mandatory option is fine. 

> There shall be a maintenance method to import a self cert 
> into any of the cert stores.
>   - There may be a maintenance method for adding and removing 
> certs in the other two kinds of cert stores.
> This then enables a reasonably useful default behavior.  With 
> proper instructions a skilled home user could follow these 
> rules.  It also enables direct implementation of many 
> enterprise rules, although not all of them.  It can encourage 
> developers to split their implementation so that new policy 
> structures do not cause problems with the underlying protocol 
> implementation.
> 
>    - Home user generates a self-signed certificate for the 
> server, files it into the server local certificate store, and 
> saves it for making copies for clients.  The corresponding 
> private key lives somewhere in local configuration files and 
> the user can be instructed that they should never ever give 
> that information to other people.
> 
>  - Installing a client:
>    - Home user generates a self-signed certificate for the 
> client, files it into the client local certificate store, and 
> saves it for making copies for servers.  Again, private key 
> remains secret in configuration files somewhere.
>    - Home user copies the client self-signed certificate into 
> the server's specific certs for remotes.
>    - Home user copies the server self-signed certificate into 
> the client's specific certs for remotes.
> 
> This default does not scale to the large enterprise.  Adding 
> the two kinds of signed cert stores extends the default 
> configuration to support many, but not all, enterprise 
> policies.  There will be other enterprise oriented methods.
> 
> This default does meet the needs of a small enterprise or 
> skilled home user.  By making the default the use of 
> self-signed certificates you avoid all the problems resulting 
> from the absence of syslog oriented PKI infrastructures.  
> Even when there are suitable PKI infrastructures for identity 
> management, these are not generally suitable for applications 
> authentication management.  Introducing a PKI dependency will 
> effectively delay the use of syslog-tls for many more years.
> 
> Using self-signed certificates leaves the home user with the 
> need to copy around these certificates.  Moving files from 
> here to there is something that can be handled by media, web 
> aps, etc.  This is simplified by the lack of security 
> requirements.  All you need is fingerprint display if you 
> have reason to question the copying.  It will overwhelm the 
> unskilled home user, but they probably won't be configuring 
> syslog.  Someone who is setting up syslog can probably handle 
> instructions for copying certificates from place to place.  
> Self-signed certs may take a few minutes to generate, but 
> they are something that is not overly burdensome for syslog 
> maintenance programs.
> 

[Joe] This is where a standard fingerprint format can help. 

> This also scales to the needs of many service providers.  If 
> a service provider is installing thousands of dumb remote 
> systems to unsupported locations (i.e., unskilled home user 
> systems), they can preconfigure the dumb remote with 
> self-signed certificates.  Since the rules only require 
> matching, the service provider does not need to try to match 
> hostnames, IP addresses, etc.  I would base the cert on the 
> device serial number. This would not be perfect security.  

[Joe] So in this scenario you match the end entity cert against a local
store, correct?  

>I 
> could break into the dumb remote and steal the private key.  
> But it is a huge improvement over the current situation.  It 
> does force me to break in, and none of the PKI structures 
> protect against that.  Revocation is a bigger administrative 
> problem but you can manage revocation of self-signed 
> certificates for simple situations like this even at the 
> service provider scale.
> 
> Kind Regards,
> 
> Research Scientist | HE/Technology Office T  +1 978 897 4860
> 
> Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield 
> Park, NJ, 07660-2199, United States 
> http://www.agfa.com/healthcare/ Click on link to read 
> important disclaimer:

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 12 May 2008 10:12:35 +0300

Hi,

I think the real difference here is not "CA-issued certs" vs.
"self-signed certs", but "accepting any cert" vs. "accepting certs 
you can verify (as trusted peers according to your local policy)".

We definitely want to discourage blindly accepting any certificate
(CA-issued or self-signed); but when properly verified, self-signed
certificates are not any less secure than CA-issued ones.

Best regards,
Pasi

> From: Chris Lonvick
> Sent: 09 May, 2008 16:20
> Subject: [Syslog] Self-signed certs - was: Re: 
> -transport-tls-12, section 4.2.3 (fingerprints)
> 
> Hi,
> 
> > *self-signed* cert is generated by the remote peer AND we accept
> > it, doesn't that essentially mean we accept any peer because the
> > peer can put whatever it likes into the cert? I do not see why
> > this is any better than having no cert at all...
> 
> threats we agreed upon.  It will also provide a TCP-based transport
> for anyone who wishes/needs to have a mechanism to throttle the flow
> of packets for congestion control - something that you cannot do
> with the UDP transport.
> 
> questioning this and I'd like to see some discussion from the WG.
> Are these reasons sufficient to keep self-signed certs in the
> specification?  If so, should specific comments be made about their
> use?
> 
> WG Chair Hat sort'a on, sort'a off: I'm thinking that a self-signed
> cert is the method of least effort to provide congestion control for
> syslog and it should be included in the document just for that
> reason.  This was the objection raised by the Transport ADs when
> they saw that syslog-transport-udp was the only REQUIRED transport.
> I agree that self-signed certs don't really provide good protection
> and that should be noted in the Security Considerations Section.  If
> you don't agree with this, please object now.
> 
> fingerprint authorization lists.  The use of self-signed
> certificates without certificate fingerprint authorization lists is
> NOT RECOMMENDED.  However since tls is a tcp-based protocol,
> enabling tls, even with self-signed certificates, will effectively
> enable congestion control in the network.  See Section 8.6 of
> [syslog-protocol].
> 
> And perhaps merge the first three sentences of the above with 
> the second paragraph in Sec Considerations section 5.1.  Current:
>     authorization lists provides more protection from 
>     masquerade and man-in-the-middle attacks than forgoing certificate 
>     validation and authorization.
> ===
> 
> Thanks,
> Chris

---

From: [email-masked]
Date: Mon, 12 May 2008 07:53:17 -0400

Some inline responses below.  Plus an explanation of the difference in 
chain of trust. 

The situation that I have seen is one where there are certificate issuer 
policy disagreements.  One CA (I'll call it Region 1) issues certificates 
that permit chain of trust by allowing further signatures.  The other CA 
(I'll call them Region 2) says that Region 1 is not allowed to issue 
certificates for Region 2.   This is just part of a much bigger turf war 
between Region 1 and Region 2.  Server does not want to get into the 
middle of the turf wars between Region 1 and Region2.   In theory, the 
complexity of policy disagreements can be unbounded.  In practice, I've 
found it sufficient to have two extra rules that over-ride the contents of 
the certificate.  I limit the ability to sign other certificates.  This 
seems to eliminate most of these policy overlaps.  I also limit the scope 
of certificate authority to a list of IP subnets.  These two seem to be 
sufficient to limit the scope of a certificate to just those machines that 
are within the policy domain of the source of certificates.

If you think it would be easier to standardize the ability to configure a 
list of IP subnets rather than chaining constraints, that would be just as 
effective.  It's a little more work to configure properly, but it deals 
with a wider range of policy disagreements.

Kind Regards,

"Joseph Salowey (jsalowey)" <[email-masked]> wrote on 05/12/2008 

> [Joe] This is where a standard fingerprint format can help. 

[rjh] I'm a little surprised that this has not been standardized somewhere 
in the PKI standards, but I've not found it yet.  We really shouldn't be 
dealing with this inside syslog.  The needs go far beyond syslog and it 
will be a problem if different applications use different forms.  Is there 
some way to shift this over to be their problem and get a common solution? 
 Are we already unable to specify a common solution because of an 
installed base of disagreement between CAs and fingerprint algorithms?

What I've seen from other certificate tools is the dual display of MD5 and 
SHA1 fingerprints, both in the numeric pair notation.  Could some similar 
approach be used?

> [Joe] So in this scenario you match the end entity cert against a local

[rjh] Yes.  That's one reason for scalability problems, but the service 
provider for dumb remotes generally has a database of many properties that 
are unique to each remote.  This adds one more item to that list, but 
since the provider is the issuer it can be prepopulated and maintained 
easily.