Subject: [Syslog] Subject Name verification policy

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 4 Jun 2008 23:19:09 -0700

>From the discussion on the list it seems that the largest issue is with
section 5.1 

It seems that there is rough consensus to demote IP address matching in
certificates to a SHOULD or MAY.  My preference would be to demote it
down to a may and just include it as an example of other things that
could be done, such as matching against the distinguished name as Martin
suggested. 

"Implementations MAY also support authorization based on matching
configured names to other identity attributes.  For example, the
authorization of a device Serial Number against the SerialNumber portion
of the Subject Distinguished Name, IP address against a SubjectAltName
of type ipAddress, or an identity against a subject distinguished name.
Implementations MAY support other checks such as restrictions on the
depth of a certificate chain.  "

As far as hostname matching Tom brought up RFC4642 which has a slightly
different set of rules for matching host names (in particular it is more
restrictive with wildcards).  Text that is more in line with what 4642
has might look like the following:

"	o Host-name-based authorization where the host name of the
authorized peer is compared against the subject fields in the
certificate.  For the purpose of interoperability, implementations MUST
support matching the host name against a SubjectAltName field with a
type of dNSName and SHOULD support checking hostname against the Common
Name portion of the Subject Distinguished Name.  If more than one host
name identity is present in the certificate a match in any one of the
set is considered acceptable.  Matching is case-insensitive.
Implementations also MAY support wildcards to match a range of values.
A "*" wildcard character MAY be used as the left-most name component in
the certificate.  For example, *.example.com would match a.example.com,
foo.example.com, etc., but would not match example.com.  Using a
wildcard for the entire host name makes it possible to deploy
trust-root-based authorization where all credentials issued by a
particular CA trust root are authorized." 

We should also include a discussion on using configured names instead of
names derived from DNS for matching.  

I'll work on clarifying some of the other sections and try to have
another revision by the end of the week.

Cheers,

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 5 Jun 2008 08:26:28 +0200

Hi Joe,

excellent suggestions. I concur to both. 

It may also be useful (but not vital) to include a note that
transport-tls is a secure, but not a 100% reliable protocol (because tcp
without an app-layer ack is unreliable). Lots of folks have the
misconception that just because tcp is used it is reliable. For that,
one needs to implement rfc 3195. But, again, this is not a important
enough point to hold publishing.

Rainer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Thursday, June 05, 2008 8:19 AM
> To: syslog
> Subject: [Syslog] Subject Name verification policy
>

---

From: [email-masked]
Date: Thu, 5 Jun 2008 06:45:47 -0400

I agree with Rainer that those fixes would make it good enough.

[Rainer]
> enough point to hold publishing.

I worry that getting into the reliability discussion will delay things. 
The reliability discussion is more a tutorial about the limitations of TCP 
and is not syslog specific.  It comes up because syslog users react very 
negatively to the work "unreliable" in UDP and become concerned.

If a reliability note is included, it would help to indicate that TCP 
provides protection against some forms of data loss, such as network 
congestion and data corruption related message loss but not against all 
forms of loss.  The most common form of data loss with TCP involves mobile 
equipment.  If I disconnect a machine from the network without warning, 
move it, and relocate it to somewhere that assigns it a new IP address, 
all the active TCP/IPv4 connections are lost.  A syslog-tls that was using 
one of these connections may, depending on details of timing and 
implementation, suffer undetected data loss.  TCP/IPv6 can be configured 
to reduce or even eliminate this source of data loss, but other lower 
probability sources of loss remain.

All of this discussion would really be advanced education on the error 
recovery capabilities of TCP and is not syslog specific in any way.

R Horn

---

From: "Moehrke, John (GE Healthcare)" <[email-masked]>
Date: Thu, 5 Jun 2008 07:37:47 -0400

I too support making these last final clarifications and move this
specification along. 

