Subject: [Syslog] Syslog-tls-09 draft - suggested change

From: "David B Harrington" <[email-masked]>
Date: Mon, 23 Apr 2007 16:46:50 -0400

Hi,

The -09- revision copied text directly from rfc2818 without modifying
it to match the simplex operating environment of syslog, as compared
to the duplex operating environment of HTTP. 

I think this makes the text confusing since it is unclear what a
"user-oriented" syslog would be.

HTTP is often used in a "user-oriented" environment, such as with a
web browser, so the following makes sense:
   If the hostname does not match the identity in the certificate,
user
   oriented clients MUST either notify the user (clients MAY give the
   user the opportunity to continue with the connection in any case)
or
   terminate the connection with a bad certificate error.  Automated
   clients MUST log the error to an appropriate audit log (if
available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it.

The syslog-tls text was changed from rfc2818 because the "user
oriented" text of rfc2818 does not seem to make protocol sense for the
simplex syslog, where you cannot "notify the user", so most of the
first sentence was eliminated from the syslog draft.

   If the hostname (or IP address) does not match the identity in the
   certificate, the clients MUST terminate the connection with a bad
   certificate error.  Clients MAY log the error to an appropriate
audit
   log (if available) and SHOULD terminate the connection (with a bad
   certificate error).

The "user-oriented" and "automated client" conditionals were removed,
and the user-oriented action was changed from "MUST notify or
terminate" to simply "MUST terminate". The removal of the conditionals
makes the actions unconditional. But the unconditional "MUST
terminate" in the first sentence conflicts with the unconditional
"SHOULD terminate" in the second sentence.

I recommend the following text which is consistent with the automated
client case in rfc2818:

   If the hostname (or IP address) does not match the identity in the
   certificate, the client MUST log the error to an appropriate audit
   log (if available) and SHOULD terminate the connection (with a bad
   certificate error).

(Note that changing "MAY log the error" (syslog-tls-08) , to "MUST log
the error" (rfc2818), makes little difference since there is an "if
available" clause.)

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

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

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 24 Apr 2007 10:34:45 +0800

Hi,

TLS is still duplex even if syslog is simplex. In the same time,
authenticaiton happens in the handshaking phase of TLS when syslog message
transfering does not begin . So, simplex or duplex does not matter for
authentication. 

I had persuaded myself that syslog sender is always hosted on automated
application/appliance, such as web daemon or printer, this make it
impossible for an user to check interactively whether umatched hostname/IP
address is acceptable. However, I am suspecting the perception is wrong. It
is possible to host syslog sender on a interactive application, such as
database administration tool. One may argue that why we need to log events
when we could read event description on a popup dialog or from prompt.
Probably one of the motivations is that currently syslog are widely used to
collect events for audit, so IDS tools could check the audit trail for
further analysis. This is not only valuable for automated application but
also for interactive (or user-oriented) application.

So, my suggestion is the specification should not exclude user-oriented
apllication of syslog, just like RFC2818 does not exclude automated
application.

My 0.02 bucks.

Thanks,
Miao

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Tuesday, April 24, 2007 4:47 AM
> To: [email-masked]
> Subject: [Syslog] Syslog-tls-09 draft - suggested change
> 
> Hi,
> 
> The -09- revision copied text directly from rfc2818 without 
> modifying it to match the simplex operating environment of 
> syslog, as compared to the duplex operating environment of HTTP. 
> 
> I think this makes the text confusing since it is unclear 
> what a "user-oriented" syslog would be.
> 
> HTTP is often used in a "user-oriented" environment, such as 
> with a web browser, so the following makes sense:
>    If the hostname does not match the identity in the 
> certificate, user
>    user the opportunity to continue with the connection in 
> any case) or
> The syslog-tls text was changed from rfc2818 because the 
> "user oriented" text of rfc2818 does not seem to make 
> protocol sense for the simplex syslog, where you cannot 
> "notify the user", so most of the first sentence was 
> eliminated from the syslog draft.
> 
>    certificate error.  Clients MAY log the error to an 
> appropriate audit
> The "user-oriented" and "automated client" conditionals were 
> removed, and the user-oriented action was changed from "MUST 
> notify or terminate" to simply "MUST terminate". The removal 
> of the conditionals makes the actions unconditional. But the 
> unconditional "MUST terminate" in the first sentence 
> conflicts with the unconditional "SHOULD terminate" in the 
> second sentence.
> 
> I recommend the following text which is consistent with the 
> automated client case in rfc2818:
> 
> (Note that changing "MAY log the error" (syslog-tls-08) , to 
> "MUST log the error" (rfc2818), makes little difference since 
> there is an "if available" clause.)
> 
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Apr 2007 09:42:34 +0200

Miao,
> transfering does not begin . So, simplex or duplex does not matter for

I personally haven't liked those terms since 300 baud modems and 3270s 
went out of style  ;-)

