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

From: "David Harrington" <[email-masked]>
Date: Mon, 5 Feb 2007 11:13:41 -0500

Hi WG,

[speaking as co-chair]

As co-chair, I will need to advise Miao to remove support for generic
certificates unless there is overwhelming WG consensus to keep them,
and the explanation of why reuse of private keys is necessary will
need to be compelling. Please read RFC4107 (which is short).

There are ambiguities in the TLS document regarding who MUST
authenticate that will need to be tightened up. As the email from Tom
reflects, part of the problem is the ambiguity in the definition of
relay; I think it needs to be made clearer in the -protocol- document
that a relay is a receiver and is a sender, and clearer in the -tls-
document that authentication is hop-by-hop. 

Personally, I think we should make authentication more mandatory than
is currently described, but the WG needs to reach such a consensus. If
we keep the optional authentication(s), then the WG should justify in
the document why it makes "protocol sense" for the authentication(s)
to be optional.

The WG needs to develop the table showing how the various
authentication options mitigate threats, especially MITM threats, and
we should have text that describes this as well.

Please work with Miao to address these issues.

Thanks,
David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG 

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 12:53 PM
> To: Miao Fuyou; 'Sam Hartman'; [email-masked]
> Subject: Relays was Re: [Syslog] AD Review for 
> draft-ietf-syslog-transport-tls
> 
> <inline>
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Miao Fuyou" <[email-masked]>
> To: "'Sam Hartman'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 31, 2007 5:50 AM
> Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls
> 
> > Hi Sam,
> >
> > Thanks for the review! My response is inline.
> >
> > Regards,
> > Miao
> >
> > > -----Original Message-----
> > > From: Sam Hartman [mailto:[email-masked]]
> > > Sent: Wednesday, January 31, 2007 7:23 AM
> > > To: [email-masked]
> > > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls
> > >
> > > Hi, folks.  I had no comments on the UDP draft or the main
> > > protocol draft so I have forwarded them to IETF last call.
> > >
> > > I do have some concerns with the TLS draft.
> > >
> <snip>
>  >
> >
> > > Are senders and relays required to have a certificate and to
> > > use that certificate?
> > >
> >
> > It is not required, but it is preferrable for some deployment
where
> > malicious senders may send lots of messages to overwhelm 
> the receiver.
> >
> Sam
> 
> I have a slightly different view.  To quote the I-D, where it says
> "The sender/relay should initiate a connection to the receiver"
> I take that as the sender initiates a connection to the 
> receiver if no relay is
> present or to the relay (when present), the relay (when 
> present) initiates the
> connection to the receiver (collector).  Relay and receiver 
> become TLS Servers
> and insofar as TLS Servers have certificates, the relay will have
one!
> 
> When the next paragraph says
> "When a sender/ relay authenticates a receiver it MUST 
> validate the certificate"
> I take that to mean that the sender authenticates the 
> receiver if no relay is
> present or the sender authenticates the relay (when present) 
> and the relay
> authenticates the receiver.
> 
> relay and sender are TLS clients.
> 
> I appreciate that this is hop by hop security and not ideal 
> end to end security.
> 
> Tom Petch
> > > --Sam
> > >
> > >
> > > _______________________________________________
> > > Syslog mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> >
> >
> >
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 5 Feb 2007 17:32:11 +0100

David,

let me start with the relays: given the recent discussion, I think it
would be much more advisible to add a few sentences to -protocol (I
already made a proposal) that clarifies the situation. It is not much
that needs to be added. It would resolve all those other issues.

Regarding generic certificates, I do not see an overwhelming reason to
have them (and I was one of them who liked them). I agree with Sam that
there can be placed unique certificates on the device during the
manufacturing process. Another story, however, is the need to
authenticate/verify a device. Without any doubt, there is more than one
scenario where authentication based on the device is mandatory.

However, syslog is also often deployed in (low end) scenarios where the
(part-time) operator is simply interested receiving log messages from
his 5 or so routers. This admin is often not very knowledgable. If we
now require that admin to either

a) configure access rules for all (though few) devices
or
b) use unencrypted UDP syslog

I am sure many of these admins will resort to b) because a) requires too
much learning. In the essence, strong security/authentication would
bring us less real-world security (pretty much the same thing with
strong passwords ... so strong that they are "stored" on post-it notes
under the keyboard).

So I would not like to see client and server authentication to be a
MUST. Well ... a MUST for an implementation to have that capability
would be OK. But an admin must be capable to configure sender and/or
receiver to work without authentication. No matter what we specify in
-protocol, that capability will be available in all implementations that
I foresee. IMHO an uncoditional MUST would create a false sense of
security ... and the most insecure thing is false sense of security.

Rainer