John

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Rainer Gerhards
> Sent: Thursday, June 05, 2008 1:26 AM
> To: Joseph Salowey (jsalowey)
> Cc: syslog
> Subject: Re: [Syslog] Subject Name verification policy
> 
> Hi Joe,
> 
> > We should also include a discussion on using configured names
instead
> > of

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 5 Jun 2008 14:01:37 +0200

Hi Robert,

I think I should have been more clear. I meant a note along these lines
(and only these lines, without any more specifics).

###
It should be noted that this transport does not use application-level
acknowledgments. As such, there exists situations where loss of data
may occur. This protocol is not suitable if a 100% reliable solution
is desired.
###

... nothing more. I often need to talk to people (sales but
unfortunately technical folks, too) that claim that their implementation
is reliable just because it is based on TCP. While for some one can
assume they know better, at least some do not even know there actually
is a problem. I'd like to make the later aware of the fact. And for the
first sort of folks, it would be very handy to have a good reference
that they are wrong ;)

Rainer

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 05, 2008 12:46 PM
> To: Rainer Gerhards
> Cc: Joseph Salowey (jsalowey); syslog; [email-masked]

---

From: [email-masked]
Date: Thu, 5 Jun 2008 09:23:20 -0400

"Rainer Gerhards" <[email-masked]> wrote on 06/05/2008 08:01:37 

> may occur. This protocol is not suitable if a 100% reliable solution

How about just
###
may occur.
###

Maybe someone will find or write a good reference article explaining the 
application level issues with TCP/IPv4, TCP/IPv6, etc.  Then an in depth 
explanation could be given once for all the many applications that care. 
People who are serious about this will need the full details.  The rest 
deserve just the short warning.  I don't want them blindly telling 
everyone that the syslog group has officially said that they shouldn't use 
syslog-tls because it isn't reliable.  That is what would happen if we 
include that final sentence.

There are unsophisticated users who routinely demand 100% reliability.  I 
deal with them by asking about how they plan to handle power failures, 
hurricanes, earthquakes, floods, tornados, etc.  I know that when I cared 
about such stuff I could quote the local power grid reliability statistics 
off the top of my head, and could explain our decision tree on the size of 
the fuel tank for the auxiliary diesel generator.  I was also on top of 
disk drive reliability figures.  This was before RAIDs and hot swap was 
very expensive.  It turned out that downtime for disk drive problems was a 
major issue as you went below 10min/year of downtime.  Their response to 
the basic disaster questions establishes what kind of response to give for 
applications level data loss.

R Horn

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 5 Jun 2008 15:48:51 +0200

Robert,

I am fine with your text.

<slightlyOffTopic>
The reliability issue is not rooted in disasters or other uncommon
scenarios. As of my testing, confirmed this month by Martin, the
probability of message loss even in a simple server restart case is very
high. For a busy network, I'd say it tends toward 100%, though I cannot
provide hard evidence - I didn't bother to do a statistically large
enough sample to back that statement. After all, it is irrelevant if
there is a 80% or 100% probability - the point is that it is very high
(probability of message loss increases with traffic volume).

In any case, I expect that an operator of an enterprise logging system
will routinely see message loss (if he cares to detect it) inside a
system using -transport-tls. Of course -transport-udp will be much
worse. But the point is that an auditor may very well question the
completeness of the log data under *normal* circumstances. Martin has
found a trick to get some better reliability for these normal
circumstances, but the trick only works in a fast, lossless network with
low traffic volume and without bursts. Plus, it is racy. But it is the
best you can do.
</slightlyOffTopic>

All of this off-topic should NOT go into the document, but it is the
reasoning behind my proposal.

Rainer

> Sent: Thursday, June 05, 2008 3:23 PM
> To: Rainer Gerhards
> Subject: RE: [Syslog] Subject Name verification policy
> 
> off the top of my head, and could explain our decision tree on the
size

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 5 Jun 2008 16:36:42 +0200

I need to correct myself slightly... (below)

