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

[Eliot Lear]

Hi Dave,

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

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:
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:

   If the hostname does not match the identity in the certificate,
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. 

   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

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

Miao,
    
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 personally haven't liked those terms since 300 baud modems 
and 3270s 
went out of style  ;-)

    
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.
      
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

    

  

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog