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

["Joseph Salowey (jsalowey)" <[e-mail]>]

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. 

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