> Behalf Of Rainer Gerhards
> Sent: Thursday, June 05, 2008 3:49 PM
> To: [email-masked]
> Cc: syslog

This was the number for (non-standard) plain TCP syslog (still widely
deployed). With -transport-tls, it looks a bit better, because we have
the TLS closure process. But there are still issues. Just to clarify.

> > everyone that the syslog group has officially said that they
> shouldn't
> > use
> > There are unsophisticated users who routinely demand 100%
> reliability.
> > I
> > major issue as you went below 10min/year of downtime.  Their
response
> > to
> > the basic disaster questions establishes what kind of response to
> give
> > for

---

From: [email-masked]
Date: Thu, 5 Jun 2008 11:17:53 -0400

I just brought up disaster because I use it as a good way to separate 
users who do understand the issues from those who do not.  I hadn't 
thought of the auditor case.  It is possible for a naive user to be asked 
about this by an auditor.

Kind Regards,

Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 
07660-2199, United States
http://www.agfa.com/healthcare/
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 5 Jun 2008 17:24:41 +0200

Not for the draft, again: it gets even more problematic if logs are used
as evidence in court. Without going into all the details (what I am not
qualified at all), the reliability of the logging system (as well as the
authenticity) can and will probably be questioned in court. If now a
single line can alter the meaning of the evidence, a transport that can
experience loss of message during regular operations may be totally
unsuitable for use inside a legal-compliant logging system (different
parts of the world have obviously different legislation). So I find it
most useful to hint users about potential problems that arise out of the
transport - especially if there is a common misconception.

Rainer

> Sent: Thursday, June 05, 2008 5:18 PM
> To: Rainer Gerhards
> Cc: Joseph Salowey (jsalowey); syslog

---

From: "tom.petch" <[email-masked]>
Date: Fri, 6 Jun 2008 18:35:57 +0200

I concur with the sentiments expressed in this thread.

I would prefer not to talk of transport using application, since it subverts my
idea of the stack.  Rather I would say that the syslog application does not have
application level acknowledgements and that the use of TLS and TCP as a
transport does not change this.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Jun 2008 16:38:50 -0400

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, June 05, 2008 6:46 AM
> To: [email-masked]
> Cc: syslog; [email-masked]
[...]
> recovery capabilities of TCP and is not syslog specific in any way.

I disagree. I think Rainer pointed out that the lack of an application
ACK limits reliability, and the lack of a syslog ACK is definitely
syslog specific. A small note to this effect in the security
considerations should be adequate.

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

---

From: Martin Schütte <[email-masked]>
Date: Thu, 05 Jun 2008 13:00:06 +0200

Joseph Salowey (jsalowey) schrieb:
> Name portion of the Subject Distinguished Name.

So that means one has to do DNS lookup for name matching?

What happened to the requirement from draft 12:
> For subject name verification, client implementations MUST support
>    configuring, for each transport receiver, the name to be matched
>    against the certificate.

IMHO that is a useful requirement because it allows the user to 
configure the hostname by IP and still match against a dNSName in the 
certificate.
This easily allows DNS-independent syslog configurations without having 
iPAddresses in the certificates and having to match against them.

> the certificate.

So this only applies to wildcards in the certificate?

If a configured name is used for matching, should that be allowed to 
contain wildcards as well? (I hope not because that would make the whole 
name matching useless.)

> names derived from DNS for matching.  

See above.
My current implementation uses only the hostname and an optional 
configured subject name for matching. That way I avoid DNS for 
certificate matching and I consider that a feature.

-- 
Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 6 Jun 2008 17:47:32 -0700

Hi Martin

Thanks for looking at this. 

> [mailto:[email-masked]] On Behalf Of Martin Schütte
> Sent: Thursday, June 05, 2008 4:00 AM
> To: syslog
> > certificate.  For the purpose of interoperability, implementations 
> > MUST support matching the host name against a SubjectAltName field 
> > with a type of dNSName and SHOULD support checking hostname against 
> > the Common Name portion of the Subject Distinguished Name.
> 
[Joe] Correct DNS lookups should not be done when matching.  

