I think that whatever we say should use consistent terminology. 'Authorization' seems out of place. I am well familiar with it from SNMP and isms, as well as from RFC2828, and think that authentication is enough here, as it is for TLS documents and syslog-protocol.
client and transport sender get used interchangeably, which I think impedes understanding. After the initial paranthetic reference to client and server in this section, I think that we should only use transport sender and transport receiver. Tom Petch ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[email protected]> Sent: Thursday, May 15, 2008 9:35 PM Subject: Re: [Syslog] Document shepherd report of AD concerns > To add to David's email, and Tom's concern that "[we] should only > change what the IESG wants us to to; and that I do not see": > > All the changes in version -12 were done in response to my (and > earlier Sam's) AD review comments. However, based on the recent > discussions, it's clear that the text isn't final yet, and needs > some improvement. > > The intent of 4.2.1/4.2.2 was to specify a minimum level needed for > interoperability, not to prevent deployments for making their own > policy decisions. That minimum level can be pretty small -- and > there's some room for discussing what exactly it should be -- but it > must provide reasonable security for many typical syslog uses (and in > this particular case, having a full-fledged PKI as the only approach > isn't really a credible solution). > > Perhaps we could rephrase the text to make this more clear, and > also explain the motivation for these requirements. Here's a first > shot at that text -- feedback is welcome. > > To prevent disclosure of syslog message contents, the transport > sender (TLS client) has to verify that it is sending the messages > to an authorized transport receiver (TLS server). > > Typically, a client application using TLS achieves this by > performing certification path validation (using previously > configured trust anchors), and comparing the certificate subject > name against the expected server name (or a list of authorized > server names). > > Syslog transport senders MUST support this approach. The minimum > requirements for certification path validation and subject name > comparison are specified later in this section. > > However, syslog is frequently used in environments where assuming > PKI deployment is not realistic. Thus, an alternative that provides > a reasonable level of security, while being simple to deploy, is > desired. This document requires that syslog transport senders MUST > support a mechanism where the authorized transport receivers are > identified by certificate fingerprints. The minimum requirements > for this mechanism are specified in Section 4.2.3. > > However, these requirements are intended to specify only a minimum > level of compliance required for interoperability. Implementations > MAY support additional mechanisms for expressing more complex > policies, validating certificates, and determining whether a > certificate represents an authorized transport receiver. > > There can be extreme situations where it is not feasible to verify > that the transport sender is communicating with an authorized > transport receiver. A syslog implementation MAY provide an option > to skip this verification (i.e., accept any server certificate). > This option MUST NOT be enabled by default. > > Best regards, > Pasi > > > -----Original Message----- > > From: David Harrington > > Sent: 15 May, 2008 21:02 > > To: [email protected] > > Subject: [Syslog] Document shepherd report of AD concerns > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
