[Syslog] Terminology was Re: Document shepherd report of AD concerns

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: <Pasi.Eronen@nokia.com>
To: <ietfdbh@comcast.net>; <syslog@ietf.org>
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: syslog@ietf.org
> > Subject: [Syslog] Document shepherd report of AD concerns
>

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