> IMHO that is a useful requirement because it allows the user 
> to configure the hostname by IP and still match against a 
> dNSName in the certificate.
> This easily allows DNS-independent syslog configurations 
> without having iPAddresses in the certificates and having to 
> match against them.
> 
[Joe] I think I see your point, how about modifying the text such that host name is replaced by "configured name" as below: 

"o Host-name-based authorization where a configured name of the authorized peer is compared against the subject fields in the certificate.  For the purpose of interoperability, implementations MUST support matching the name against a SubjectAltName field with a type of dNSName and SHOULD support checking the name against the Common Name portion of the Subject Distinguished Name.  If more than one identity is present in the certificate a match in any one of the set is considered acceptable.  Matching is case-insensitive."

Does this help?

> > A "*" wildcard character MAY be used as the left-most name 
> component 
> > in the certificate.
> 
[Joe] I actually meant to remove the reference to wildcards in the certificate.  

> If a configured name is used for matching, should that be 
> allowed to contain wildcards as well? (I hope not because 
> that would make the whole name matching useless.)
> 
[Joe] New text

"Implementations also MAY support wildcards to match a range of values.  For example, a "*" wildcard character MAY be used as the left-most name component.  In this case *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.  Using a wildcard for the entire host name makes it possible to deploy trust-root-based authorization where all credentials issued by a particular CA trust root are authorized."

> > We should also include a discussion on using configured 
> names instead 
> > of names derived from DNS for matching.
> 
> See above.
> My current implementation uses only the hostname and an 
> optional configured subject name for matching. That way I 
> avoid DNS for certificate matching and I consider that a feature.
> 
[Joe] Good. I agree.

---

From: <[email-masked]>
Date: Mon, 9 Jun 2008 12:23:57 +0300

David Harrington wrote:
> [...]
> > All of this discussion would really be advanced education on 
> > the error recovery capabilities of TCP and is not syslog specific 
> > in any way.
> 

I agree that a short note would be good. Here's my proposal,
slightly expanding Rainer's text:

  It should be noted that the syslog transport specified in this
  document does not use application-layer acknowledgments.  TCP uses
  retransmissions to provide protection against some forms of data
  loss. However, if the TCP connection (or TLS session) is broken for
  some reason (or closed by the transport receiver), the syslog
  transport sender cannot always know what messages were successfully
  delivered to the syslog application at the other end.

Best regards,
Pasi

---

From: Martin Schütte <[email-masked]>
Date: Mon, 09 Jun 2008 12:36:12 +0200

Joseph Salowey (jsalowey) schrieb:
>>> For subject name verification, client implementations MUST
>>> support configuring, for each transport receiver, the name to be
>>> matched against the certificate.
> [Joe] I think I see your point, how about modifying the text such
> that host name is replaced by "configured name" as below:
> 
> Does this help?

"configured name" clarifies that no DNS is necessary.
But for me it still sounds a bit optional, I am not sure every
implementor will read it as a requirement to introduce a 'subject name'
field into its syslog.conf.
The original above was more explicit.

> [Joe] I actually meant to remove the reference to wildcards in the

Ok.

>> If a configured name is used for matching, should that be allowed
>> to contain wildcards as well? (I hope not because that would make
>> the whole name matching useless.)
> [Joe] New text
> 
> "Implementations also MAY support wildcards

I suggest to insert here:
... in configured hostnames ...

> to match a range of
> values.  For example, a "*" wildcard character MAY be used as the

-- 
Martin

---

From: "David Harrington" <[email-masked]>
Date: Tue, 10 Jun 2008 17:20:18 +0800

+1

dbh 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, June 09, 2008 5:24 PM
> To: [email-masked]; [email-masked]
> Subject: Note on reliability (was: RE: Subject Name 
> verification policy)
> 
> David Harrington wrote:
> > [...]