Re: [Syslog] Document shepherd report of AD concerns

["Rainer Gerhards" <[e-mail]>]

Hi Pasi and David,

Thanks for the recent clarifications. 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Thursday, May 15, 2008 9:35 PM
> To: [e-mail]; [e-mail]
> Subject: Re: [Syslog] Document shepherd report of AD concerns
> 
> 
> To add to David's email, and Tom's concern that "[we] should only
> change what the IESG wants us to to; and that I do not see":
> 
> All the changes in version -12 were done in response to my (and
> earlier Sam's) AD review comments. However, based on the recent
> discussions, it's clear that the text isn't final yet, and needs 
> some improvement.
> 
> The intent of 4.2.1/4.2.2 was to specify a minimum level needed for
> interoperability, not to prevent deployments for making their own
> policy decisions. That minimum level can be pretty small -- and
> there's some room for discussing what exactly it should be -- but it
> must provide reasonable security for many typical syslog uses (and in
> this particular case, having a full-fledged PKI as the only approach
> isn't really a credible solution).
> 
> Perhaps we could rephrase the text to make this more clear, and 
> also explain the motivation for these requirements.  Here's a first 
> shot at that text -- feedback is welcome.
> 
>    To prevent disclosure of syslog message contents, the transport
>    sender (TLS client) has to verify that it is sending the messages
>    to an authorized transport receiver (TLS server).
> 
>    Typically, a client application using TLS achieves this by
>    performing certification path validation (using previously
>    configured trust anchors), and comparing the certificate subject
>    name against the expected server name (or a list of authorized
>    server names).
>  
>    Syslog transport senders MUST support this approach. The minimum
>    requirements for certification path validation and subject name
>    comparison are specified later in this section.
> 
>    However, syslog is frequently used in environments where assuming
>    PKI deployment is not realistic. Thus, an alternative that provides
>    a reasonable level of security, while being simple to deploy, is
>    desired. This document requires that syslog transport senders MUST
>    support a mechanism where the authorized transport receivers are
>    identified by certificate fingerprints. The minimum requirements
>    for this mechanism are specified in Section 4.2.3.
> 
>    However, these requirements are intended to specify only a minimum
>    level of compliance required for interoperability.  Implementations
>    MAY support additional mechanisms for expressing more complex
>    policies, validating certificates, and determining whether a
>    certificate represents an authorized transport receiver.
> 
>    There can be extreme situations where it is not feasible to verify
>    that the transport sender is communicating with an authorized
>    transport receiver. A syslog implementation MAY provide an option
>    to skip this verification (i.e., accept any server certificate).
>    This option MUST NOT be enabled by default.

This text is along a fine line of differences: it talks about the sender
checking the server. It is the same model that HTTPS uses (sorry, but
this *is* the analogy). The server is authenticated but the client not.

The text is NOT talking about the server authenticating the client.

Let's look at a syslog.conf line:

*.* @@<server>

Where server is the remote server's name or IP address. This is
(extended) rsyslog syntax, but in essence it is the same for all
implementations. What always must be configured is the name of the
server.

So it is quite easy to check the server identity (again, just like
https) - we can simply compare the name from the cert to what was
configured as <server>. Note that this process is fully automatic if the
sender ships with a set of trusted root certs (like web browsers do) and
the server operator obtained a cert from one of those authorities. As I
said myself, a home user is not likely to pay the associated fee, but a
small biz may do. The advantage is obvious, because we have instant
security without any need to configure anything (that would not be
configured in any case).

A server cert fingerprint requires a bit more of configuration, but can
obviously be a good solution in scenarios where neiterh PKI nor paid
public certs are available.

If we look at the server, there is no such semi-automatic authentication
available. The client can not actually be authenticated. We have a hop
by hop archetecture and we have no required indication of relays inside
the message. So for the server, we can not have a check if client is
authentic (is who it claims it is) but instead we can just have access
control - we can check if the client is permitted to send to us. IMHO
this is different from verifying authenticity. In a relay chain, the
relay may still receive spoofed messages from a relay in front of it. So
we can not autenticate the messages themselfs but only provide access
control for the machine that is connecting to us. Once we are beyond
that stage, we may still receive spoofed, faked, whatever messages. We
can only trust messages if all relays in the chain are configured with
TLS and the same access control. For *nix based syslogds, even that does
not help, because the message on the OS log socket may already be
spoofed.

Thus, I consider authenticating the originator or relay to the receiver
(or relay) quite less important than authenticating the server to the
client. 

This is the reason that I propose to not only split these two modes (as
already happened), but have different minimal requirements for them.

A useful mode to actually authenticate messages is to check the hostname
provided inside the message against the clients certificate. Of course,
this only work on the first hop after the originator, only if we have
syslog-protcol formatted messages and is still somewhat vulnerable to
local log injection in a *nix environment (there is no cure against
that). If one thinks along these lines, it would be quite useful to have
an additional access policy the requires a given server to accept only a
given set of hostnames from a remote client (those that it is permitted
to relay from). This check is probably more useful than the initial
cert-based access control check because it (somewhat) protects against
injecting malicious messages (somewhat, because it still depends on the
full chain being properly protected, it is just easier to detect simpler
attacks, what I find useful).

Just my 2cts... Again, I can live with whatever we specify, because I
can extend it and the current text provides good enough opportunity to
switch back to anonymous authentication by a simple on/off switch (which
defaults to "security on"). But I think it would be useful to get the
best possible defaults. I fear that too-tight requirements are
counter-productive and people will simply turn that switch to "off"
instead of investigating and properly configuring.

Rainer
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: David Harrington
> > Sent: 15 May, 2008 21:02
> > To: [e-mail]
> > Subject: [Syslog] Document shepherd report of AD concerns
> > 
> > Hi,
> > 
> > Tom asked for a review of the IESG concerns.
> > As document shepherd, let me address that question.
> > 
> > This email shows the AD comments as the draft progressed 
> since -11-. 
> > Some WG input was also taken into consideration during the document
> > revisions.
> > 
> > Following the publication of -11-, Sam Hartman said:
> > "Dave, the syslog tls document is much clearer and I think it does a
> > good job of specifying what implementations need to do.
> > I think  this is a huge improvement.
> > 
> > However  I have two major problems.
> > 
> > 1) The default/recommended configuration requires managed trust
> >    anchors, a working DNS deployment and certificates provisioned to
> >    syslog servers.  I do not find it plausible that operators will
> >    actually do this and so I do not find the specification credible.
> > 
> > 2) The spec talks about caching of certificates in a manner 
> similar to
> >     ssh, but does not discuss operational concerns such as key
> >     rollover.  Jeff, any chance you could help the syslog working
> >     group understand the tradeoffs around leap of faith?
> > "
> > 
> > Jeff Hutzelman provided expert advice on behalf of Sam:
> > "I can try.  It may be worth noting that I don't think ssh 
> talks much
> > about 
> > server key rollover, and it certainly isn't done much in practice.
> > What 
> > does happen is server keys changing because of a machine being
> > reinstalled 
> > or some similar event.  The approaches open to SSH in that case
> > (prompt the 
> > user, or just notify them and fail so they can fix it and try again)
> > don't 
> > work so well with syslog, where the originator of a message likely
> > can't 
> > fix the problem, and the way to notify the person who can 
> is to send a
> > 
> > syslog message!"
> > 
> > Then the AD token passed from Sam to Pasi, who suggested:
> > "Here's one idea how to handle certificates for TLS in 
> order to make 
> > it reasonably secure (in most cases), yet also deployable:
> > 
> > - When a tranport sender configures the address of 
> transport receiver,
> > and enables TLS, allow the following choices:
> > 
> >   1) configure set of trust anchors, and a name to be 
> matched against
> >      the cert. If the transport receiver address is 
> configured as DNS
> >      name, this name would usually be the same one. If the transport
> >      receiver address is configured as IP address, this one could
> >      be IP address (but could be also a domain name).
> > 
> >      (Note: in no situation, the result of A/AAAA or PTR lookup
> >      would be used when checking the certificate. This part of the
> >      current spec isn't correct.)
> > 
> >   2) configure the "certificate fingerprint" of the peer (typically 
> >      a 40-digit hex string). Cut-and-pasting that from one 
> SSH window 
> >      to another isn't the world's friendliest UI, but would 
> be doable
> >      by admins, and is couple of orders of magnitude less work than 
> >      setting up a real PKI.
> > 
> >   3) configure "anything goes, don't verify the cert" (obviously,  
> >      not very secure; SHOULD NOT be done)
> > 
> > - A transport receiver would have similar choices:
> > 
> >   1) configure set of trust anchors, and a list of names (or 
> >      wildcards matching names) to be matched against the
> >      certificates; everyone listed here would be OK.
> > 
> >   2) configure list of certificate fingerprints that are OK.
> > 
> >   3) configure list of transport (IP) addresses/netmasks that are 
> >      allowed to send messages regardless of the certificate
> >      (obviously, not very secure; SHOULD NOT be done)
> > 
> > - I've intentionally omitted "SSH style leap of faith" (called "MAY
> >   cache the certificate presented by its peer so it can compare the
> >   certificate with what is presented in subsequent connections" in
> >   current spec). .
> > 
> >   It could be added (but has some operational issues); or we could
> >   specify slightly similar (but not quite) functionality 
> where instead
> >   of typing in the 40-digit fingerprint, the management interface
> >   would fetch the fingerprint from the peer, show it to the
> > administrator,
> >   and the admin would then compare it against something (e.g., what
> >   he/she sees in some other SSH window), and confirm that 
> they match.
> >   There are some issues with this, though.... (user studies 
> made with 
> >   similar approaches show that most users click "yes, they 
> match" even
> >   when shown two totally different values).
> > 
> > - We probably need to require that everyone must be able to 
> generate a
> >   keypair and self-signed certificate, and calculate/display the
> >   fingerprint of the certificate (in some management interface).
> > 
> > Has something like this (in particular, using the fingerprint in 
> > cases where deploying PKI isn't feasible) suggested before?  Do 
> > you think it would be operationally workable?
> > 
> > If you think this might make sense, I can post something on the
> > mailing list, too. But this is just one preliminary idea -- if 
> > there are other ideas that would solve the issues, I'm in no way
> > saying it must be done this way."
> > 
> > Joe did a revision which Paso reviewed, and commented:
> > "Joe: thanks for working on this; I think we're making good
> > progress, and I'm optimistic that we could get this draft
> > done soon.
> > 
> > However, some of the TLS/certificate related text in version -11 
> > was *really*...err... unclear, so I think we need to rewrite
> > it to some extent before taking it to the WG list (fortunately, 
> > the whole text is only two pages, so this shouldn't be
> > too much effort). We also have an option (fingerprints)
> > that wasn't present before, so we need to recheck the WG 
> > consensus anyway.
> > 
> > Some proposed text fragments from me (Joe, please feel free 
> > to edit as you like):
> > 
> > 4.2
> > 
> >    TLS typically uses certificates to authenticate
> >    peers. Authentication and authorization of the TLS server
> >    (transport receiver) is described in Section 4.2.1; 
> authentication
> >    and authorization of the TLS client (transport sender) 
> is described
> >    in Section 4.2.2.
> > 
> > 4.2.1 Server authentication/authorization
> > 
> >    The transport sender (TLS client) has three different options for
> >    authenticating and authorizing the transport receiver 
> (TLS server):
> > 
> >    (Pasi's note: it could be sufficient is one of the following
> >    two is a MUST, and the other one is a SHOULD.)
> > 
> >    o  Certification path validation and subject name 
> verification: the
> > 
> >       client is configured with one or more trust anchors, and for 
> >       each transport receiver, the name to be matched against the  
> >       certificate. This option MUST be supported.
> > 
> >    o  Certificate fingerprints: For each transport receiver, the
> > client 
> >       is configured with a fingerprint of the server's certificate
> >       (which can be self-signed). This option MUST be supported.
> > 
> >    o  No server authentication/authorization: The client is 
> configured
> > 
> >       to accept any certificate from the server. This option
> >       MAY be supported, but MUST NOT be enabled by default.
> > 
> >    For certification path validation, client implementations MUST
> >    provide a mechanism for configuring one or more trust 
> anchors, and
> >    MUST perform certification path validation as specified in
> >    [RFC3280bis].
> >  
> >    For subject name verification, client implementations 
> MUST support
> >    configuring, for each transport receiver, the name to be matched
> >    against the certificate.  This name may be the host name or IP
> >    address used when opening the TCP connection, or a distinct host
> >    name (...details of name matching...MUST support DNS names,
> >    probably others can be MAY...)
> > 
> >    To support certificate fingerprints, client implementations MUST
> >    support configuring, for each transport receiver, a 
> fingerprint of
> >    the server certificate. See Section 4.2.3 for details.
> > 
> >    If server authentication/authorization fails, the client 
> SHOULD log
> >    the error in some form or another (...more text...)
> > 
> > 4.2.2 Client authentication/authorization
> >   
> >    The transport receiver (TLS server) has three different 
> options for
> >    authenticating and authorizing the transport sender (TLS client).
> > 
> >    (Pasi's note: it could be sufficient is one of the following
> >    two is a MUST, and the other one is a SHOULD.)
> > 
> >    o  Certification path validation and subject name verification:
> >       the server is configured with one or more trust anchors,
> >       and a set of names (or wildcard patterns) to be matched 
> >       against the certificates.  This option MUST be supported.
> > 
> >    o  Certificate fingerprints: The server is configured with the 
> >       fingerprints of client certificates. This option MUST be
> >       supported.
> > 
> >    o  No client authentication/authorization (or authorization
> >       based only on connection source IP address): This option MAY 
> >       be supported, but MUST NOT be enabled by default.
> > 
> >    Certification path validation and subject name verification work
> >    as described in Section 4.2.1 above, with following addition: 
> >    (...locally configured client name can be a wildcard; different 
> >    from wildcard-in-cert case...)
> > 
> >    To support certificate fingerprints, server implementations MUST
> >    support configuring with a list of fingerprints of authorized
> >    certificates. See Section 4.2.3 cor details.
> > 
> > 4.2.3 Certificate fingerprints
> > 
> >    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.
> > 
> >    <describe details of certificate fingerprint calculation here. 
> >    this should be compatible with the way e.g. current web browsers
> >    calculate fingerprints> "
> > 
> > and after Joe did some additioon revising, Pasi said:
> > "I'd be interested in getting the WG's opinion on this (in
> > particular, the fingerprint stuff) as soon as possible."
> > 
> > At this point, Joe revised and published the draft and we brought it
> > to the WG for comment.
> > 
> > Hope this helps
> > 
> > 
> > David Harrington
> > [e-mail]
> > [e-mail]
> > [e-mail]
> > 
> > _______________________________________________
> > Syslog mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/syslog
> > 
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/syslog
> 
_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog