<snip>
> >
> > ===
> > The server MUST be implemented to support certificate and certificate
> > generation,
> > ===
> >
> > I do not think it is a MUST that a server must contain code
> > to generate certificates. This should be left to the
> > implementation. There is already the requirement to use
> > certificates, so IMHO it is not the business of an IETF
> > document to specify how they are provided. For example, I
> > would provide a helper app with my syslog implementations,
> > but not include it in the core app - it doesn't belong there.
> >
>
> Need more opinion from the working group.
>
I agree with Rainer
And I see some idiosynchratic wordings that MIGHT be changed.
2. Security Requirements for Syslog
syslog messages may pass several hops
** not really pass, suggest transit
It is recommended to use dNSName in the certificate rather than any
other type subjectAltName for certificate verification, such as
ipAddress.
**suggest iPAddress (ie PKI not SNMP)
4.2.2. Client Identity
If a server authenticates a client and the client presents a
certificate to the server, the server MUST validate the certificate.
Validation includes constructing a certificate path to one of the
configured trust anchors and validating that path. However, identity
check is not required even if subjectAltName is presented in the
certificate.
**I do not understand how failing to check the identity provides protection
against Masquerade, as we claim in s.2
SubjectAltName is not necessarily unique for different
certificates.
** suggest The subjectAltName
5.1. Authentication and Certificates
Mutual authentication means the TLS client and server are
provisioned with necessary trust roots
**suggest trust anchors as in the next paragraph
. If a server does not
have a certificate and key/pair configured
**unclear what the solidus is doing - '/' usually means either/or
The server MUST be implemented to support certificate and certificate
generation, and certificate validation MUST be implemented for all
clients. The Syslog client SHOULD be implementated to support
**implemented
certificate and certificate generation, and certificate validation
SHOULD be inplemented for Syslog server.
**These both read oddly to me - what is the support for certificate
(certificates?) as distinct from support for certificate generation and
certificate validation? If I support certificate (without qualification), then
I expect that to convey support for every aspect thereof so the validation and
generation is redundant but, as I agreed with Rainer above, I think that
generation should not be a MUST.
Since a receiver may act upon received data, for syslog over
TLS, it is recommended that the server authenticate the client to
ensure that information received is authentic.
**this seems to weaken the claim earlier that TLS defends against the listed
threats - by now I am feeling confused about what protection is being offered
by what. To meet the claims of s.2, I think we need both server and client to
check certificates for suitable identities and to follow a chain to a trust
anchor - I have no problem with describing other scenarios but think that each
such scenario should then be qualified with a comment to the effect that this
MAY not defend against threats ... as identified in s.2
5.2. Cipher Suites
Operators MAY choose to disable older/weaker cipher suites for TLS
despite the tradeoff of interoperability, for example, if the cipher
suite specified in the specification is found weak in the future.
**suggest
Operators MAY choose to disable cipher suites for TLS that are regarded as
too weak for the environment in which this specification is being used,
especially older cipher suites. This MAY lead to a reduction of
interoperability. It is likely that, in time, the cipher suite specified here
will become subject to attack and the use of it will too be deprecated.
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
