Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls

From: [email-masked]
Date: Wed, 7 Feb 2007 11:18:18 -0500

transport-tls should be designed to enable policy decisions.  This group is
not able to make policy decisions.  Some of this discussion is really
policy making.  Policy discussions within syslog should be oriented towards
ensuring that any reasonable policy can be properly supported.

For example, in my real world situations, the primary policy concern is
disclosure of audit information to unauthorized recipients.  This means
that the encryption aspect is most important, not the authentications.  I
can deal with a degree of uncertainty about the source and destination
authentications.

If you look inside what authentication really means to us you find several
kinds of authentication to manage:
 - Is the source machine authenticated and authorized to be on the network?
 - Is the source machine/process authenticated and authorized to be a
source of audit information?
 - The symetric questions for the destination machine.

My destination accepts all connections and has different processing
policies for incoming syslog information for the categories:
 - unauthenticated machine source
 - authenticated machine source, unauthenticated process
 - authenticated machine source and process

The differences are a degree of confidence about various source
characteristics.  No authentication ensures complete confidence, because it
is possible that both the source machine and process have been penetrated
by a hostile attacker.

The chain of trust to the various root certificate authorities is not
important.  Suppose I get a good certificate signed by the ABA.  What does
that mean?  Does the ABA know what machines are authorized to be on my
network?  no.  It means that someone with good credentials paid the ABA
money to get a certificate for that identity.  I will treat is as an
unauthenticated machine.

Suppose I get a certificate with a chain of signatures, the last of which
is my local hospital administration.  All those earlier signatures mean as
little as the ABA signature.  But that signature from the local hospital
administration means something.  Now I will consider this machine to be an
authenticated machine source.  (Process might still be unclear.)  I don't
need the rest of the chain.  A self-signed hospital administration CA is
good enough.  This can save money and bother.

The source side rule gets even stricter.  A hospital administration CA
signature is not enough.  They sign all the internal machine certificates.
I need the cert contents to be right.  Or, (more commonly) I demand that
the destination certificate match the single public cert that I provide to
authenticated source processes for logging.  This cert is self-signed by
the syslog destination machine.  The authorized internal machines and
processes use this to ensure that they have connected to the right
destination.

Now I have all three different categories that derive from my policies.
The chain of trust back to root CAs was not used much.  What I really need
is just the portion to the CA for the hospital.  It might happen to be
traceable to a root CA, but that doesn't matter in this situation.  I can
even live without it on a small network, by inverting the relationship and
copying the self-signed  public certs of the authorized source systems over
to the destination server.  This doesn't scale well, but for small networks
it can be easier than setting up the local CA.

R Horn

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Feb 2007 11:53:03 -0500

It sounds like trust anchor selection (what security people talk about
when the rest of the world talks about set of root CAs) is actually
very important to you.  It's just that you don't actually consider the
traditional root CAs part of your trust anchor set; you have a much
smaller trust anchor set.

--Sam

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Feb 2007 09:16:48 +0100

This is precisely the sort of thing that RFC 3195 attempted.  You want 
authenticated source?  You can have it.  You want authenticated server?  
You can have that too.  You can even have unauthenticated server with 
authenticated client.  As we've just released a revision draft, I 
suggest people look that over.  My guess is that the security 
considerations and the choices made here will require at least some 
additional review.

Please draft-lear-ietf-syslog-rfc3195bis-00.txt.

And that leads to my other question.  Why are we implementing a separate 
TLS protocol when 3195 and its successor both exists and has been 
implemented?  That seems to me rather redundant, and violates a tenant 
that we really should observe more: don't reinvent the wheel.

Eliot

