Re: [Syslog] -transport-tls-12, section 4.2 suggestion

[[e-mail]]

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,

Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T  [phone]

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

"Joseph Salowey (jsalowey)" <[e-mail]> wrote on 05/12/2008 
12:51:15 AM:

> 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 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.
> >
> [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. 
> 
> > 
> > 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.
> > 
> 
> [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?

> > 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? 

[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.
> 
> >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  [phone]
> > 
> > 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
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog