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 PROTECTED] 
> Sent: Tuesday, April 24, 2007 4:47 AM
> To: [EMAIL PROTECTED]
> 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
>    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 PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> 
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 



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

Reply via email to