[email-masked] wrote:
>
> transport-tls should be designed to enable policy decisions. This 
> group is not able to make policy decisions. Some of this discussion is 
> really policy making. Policy discussions within syslog should be 
> oriented towards ensuring that any reasonable policy can be properly 
> supported.
>
> For example, in my real world situations, the primary policy concern 
> is disclosure of audit information to unauthorized recipients. This 
> means that the encryption aspect is most important, not the 
> authentications. I can deal with a degree of uncertainty about the 
> source and destination authentications.
>
> If you look inside what authentication really means to us you find 
> several kinds of authentication to manage:
> characteristics. No authentication ensures complete confidence, 
> because it is possible that both the source machine and process have 
> been penetrated by a hostile attacker.
>
> important. Suppose I get a good certificate signed by the ABA. What 
> does that mean? Does the ABA know what machines are authorized to be 
> on my network? no. It means that someone with good credentials paid 
> the ABA money to get a certificate for that identity. I will treat is 
> as an unauthenticated machine.
>
> Suppose I get a certificate with a chain of signatures, the last of 
> which is my local hospital administration. All those earlier 
> signatures mean as little as the ABA signature. But that signature 
> from the local hospital administration means something. Now I will 
> consider this machine to be an authenticated machine source. (Process 
> might still be unclear.) I don't need the rest of the chain. A 
> self-signed hospital administration CA is good enough. This can save 
> money and bother.
>
> signature is not enough. They sign all the internal machine 
> certificates. I need the cert contents to be right. Or, (more 
> commonly) I demand that the destination certificate match the single 
> public cert that I provide to authenticated source processes for 
> logging. This cert is self-signed by the syslog destination machine. 
> The authorized internal machines and processes use this to ensure that 
> they have connected to the right destination.
>
> Now I have all three different categories that derive from my 
> policies. The chain of trust back to root CAs was not used much. What 
> I really need is just the portion to the CA for the hospital. It might 
> happen to be traceable to a root CA, but that doesn't matter in this 
> situation. I can even live without it on a small network, by inverting 
> the relationship and copying the self-signed public certs of the 
> authorized source systems over to the destination server. This doesn't 
> scale well, but for small networks it can be easier than setting up 
> the local CA.
>
> R Horn
>
> ------------------------------------------------------------------------
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Feb 2007 07:26:09 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> And that leads to my other question.  Why are we
    Eliot> implementing a separate TLS protocol when 3195 and its
    Eliot> successor both exists and has been implemented?  That seems
    Eliot> to me rather redundant, and violates a tenant that we
    Eliot> really should observe more: don't reinvent the wheel.

Eliot, at this point we're doing TLS because we're chartered to do it.
There was a long discussion within the WG about what direction to
take.  I don't know if you participated in that discussion but you
were certainly welcome to have done so.  That discussion resulted in a
charter which explicitly called out TLS.  That charter was sent out
for IETF wide review with additional text specifically calling
attention to the fact that this charter needed extra review.

Again, you were welcome to read that charter and comment on it.

I do think the question of why we're doing TLS has some good answers
in the WG archive.  You may not agree with them, but they are there in
the archive for you to explore.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Feb 2007 14:57:30 +0100

Sam,

I got involved recently because both chairs asked me to submit a draft 
to revise 3195 to reflect the work of -protocol-19.  I have done so.  
And so perhaps you can help me.

The charter calls for a secure transport.  The milestones say TLS 
(something that could easily be changed without community review, mind 
you).  A reasonable person could believe that perhaps we might actually 
*build* on the work that was already done with SYSLOG/BEEP/TLS.  As I'm 
relatively new to the party, I'll accept a pointer to the logic of the 
choice.  There being an IPR claim against the new work,  and the fact 
that multiple interoperable implementations of a proposed standard that 
could easily go to draft exist, I am hoping that pointer explains why 
this group is has put aside both interoperability and basic engineering 
principles of reuse.

Eliot

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 8 Feb 2007 15:16:13 +0100

Eliot,

TLS vs. 3195 *was* a community request and very though decision. You can
not simply change that bullet point.

Just a few quick pointers before I need to leave for a meeting:

http://www.mail-archive.com/syslog%40lists.ietf.org/msg00643.html

probably this:

http://www.mail-archive.com/syslog%40lists.ietf.org/msg00379.html

and then messages up to:

http://www.mail-archive.com/syslog%40lists.ietf.org/msg00182.html

This is eventually also relevant:

