Subject: RE: [Syslog] Re: Threat model and charter

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 11 Jan 2006 14:06:30 +0100

Hi Bazsi,

I agree with you, thanks for the great clarification. I think this is
also an excellent explanation why syslog-sign is necessary - and that a
secure transport and -sign have some different applications.

When it comes to priorities, I am still in favour of mandating a TLS
transport. The good in that is that you can actually guarantee
authenticy, even in a relay chain, as long as you (can) trust all
relays. In a typical corporate environment, I think this can be ensured.
-sign, on the other hand, does not solve the "message observation"
issue, which to the best of my knowledge is the driving force behind
most of todays syslog/ssl implementations.

The security considerations section for -transport-tls should list the
hop-by-hop restriction and provide information on mitigating it.

Rainer

> -----Original Message-----
> From: Balazs Scheidler [mailto:[email-masked]] 
> Sent: Wednesday, January 11, 2006 1:04 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: RE: [Syslog] Re: Threat model and charter
> 
> On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote:
> > Chris,
> > 
> > However, it *is* possible to authenticate the peers via X.509
> > certificates. Any TLS implementation can do client and server
> > certificate verification as part of the session setup 
> process. To the
> > best of my knowledge, some folks use this feature with 
> stunnel. So the
> > server accepts messages only from clients which are 
> authenticated via
> > their certificate (their certificate-based names are 
> configured at the
> > server side).
> 
> I basically agree with you, one minor addition that this X.509
> certificate based authentication is a hop-by-hop authentication and
> provided the operator trusts all devices on the message path and
> requires authentication on each hop, then message authenticity can be
> ensured. There's no per-message signature, thus it is not 
> proovable that
> a message was generated by a given device after it has been 
> received and
> stored. 
> 
> A parallel example: It is in a sense similar to client 
> authentication in
> HTTPS: if you upload a file using HTTPS where client certificate was
> required and validated, then the file on the server can be 
> trusted to a
> certain extent (as much as the HTTPS server can be trusted), however
> there's no means to prove that the file has not been tampered 
> with after
> it has been received. There was no signature _stored_ along 
> the file and
> no such signature exists in the HTTPS protocol itself, to do this the
> HTTPS client would need to generate a signature before 
> transmission and
> upload the signature along with the file itself.
> 
> Back to syslog: TLS and X.509 certificate authentication is hop-by-hop
> and authenticates the infrastructure and network transmission (like
> HTTPS itself), syslog-sign is a per-message authentication similar to
> the client-side-sign-and-upload-along-with-file example in HTTPS as
> described above.
> 
> -- 
> Bazsi
> 
> 
> 

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 11 Jan 2006 17:01:16 +0100

Chris,

I think a shared secret is not actually much less management overhead
then certificates. You need to distribute the shared secret anyway, much
the same as you distribute the certificates. 

>From the implementor's standpoint, I assume most implementors will use
openssl or a similar library. These libraries all support certificate
processing. In fact, it should be done as part of the session setup
process. So, in short, the implementor will already have almost
everything implemented that is necessary. The only thing missing are
some configuration file entries (or whereever the config is kept) that
allow the operator to specify which sending systems to accept (something
necessary for shared secrets, too). I tend to assume that shared secrets
are a bigger effort to implement than certificate based authentication.

>From the security perspective, there is the hop-by-hop problem Bazsi
mentioned. With TLS, you can only secure/authenticate from hop to hop,
leaving a gap. With TLS, you also do not get anything that you can
persist to the log file (at least not easily). The hash you propose
offers this. However, isn't that hash not just a signature? If so (and I
think so), we are back at syslog-protocol. I do not fully agree with
Baszi that it does not offer additional benefits. Relays do not
necessarily need to rewrite the signature, so it can provide a genuine
"stamp" of the orginal sender. It even can be persisted to a log file
and such. I think we should address this need in the context of
syslog-sign, which already put a lot of effort into it. 

In my point of view, the ideal solution is transmitting signed messages
via certificate-authenticated TLS. I haven't look at -sign lately, but I
think the signature could be based on the same cert that is used for TLS
authentication. A receiver could even be configured to check that the
signature matches the sender (obviously not an option when relaying, but
in other cases it might be useful). So we could use the same technology
for multiple purposes - plus the technology is close to what is already
being deploed (signing shouldn't be too hard for an implementor if
openssl is already used for TLS...).

Rainer

> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Wednesday, January 11, 2006 3:19 PM
> To: Balazs Scheidler
> Cc: Rainer Gerhards; [email-masked]
> Hi,
> I was thinking that if we have to do authentication then we 
> could try to 
> get consensus on a simple authentication mechanism - a shared secret. 
> Essentially, each sender would have to be configured with a 
> shared secret 
> before it could use TLS.  The receivers and relays would also 
> have that 
> information.  When a sender prepares a message, it would hash 
> the shared 
> secret with the formed message.  That hash could be placed in an SD 
> element ( [tlsAuthChk="12345678..."] ).  The recipient could 
> extract the 
> value, and then re-run the hash.  If the received hash is the 
> same as the 
> calculated hash then both the sender and the receiver must be 
> using the 
> same shared secret.  The caveat to this is in choosing the right hash 
> algorithm.  This mechanism and shared secret authentication 
> has been well 
> defined in many prior RFCs.  A lot of those RFCs used MD5 
> which is now 
> going out of favor.  Check out RFC 1305 (NTP - appendix D) 
> and RFC 2385 
> (authentication for BGP).
> 
> This suggestion tries to keep the ease-of-use of syslog.  Using 
> credentials stored in an X.505 certificate (of the recipient) would 
> provide a higher degree of authentication - shared secrets 
> can be much 
> more easily compromised (found, guessed, brute-forced, etc.) than the 
> validated credentials contained in a certificate.
> 
> If we can get consensus that an in-packet authentication 
> mechanism like 
> this is sufficient to meet our threat model, then we can 
> decide if the 
> shared secret is sufficient (the REQUIRED mechanism), and/or 
> if we want to 
> RECOMMEND a similar X.509 mechanism.  That would require having each 
> syslog sender to have an X.509 certificate, and have those signed and 
> available.  That just seems to me to be getting a bit far 
> away from the 
> ease-of-use that makes syslog so easy to deploy.
> 
> Thoughts?
> 
> Thanks,
> Chris
> 
> On Wed, 11 Jan 2006, Balazs Scheidler wrote:
> 
> > there's no means to prove that the file has not been 
> tampered with after

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 11 Jan 2006 21:24:30 +0100

