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

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

Sam, thanks for your reply, I think I am getting closer (and many thanks
for bearing with me)... 

> 
>     >> We also need to do the analysis of what security is actually
>     >> required by syslog deployments.  If the ansers are different,
>     >> we'll have to deal with that.
> 
>     Rainer> I thought we are doing this by refering to the sections in
>     Rainer> RFC 3164 and syslog-protocol-16. Do you think we need to
>     Rainer> elaborate more on the potential threats? If so, we
>     Rainer> definitely would need to reconsider that part of the work
>     Rainer> (also in -protocol, because it should mention at least all
>     Rainer> transport-independant threats).
> 
> no, that documents all the threats.  It doesn't actually make a call
> as to wether a particular threat is important to solve.
> 
> As an example, if integrity is not important to the way people use
> syslog, we might not consider it important to provide integrity.  On
> the other hand if integrity is important to how syslog is used but we
> cannot find a way to deliver integrity in a manner that is useful to
> people, we have to carefully consider what to do.

I now understand. But wouldn't it then make sense to create a separate
document for it? I have the feeling that would focus us better than when
the discussion is split among different places/documents. And if I
understood Eric Hibbard right, we may even have a volunteer to put it
together.

Or would it be better to put all of this into -protocol's security
considerations section?

> So, you and Chris have made an argument that we cannot provide
> integrity without decreasing the utility of our security solution.

Actually not. I wrote

###
On the other hand, it might make sense to mandate that a -transport-tls
(let me call it so for now) compliant implementation MUST support #2,
but MUST be configurable to not use it. That way, we would require that
each implementation supports full security but do not force the operator
to use it. However, I am not sure if such wording is within the scope of
the IETF.
###

(#2 was authenticated TLS) Look at the last sentence. I was not sure if
we could specify a configuration option inside a RFC. My intension is to
mandate in -transport-tls that the implementation MUST support anonymous
and authenticated TLS (its even easy to do), but that it must be
possible that that the operator decides which to use. Now that I have
written this sentence, it probably is already the solution.
-transport-tls mandates both as two separate modes. So either mode could
be configured by the operator. Then, it's security considerations
section could document the implications of mode selection. 

Rainer

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Jan 2006 13:09:03 -0500

>>>>> "Rainer" == Rainer Gerhards <[email-masked]> writes:

    Rainer> I now understand. But wouldn't it then make sense to
    Rainer> create a separate document for it? I have the feeling that
    Rainer> would focus us better than when the discussion is split
    Rainer> among different places/documents. And if I understood Eric
    Rainer> Hibbard right, we may even have a volunteer to put it
    Rainer> together.

I'm not sure this needs to be in a document although documenting it is
certainly not harmful.  It does need to be decided by the WG and the
WG does need to justify that decision.

The protocol document will naturally describe all the threats
(possibly by referring to 3164 for some of them) and will describe
which threats are handled by the mandatory to implement transport.
This can be split across documents as desired provided there is a
reference.

    Rainer> Or would it be better to put all of this into -protocol's
    Rainer> inside a RFC. My intension is to mandate in -transport-tls
    Rainer> that the implementation MUST support anonymous and
    Rainer> authenticated TLS (its even easy to do), but that it must
    Rainer> be possible that that the operator decides which to
    Rainer> use. Now that I have written this sentence, it probably is
    Rainer> already the solution.  -transport-tls mandates both as two
    Rainer> separate modes. So either mode could be configured by the
    Rainer> operator. Then, it's security considerations section could
    Rainer> document the implications of mode selection.

You can certainly do this.
It's even a reasonable solution if:

1) The people who need integrity are willing to deploy some sort of
   credential to the senders.  (This is more or less given; without
   it, I think you can prove no solution exists).

2) That credential is a valid TLS credential.

In particular note that TLS would not be useful in a Kerberos
environment,an environment where people had ssh public keys, etc.

So, from a theoretical standpoint, your proposed solution works.  The
WG needs to consider whether it meets the needs of operators in
practice.  If so, then that's a fine direction.

--Sam

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 11 Jan 2006 20:51:07 +0100

> environment,an environment where people had ssh public keys, etc.

Although not strictly related to this discussion, but TLS does support
kerberos based authentication, see RFC 2712

> practice.  If so, then that's a fine direction.

How to decide? Are there operators on this mailing list who we could
poll, or is it enough that at least three implementors are on the list
were involved in the discussions and seem to agree?

-- 
Bazsi

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Jan 2006 15:01:00 -0500

>>>>> "Balazs" == Balazs Scheidler <[email-masked]> writes:

    Balazs> Although not strictly related to this discussion, but TLS
    Balazs> does support kerberos based authentication, see RFC 2712

I just knew someone was going to bring that up.

I really need to right draft-hartmans-tls-2712-historic.  Briefly, the
major Kerberos implementations do not provide APIs necessary to
implement RFC 2712, the spec provides insufficient detail to be
implemented, the Kerberos vendors believe that providing the APIs
would be a bad idea from an abstraction standpoint, RFC 2712 only
supports DES, and RFC 2712 fails to use Kerberos in a manner that is
compatible with ongoing work in the Kerberos working group.

--Sam

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 11 Jan 2006 22:34:44 +0100

> compatible with ongoing work in the Kerberos working group.

While it is true that I only used kerberos5 and TLS separately, but
openssl 0.9.7e (the version I have on my notebook in source format) has
a file named ssl/kssl.c which seems to be an implementation of RFC2712.
But again this is probably not relevant.

-- 
Bazsi