http://www.mail-archive.com/[email-masked]/msg00015.html

And this is probably the ultimate link, though quite time-consuming:

http://www.mail-archive.com/search?q=3195%20tcp&l=[email-masked]&
start=0

Sorry for that much reading material, but this has been discussed quite
controversal.

Rainer

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Thursday, February 08, 2007 2:58 PM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: [Syslog] Re: Why we're doing TLS
> 
> Sam,
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Feb 2007 15:29:05 +0100

Rainer,

Thanks.  Will read.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Feb 2007 09:29:54 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam, I got involved recently because both chairs asked me
    Eliot> to submit a draft to revise 3195 to reflect the work of
    Eliot> -protocol-19.  I have done so.  And so perhaps you can help
    Eliot> me.

I'll try!

    Eliot> The charter calls for a secure transport.  The milestones
    Eliot> say TLS (something that could easily be changed without
    Eliot> community review, mind you).  

Hmm.  I thought that was in the text of the charter, but you're
correct that it is not.  It was circulated to the community though
with the charter text.  I agree it would not require community review
to change, although it would be revisiting a WG decision.

    Eliot> A reasonable person could
    Eliot> believe that perhaps we might actually *build* on the work
    Eliot> that was already done with SYSLOG/BEEP/TLS.  As I'm
    Eliot> relatively new to the party, I'll accept a pointer to the
    Eliot> logic of the choice.  There being an IPR claim against the
    Eliot> new work, and the fact that multiple interoperable
    Eliot> implementations of a proposed standard that could easily go
    Eliot> to draft exist, I am hoping that pointer explains why this
    Eliot> group is has put aside both interoperability and basic
    Eliot> engineering principles of reuse.

I'd recommend asking the chairs here.  It's there job to call
consensus and to the extent that there is consensus on reasons for
decisions (not just the decisions themselves) to be able to explain
that.

I think that the implementers said they would implement syslog-tls,
but not something 3195-based.  But I was not heavily involved in that
discussion other than to make sure it took place.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 8 Feb 2007 12:15:18 -0500

Hi,

[speaking as co-chair]

Rainer has provided the links to the email discussions of this topic.

>From my point of view this was pretty straightforward. We have
implementers very involved in this WG, and the implementers expressed
a strong interest in TLS. They did not express a strong interest in
BEEP. The interest in TLS was so strong, it withstood the challenge of
overcoming an IPR disclosure and was preferred over proposals for
using SSH or DTLS instead.

I think there is a fallacy involved in claiming this is a reinvention
of the wheel. BEEP offers certain functionality **in addition** to the
functionality provided by using TLS. The WG decided the functionality
provided by TLS is important; the additional functionality provided by
having a BEEP layer between syslog and TLS is just not as important to
most users, and it is seen as unnecessary complexity for most syslog
usages. 

The WG consensus was very clear that TLS alone was preferred over
BEEP/TLS.

As co-chair, I struggle with whether there is enough interest in BEEP
to justify doing 3195bis rather than just moving 3195 to experimental
or historic. I see much less WG consensus on the importance of
updating 3195. The one segment of the syslog industry that has shown
an interest in 3195 is the IHE, an organization whose mission is to
promote the adoption of standards for the healthcare industry.
According to comments posted to the syslog WG, they have seen little
actual deployment of 3195 despite their efforts to promote it.

So if we are going to question whether one or the other solution
should be dropped, it is pretty clear to me as co-chair which one
should go. 

I have deliberately NOT looked to see if WG consensus is to drop 3195
because the dialogue about whether 3195 is in use is still ongoing,
and 3195bis is not yet part of our charter.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Thursday, February 08, 2007 9:30 AM
> To: Eliot Lear
> Cc: [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Thu, 8 Feb 2007 12:30:43 -0500

Hi,

[speaking as a contributor]

I learned a lesson about standards while working on SNMPv3. The cost
of added features required by only a segment of the market should be
borne only by that segment of the market. 

Just because one segment of the market wants the functionality of an
extra feature, that is not a strong argument for forcing everybody to
support the extra feature. A standard is better when the core
functionailty wanted by everybody is made mandatory, and add-on
features are optional, to be implemented/deployed only by those who
want those features. 

As we discussed message sizes in syslog, members of the IHE community
pushed for very large messages. The WG questioned whether the usage
proposed by IHE was within the applicability scope of syslog, which is
primarily designed for logging small messages to alert operators of
system anomalies. The WG chose to recommend the use of small
messsages, but to allow for implementations to choose to support large
messages, to meet this demand from one segment of the syslog
community.

I have not argued against doing 3195bis because that same segment of
the syslog community, members of the IHE, has stated there is no
viable alternative to 3195, and they would rather use a standard
protocol than invent a new one. They like the reliability provided by
BEEP. 

In my opinion, the rest of the community should not be forced to
implement BEEP to get TLS just because there is a special interest
group that wants BEEP. My impression as a contributor is that the WG
is willing to allow the option of BEEP as a supplement to TLS,
although some implementers have said they would not support it in
their products until there was customer demand for it. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Feb 2007 18:40:04 +0100

Dave,

I have read over not only the mailing list but the drafts involved.  The 
result quite frankly is perverse.  By implementing framing on top of TLS 
you are in fact REINVENTING BEEP only without the profile, mandatory 
TLS, and without the possibility for use of SASL.  You may not have 
started at this point - but that's where you are today.  So you *are* 
reinventing the wheel.

Eliot

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 8 Feb 2007 18:40:34 +0100

I can fully back David's statement as someone who actually *has*
implemented 3195. We will  not do any further 3195 implementation
efforts until some real market demand manifests. The current number of
deployments (after 3 or 4 years) is ... zero!

We are interested in TLS and will implement it when available. I have
already implemented the framing from syslog-tls and seen that it solves
real-world problems. The primary reason for implementig it was the need
for some (non-standardized) features that I could not get without it or
with the traditional LF-based framing.

Rainer

> From: David Harrington [mailto:[email-masked]]
> Sent: Thursday, February 08, 2007 6:31 PM
> To: 'Sam Hartman'; 'Eliot Lear'
> Cc: [email-masked]
> Subject: RE: [Syslog] Re: Why we're doing TLS
> 
> Hi,
>

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Thu, 8 Feb 2007 13:56:23 -0500

Healthcare doesn't demand beep, actually beep has been a problem for us
as well. We choose 3195 because there was no viable alternative. We have
paid the price of no implementations. I think that the current path of
syslog is ok with us. The MTU is sensitive, and I like your proposal to
deal with that.  We eagerly await and encourage the current
syslog-protocol work.

John 

> Sent: Thursday, February 08, 2007 11:31 AM

---

From: "tom.petch" <[email-masked]>
Date: Fri, 9 Feb 2007 11:03:09 +0100

Robert

I am unclear how you achieve authentication of the process as opposed to the
source machine and what demands, if any, that makes on syslog-transport-tls.

I see certificates sent by TLS as authenticating 'TLS' (omitting discussions
about what ever is authenticated, identity, person, process, machine ...) and
only authenticating something else to the extent that that is securely bound to
TLS so your choice lies outside the scope of syslog-transport-tls.  Or is there
some requirement on this I-D that I have not grasped, such as having
syslog-specific information in the certs?

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 07, 2007 5:18 PM
Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls

R Horn

--------------------------------------------------------------------------------

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 14 Feb 2007 10:27:21 -0800 (PST)

Hi All,

Apologies for the delay - I've still got a very heavy travel schedule for 
the rest of this week and most of next.

I agree that the WG consensus is to produce syslog-transport-tls.

Alex is re-drafting syslog-sign to ride atop syslog-protocol.  This will 
remove the dependencies of 3164 and 3195 from syslog-sign.

I would like to see the work on 3195bis proceed to complete that effort 
and allow it to be used as another transport for syslog-protocol.  I 
believe that it has beneficial characteristics that are not covered in 
syslog-transport-tls nor syslog-transport-udp.

Thanks,
Chris