Anton,

> (d) Do we have to address message observation threat? If not. 
> Then we don't need neither TLS/SSH - syslog-sign would do. 
> This does not prevent new transport to be used.  Some can be 
> used by just underlying tunnels anyway. 

Based on my (obviously limited) experience, this is the primary
objective that leads to SSL deployments today. So it seems to be
something that operators care about (which I can very well understand).

Rainer

---

From: [email-masked]
Date: Thu, 12 Jan 2006 13:25:57 -0500

I think that you are leaping too soon into implementation space.  That is
why the threat model is requested first.  Off the top of my head here are
some components of the threat model.  I organize these in terms of "Asset,
Threat, Mitigation".  There are certainly more threats because I know I
have left off all the environmental threats like fire, earthquake, backhoe,
etc.  There are probably more assets to consider.  And each of these
descriptions is very incomplete.

Asset: Secrecy of message contents
Threat: Network eavesdropping
Mitigation: Encrypted transport or encrypted message

Asset: Operational Characteristics of the network
Threat: Traffic Analysis
Mitigations:
  a) Encryption of identifying header contents (e.g., source
identification)
  b) Encryption of transport
  c) "blinding" with random meaningless traffic between genuine end-points
  d) "blinding" with random meaningless traffic between falsified
end-points

Asset: Proper functioning of syslog receivers (data sinks)
Threat: DoS attack  (there are actually many)
Mitigation: need to be enumerated.

Asset: Messages reaching desired receivers
Threat: Bogus masquerading receivers
Mitigation: Transport with node identification.  Note that message
encryption prevents the receiver from reading the message, but it does not
mitigate the issue that the message is lost because it goes to the wrong
destination.

Asset: Message integrity
Threat: Message modification
Mitigation: Digital checksums/ hash codes; digital signatures.

and so forth.

R Horn

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 18 Jan 2006 15:33:39 +0100

> Hi Rainer,
> 
> I'm still not seeing too many responses about how TLS is 
> authenticated. 

I guess you do not see them because most often it is used anonymous...
As of my experience, people are concerend about message observation.
Authentication is not their prime concern (my previous post detailled
why it isn't - hint: Intranet, "authentication" via sender IP address).

> Only Baszi has said that full X.509 certificates should be 
> used - similar 
> to how they are used in stunnel.  Is this acceptable to the 
> WG?  

Anyhow, TLS authentication is pretty easy. If you do it as in stunnel
(and that's always an option), you do not necessarily need to set up a
full PKI. Files with the private keys do well. Distributing them to the
senders should not be more hassle than distributing shared secrets.

> Should 
> the WG also consider using PSKs as proposed in RFC 4279?
> 
> Having authenticated TLS will address many of the threats 
> described in RFC 
> 3164.  Is this how the Working Group wants to proceed?  I'd 
> like to hear 
> from more people on this.

I recommend -transport-tls with two modes:

- unauthenticated TLS
- authenticatated TLS

both are mandatory to implement but the user can choose which one he
needs (that means that nobody is forced to distribute certs or PKI if
only message observation shall be mitigated).

Rainer
> 
> Thanks,
> Chris
> 
> On Wed, 18 Jan 2006, Rainer Gerhards wrote:
> 
> > Chris,
> >
> >> I have not heard back from anyone about how SSL is currently being
> >> implemented for syslog.  From that, I might conclude that message
> >> confidentiality is not a priority for the community.
> >> (Responses to that
> >> would be welcome.)
> >
> > I thought that these postings pointed out what is done:
> >
> > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html
> > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html
> > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html
> > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html
> >
> > You might also want to review some of these documents:
> > http://www.stunnel.org/examples/syslog-ng.html
> > http://freshmeat.net/articles/view/1781/
> >
> > Rainer
> >
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 23 Jan 2006 08:19:46 +0100

I agree with Darren.

Rainer 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Darren Reed
> Sent: Friday, January 20, 2006 3:07 PM
> To: Chris Lonvick
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Syslog] Re: Threat model and charter
> 
> Chris,
> 
> WG?  Should 
> I think supporting TLS and all of its authentication options is what
> we should do in our documentation.  Or to put it another way, we
> shouldn't worry ourselves with restricting use of TLS to a particular
> authentication model, be it PSK or X.509 or something else.
> 
> What we should be doing is letting systems people use whatever they
> feel comfortable with and are already deploying...which makes me
> think, we need to be saying "authentiation style(s) X must be 
> included",
> to set a minimum level of interoperability between all 
> implementations.
> 
> I believe that minimum level should be PSK as anything certificate
> orientated can quickly become complicated, not just for management
> but initial use.
> 
> So to express this in RFC terms, TLS PSK MUST be supported,
> TLS .... SHOULD be supported, TLS ......
> 
> Darren
>