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