> From: David Harrington [mailto:[email-masked]]
> Sent: Monday, February 05, 2007 5:14 PM
> To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; [email-masked]
> Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-
> transport-tls
> 
> Hi WG,
> 
> [speaking as co-chair]
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Feb 2007 11:39:56 -0500

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

    Rainer> So I would not like to see client and server
    Rainer> authentication to be a MUST. Well ... a MUST for an
    Rainer> implementation to have that capability would be OK. But an
    Rainer> admin must be capable to configure sender and/or receiver
    Rainer> to work without authentication. No matter what we specify
    Rainer> in -protocol, that capability will be available in all
    Rainer> implementations that I foresee. IMHO an uncoditional MUST
    Rainer> would create a false sense of security ... and the most
    Rainer> insecure thing is false sense of security.

I'm not asking for mandatory authentication for all the reasons you
cite.

What I'm asking for is

1) Mandatory behavior such that all implementations can work
   together. This includes things like if authentication is going to
   be optional to implement, then there must be an option not to
   require it.

2) A description of what the possibilities are for authentication and
   what security properties you actually get based on what options you
   select when you deploy syslog.

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Mon, 5 Feb 2007 11:57:14 -0500

I would recommend against constraining the key management in -tls-. This
is a POLICY decision, not a protocol decision. (as highlighted by
RFC4107)

John 

> Sent: Monday, February 05, 2007 10:14 AM
> Subject: RE: Relays was Re: [Syslog] AD Review 
> fordraft-ietf-syslog-transport-tls
> 
> Hi WG,
> 
> [speaking as co-chair]
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 5 Feb 2007 12:10:52 -0500

Hi,

I believe this is a protocol decision only to the point of requiring
that compliant implementations provide support for the functionality.
I agree that whether operators choose to use it during deployment is a
policy decision and not a protocol decision.

I wonder why an operator would choose to use a TLS transport without
authentication, rather than simply using a non-secure transport.

dbh

> From: Moehrke, John (GE Healthcare) [mailto:[email-masked]]

> Sent: Monday, February 05, 2007 11:57 AM
> To: David Harrington; tom.petch; Miao Fuyou; Sam Hartman; 
> [email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 5 Feb 2007 18:25:44 +0100

> authentication, rather than simply using a non-secure transport.

To prevent casual observation. In my experience, this is the primary
driving force behing syslog/ssl deployments. And, yes, I agree we should
educate operators to use authentication, too.

Rainer

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Feb 2007 13:20:42 -0500

>>>>> "Moehrke," == Moehrke, John (GE Healthcare) <[email-masked]> writes:

    Moehrke,> I would recommend against constraining the key
    Moehrke,> management in -tls-. This is a POLICY decision, not a
    Moehrke,> protocol decision. (as highlighted by RFC4107)

I'm not sure I disagree with your recommendation although I do
disagree with the claim that RFC 4107 treats key management as a
policy rather than a protocol matter.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Feb 2007 13:24:10 -0500

>> I wonder why an operator would choose to use a TLS transport
    >> without authentication, rather than simply using a non-secure
    >> transport.

    Rainer> To prevent casual observation. In my experience, this is
    Rainer> the primary driving force behing syslog/ssl
    Rainer> deployments. And, yes, I agree we should educate operators
    Rainer> to use authentication, too.

    Rainer> Rainer

To be more specific, passive attackers cannot influence the integrity
or confidentiality of messages.  

In addition, active attackers who do not attack existing connections
are unaware of the contents of syslog messages that are sent.

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 06 Feb 2007 11:02:28 +0800

Hi, 

I think there are other things to consider to decide SHOULD or MUST an
authentication::

1, From deployment perspective, it is not very difficult to enable server
authentication because the population of servers is usually not as many as
that of clients, the certificates are only required to be created for the
server rather than plenty of clients: printers, routers and hosts. So, I
think server authentication is not a major reason for the operator to not
deploy TLS. However, client authentication is highly possible the reason
because the considerable effort for device certificate deployment. 

2, If no authentication exists, it is possible for an adversary to launch a
MITM attack when TLS connection initializes, it talks with server pretending
to be client and client to server. In this case, no confidentiality and
integrity is conserved. 

So, I would like server authenticaiton to be a MUST rather than SHOULD. For
client authentication, it may be SHOULD, even MAY. 

Thanks,
Miao

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Tuesday, February 06, 2007 12:32 AM
> let me start with the relays: given the recent discussion, I 
> think it would be much more advisible to add a few sentences 
> to -protocol (I already made a proposal) that clarifies the 
> situation. It is not much that needs to be added. It would 
> resolve all those other issues.
> 
> Regarding generic certificates, I do not see an overwhelming 
> reason to have them (and I was one of them who liked them). I 
> agree with Sam that there can be placed unique certificates 
> on the device during the manufacturing process. Another 
> story, however, is the need to authenticate/verify a device. 
> Without any doubt, there is more than one scenario where 
> authentication based on the device is mandatory.
> 
> (part-time) operator is simply interested receiving log 
> messages from his 5 or so routers. This admin is often not 
> very knowledgable. If we now require that admin to either
> 
> a) configure access rules for all (though few) devices or
> I am sure many of these admins will resort to b) because a) 
> requires too much learning. In the essence, strong 
> security/authentication would bring us less real-world 
> security (pretty much the same thing with strong passwords 
> ... so strong that they are "stored" on post-it notes under 
> the keyboard).
> 
> So I would not like to see client and server authentication 
> to be a MUST. Well ... a MUST for an implementation to have 
> that capability would be OK. But an admin must be capable to 
> configure sender and/or receiver to work without 
> authentication. No matter what we specify in -protocol, that 
> capability will be available in all implementations that I 
> foresee. IMHO an uncoditional MUST would create a false sense 
> of security ... and the most insecure thing is false sense of 
> security.
> 
> Rainer
> 
> > > > > Are senders and relays required to have a certificate 
> and to use 
> > > > > that certificate?
> > > > >
> > > >
> receiver if 
> > > no relay is present or to the relay (when present), the 
> relay (when
> > > present) initiates the
> > > connection to the receiver (collector).  Relay and 
> receiver become 
> > > TLS Servers and insofar as TLS Servers have certificates, 
> the relay 
> > > will have
> > one!
> > >
> validate the 
> > > certificate"
> receiver if no 
> > > relay is present or the sender authenticates the relay (when 
> > > present) and the relay authenticates the receiver.
> > >
> > > I appreciate that this is hop by hop security and not 
> ideal end to 
> > > end security.
> > >
> > > Tom Petch
> > > > > --Sam
> > > > >
> > > > >

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Feb 2007 23:47:01 -0500

>>>>> "Miao" == Miao Fuyou <[email-masked]> writes:

    Miao> Hi, I think there are other things to consider to decide
    Miao> SHOULD or MUST an authentication::

    Miao> 1, From deployment perspective, it is not very difficult to
    Miao> enable server authentication because the population of
    Miao> servers is usually not as many as that of clients, the
    Miao> certificates are only required to be created for the server
    Miao> rather than plenty of clients: printers, routers and
    Miao> hosts. So, I think server authentication is not a major
    Miao> reason for the operator to not deploy TLS. 

Keep in mind that if you deploy server authentication you need to
configure all the clients with a trusted set of CAs.

    Miao> However, client
    Miao> authentication is highly possible the reason because the
    Miao> considerable effort for device certificate deployment.

    Miao> 2, If no authentication exists, it is possible for an
    Miao> adversary to launch a MITM attack when TLS connection
    Miao> initializes, it talks with server pretending to be client
    Miao> and client to server. In this case, no confidentiality and
    Miao> integrity is conserved.

True.

    Miao> So, I would like server authenticaiton to be a MUST rather
    Miao> than SHOULD. For client authentication, it may be SHOULD,
    Miao> even MAY.
So, you believe that observers seeing messages in transit and
modifying those messages is a more important threat for syslog than
attackers being able to inject fake messages or servers being unable to determine which device a message comes from?

Also, please remember to structure your thoughts in terms of what
options are mandatory to implement rather than what is mandatory to
deploy.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 6 Feb 2007 12:20:41 +0100

Sam,

thanks for the clarification.

>    be optional to implement, then there must be an option not to

I think it is no problem at all to mandate that implementations
implement mutual authentication capabilities. It is a good thing and it
is also trivial to do using the current libraries.

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Tue, 6 Feb 2007 11:33:12 +0100

<at the end>
Tom Petch

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: "Miao Fuyou" <[email-masked]>
Cc: "'Rainer Gerhards'" <[email-masked]>; "'David Harrington'"
<[email-masked]>; "'tom.petch'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 06, 2007 5:47 AM
Subject: Re: Relays was Re: [Syslog] AD Review
fordraft-ietf-syslog-transport-tls

> attackers being able to inject fake messages or servers being unable to
determine which device a message comes from?
> options are mandatory to implement rather than what is mandatory to

For me, it is message origin authentication that is the part of security that
matters most; confidentiality is less an issue, although I know that there are
others on this list for whom the reverse is true.  One way I see of achieving
this is to make the syslog Device the TLS server and the syslog Collector the
TLS client.  All syslog devices are given certificates but the role of checking
their validity, of identifying trusted CAs, handling certificate chains etc
falls on the syslog Collector, which I see as the more  powerful engine, with
better infrastructure, better able to perform these checks and to reject a TLS
server certificate as and when it has doubts.  After all, it is the syslog
Collector that is misled by faked messages so I see no problem with making it do
the work of authentication.

Tom Petch

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Feb 2007 10:38:23 -0500

So, I shouldn't have asked my question and tom shouldn't have replied:
the answer is in the charter.

   The threats that this WG will primarily address are modification,
   disclosure, and masquerading. A secondary threat is message stream
   modification. Threats that will not be addressed by this WG are DoS
   and
   traffic analysis. 

I knew there was a good reason I asked you guys to come up with that
text before we started:-)

So, Tom's proposal to focus on data origin authentication as the
primary attack is out of charter.

Also, the current TLS document seems to have inconsistent terminology
with the charter.  The charter seems to describe message stream
modification as an end-to-end property solved by syslog-sign, while
integrity is a hop-by-hop property.

--Sam