> database administration tool.

This is not as simple a decision as may first appear.  On the one hand, 
while you can come up with examples such as the above, and they really 
do exist (another good one is when you have some sort of Windows 
Watcher(*) that you want to log back to a central source), the two 
problems with reporting to the user are (a) the cases where there is no 
user and (b) the fact that operational experience has shown that the 
user really doesn't know what to do when there is a problem.

On the other hand, we have another little problem in this specific 
case.  What do we normally say when something goes wrong in one of our 
protocols?  "Log an error."  Here that poses a little bit of a problem 
;-)  I would suggest text along the lines of the following:

    The application developer must take some care to consider the case
    when, for whatever reason, there is a problem with authenticating
    the other end of the connection.  In the case of a receiving relay
    or a receiver, the connection SHOULD be closed and an error logged,
    indicating the problem.  In the case of a syslog sender or a
    transmitting relay, the situation requires more care.  Here the
    application SHOULD also close the connection and also use whatever
    other means are available to it to inform the administrator of the
    problem.  This may include producing a message on a console,
    returning an error to the user, or writing a file to disk, if possible.

There is also a matter of what an application is supposed to do when 
logging fails.  Some applications should proceed uninterrupted.  Others 
may need to block.  I don't know whether text is appropriate.  It's not 
part of the protocol, but it does fall under common modes of failure.  
The reason this would be an issue with TLS (or BEEP for that matter) and 
not with UDP is that one doesn't block with UDP.

In addition, you have another problem in the text:

>    If the client is configured with IP address
>    of the server, the hostname should be got first through a trusted
>    mechanism such as a preconfigured hosts table or DNSSEC [8].

It is often the case that a reverse map does not match a forward map.  
For example, often times a service provider might allocate IP address 
space and route that space to a customer but not delegate the reverse 
mapping.  This is particularly true in consumer environments.   I would 
suggest that if the client is configured with an IP address, that it is 
what should be present in the certificate, as the name has no meaning at 
all to the client.

Eliot

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 24 Apr 2007 07:29:01 -0700 (PDT)

Hi,

On Tue, 24 Apr 2007, Eliot Lear wrote:

> I personally haven't liked those terms since 300 baud modems and 3270s went 
> out of style  ;-)
>
> This is not as simple a decision as may first appear.  On the one hand, while 
> you can come up with examples such as the above, and they really do exist 
> (another good one is when you have some sort of Windows Watcher(*) that you 
> want to log back to a central source), the two problems with reporting to the 
> user are (a) the cases where there is no user and (b) the fact that 
> operational experience has shown that the user really doesn't know what to do 
> when there is a problem.
>
> On the other hand, we have another little problem in this specific case. 
> What do we normally say when something goes wrong in one of our protocols? 
> "Log an error."  Here that poses a little bit of a problem ;-)  I would 
> suggest text along the lines of the following:
>
> There is also a matter of what an application is supposed to do when logging 
> fails.  Some applications should proceed uninterrupted.  Others may need to 
> block.  I don't know whether text is appropriate.  It's not part of the 
> protocol, but it does fall under common modes of failure.  The reason this 
> would be an issue with TLS (or BEEP for that matter) and not with UDP is that 
> one doesn't block with UDP.

I think Eliot is on the right track.  However, I wouldn't differentiate
between the actions that a sender or receiver is to take when
authentication fails - both cases should have a recommendation that the
device log the failure _and_ attempt to inform the administrator of the
problem.  This might be pop-ups to the unsuspecting user who won't know
what to do about it, it might be messages printed on the console, it might
be a blinky light on the printer, etc.  (Most networked printers that I'm
seeing these days have nice displays that are starting to give informative
messages.)

Perhaps this text:
    The application developer must take some care to consider the case
    when, for whatever reason, there is a problem with authenticating
    the other end of the connection.  The connection SHOULD be closed and
    an error logged indicating the problem.  Since this problem will
    prevent log messages from being transmitted, each device having this
    problem should use whatever means are available to inform the
    administrator of the problem. This may include producing a message on a
    console, returning an error to a user (if there is one), or writing a
    file to disk, if possible.

> It is often the case that a reverse map does not match a forward map.  For 
> example, often times a service provider might allocate IP address space and 
> route that space to a customer but not delegate the reverse mapping.  This is 
> particularly true in consumer environments.   I would suggest that if the 
> client is configured with an IP address, that it is what should be present in 
> the certificate, as the name has no meaning at all to the client.

I think that's an operational issue that we're not going to deal with. 
We're talking about a domain of administration here.  We're not going to 
be able to write enough text into this document to cover the case where 
the administrators cannot line up dNSName with an IP address within their 
own purview.

Thanks,
Chris

---

From: David Harrington <[email-masked]>
Date: Tue, 24 Apr 2007 11:41:50 -0400

Hi,

I am a bit concerned that most people will look at syslog as being an
automated client and not a user-oriented client, and the paragraph
from rfc2818 can be confusing if one does not consider the few
exceptions.

I recognized that my suggested text did exclude consideration of the
few user-oriented cases, so I do not have a problem with my text being
rejected on that point. But leaving the text from rfc2818 as is still
has the same problem.

I would be much more accepting of the text from rfc2818 if the
"automated client" was discussed before the user-oriented client
discussion:

automated

   User oriented clients MUST either notify the user (clients MAY give
the
   user the opportunity to continue with the connection in any case)
or
   terminate the connection with a bad certificate error.

    The application developer must take some care to consider the case
    when, for whatever reason, there is a problem with authenticating
    the other end of the connection.  The connection SHOULD be closed
and
    an error logged indicating the problem.  Since this problem will
    prevent log messages from being transmitted, each device having
this
    problem should use whatever means are available to inform the
    administrator of the problem. This may include producing a message
on a
    console, returning an error to a user (if there is one), or
writing a
    file to disk, if possible.

Does the third paragraph eliminate the need for the first two
paragraphs?

dbh

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Tuesday, April 24, 2007 3:43 AM
> To: Miao Fuyou
> Cc: 'David Harrington'; [email-masked]
> Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change
> 
> Miao,

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Apr 2007 19:20:23 +0200

Hi Dave,

> Does the third paragraph eliminate the need for the first two

I think they need to be merged.  Key parts are these:

    * SHOULD close the connection on failed authentication, and attempt
      to log an error
    * A discussion of the challenges of logging in such an environment.

I think that boils down to this:

vv

If the hostname does not match the identity in the certificate,
clients SHOULD log the error in some form or another (see below),
and SHOULD terminate the connection (with a bad certificate error).
Clients MAY provide a configuration setting that disables this check
but MUST enable it by default.

The application developer must take some care to consider the case
when, for whatever reason, there is a problem with authenticating
the other end of the connection.  Since this problem will
prevent log messages from being transmitted, each device having this
program should use whatever means are available to inform the
administrator of the problem. This may include producing an error code
on a console, returning an error to a user (if there is one), or
writing a file to disk, being mindful that such writes should be
rate limited in the case of attacks.

^^

So the above eliminates the distinction, and allows the necessary 
versatility that applications writers will need, given circumstances.   
I could envision a printer flashing the occasional "E184" or some such.  
Please also note that I changed the setting text, the reason for that 
being that if there is a configuration knob to disable a check it only 
follows that there will be something enabled already ;-)  You might 
disagree.

Eliot

David Harrington wrote:
>>> authenticaiton happens in the handshaking phase of TLS when 
>>>       
>> syslog message
>>     
>>> transfering does not begin . So, simplex or duplex does not 
>>>       
>> matter for
>>     
>>> authentication.
>>>       
>>> I had persuaded myself that syslog sender is always hosted 
>>>       
>> on automated
>>     
>>> impossible for an user to check interactively whether 
>>>       
>> umatched hostname/IP
>>     
>>> address is acceptable. However, I am suspecting the 
>>>       
>> perception is wrong. It
>>     
>>> is possible to host syslog sender on a interactive 
>>>       
>> application, such as
>>     
>>     The application developer must take some care to consider the
>>     
> case
>   
>>     when, for whatever reason, there is a problem with
>>     
> authenticating
>   
>>     the other end of the connection.  In the case of a receiving
>>     
> relay
>   
>>     application SHOULD also close the connection and also use
>>     
> whatever
>   
>>     other means are available to it to inform the administrator of
>>     
> the
>   
>>>    of the server, the hostname should be got first through a
>>>       
> trusted
>   
>> For example, often times a service provider might allocate IP
>>     
> address 
>   
>> space and route that space to a customer but not delegate the
>>     
> reverse 
>

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 24 Apr 2007 19:14:42 -0700 (PDT)

Hi,

I'm OK with this proposal with two minor changes.
- rather than "(see below)" it should have "(see next paragraph)"
- remove parenthasis from "(with a bad certificate error)" as that text is 
normative.

Thanks,
Chris

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 25 Apr 2007 09:34:13 +0200

> what should be present in the certificate, as the name has no meaning at 

And the IP address can also be added to the X.509 certificate in the
subjectAltName extension.

-- 
Bazsi

---

From: Carson Gaspar <[email-masked]>
Date: Wed, 25 Apr 2007 03:47:11 -0400

[ re: DNS reverse mapping ]

DNS is not secure, and isn't likely to be any time soon. Using DNS as any 
sort of security measure is just plain stupid.

Either the other party possesses the private key material that matches 
their public key or they don't. If they don't, SSL will fail. If they do, 
then they're exactly who they say they are (or the private key material has 
leaked, at which point it's game over anyway). DNS should have nothing 
whatsoever to do with it. Any modern RFC that makes references to doing 
reverse lookups in a security context should be laughed out of the IETF.

-- 
Carson

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 25 Apr 2007 16:30:49 +0800

I think the working group had discussed the issue and actually the draft is
written with:
"trusted mechanism such as a preconfigured hosts table or DNSSEC" 

Regards,
Miao

> From: Carson Gaspar [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 3:47 PM
> To: [email-masked]
> DNS is not secure, and isn't likely to be any time soon. 
> Using DNS as any sort of security measure is just plain stupid.
> 
> Either the other party possesses the private key material 
> that matches their public key or they don't. If they don't, 
> SSL will fail. If they do, then they're exactly who they say 
> they are (or the private key material has leaked, at which 
> point it's game over anyway). DNS should have nothing 
> whatsoever to do with it. Any modern RFC that makes 
> references to doing reverse lookups in a security context 
> should be laughed out of the IETF.
> 
> --
> Carson
>

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 25 Apr 2007 16:32:25 +0800

> > logging fails.  Some applications should proceed uninterrupted.  
> > Others may need to block.  I don't know whether text is 
> appropriate.  
> > It's not part of the protocol, but it does fall under 
> common modes of 
> > failure.  The reason this would be an issue with TLS (or 
> BEEP for that 
> > matter) and not with UDP is that one doesn't block with UDP.
> 
> I think Eliot is on the right track.  However, I wouldn't 
> differentiate between the actions that a sender or receiver 
> is to take when authentication fails - both cases should have 
> a recommendation that the device log the failure _and_ 
> attempt to inform the administrator of the problem.  This 
> might be pop-ups to the unsuspecting user who won't know what 
> to do about it, it might be messages printed on the console, 
> it might be a blinky light on the printer, etc.  (Most 
> networked printers that I'm seeing these days have nice 
> displays that are starting to give informative
> messages.)

My perception is logging does not necesarily mean send events over network
to syslog server,. Webopedia says log is "to record an action". If there is
no syslog connection available, it is still possible to log the message in
local storage. 

I just checked the printer in my office, it does log events locally. It is
reckoned the buffer for log is very small because there are only 50 records,
acutally the printer fails from time to time:-(

Thanks,
Miao

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Apr 2007 11:39:52 +0200

> no syslog connection available, it is still possible to log the message in
Right.  The issue here, however, is that you've configured an 
application or a system to use the network and that has failed.  What 
you do next requires a bit of care.  That's all I'm saying.

Eliot