Hi,
inline
On Tue, 8 Jun 2010, Sean Turner wrote:
t.petch wrote:
I see two separate issues here, trust anchor and mandatory encryption, and
<some elided>
Tom,
Ah see I'm not sure Tim was thinking along these line. I suspect Tim is
thinking is here's yet another protocol saying we're going to use TLS/DTLS
and they're not saying anything about the interesting things that can happen
with TLS/DTLS (e.g., negotiating NULL confidentiality algorithms). If the WG
isn't always using DTLS for confidentiality, then Section 4 needs to say
that. Maybe adding something like the following before the note:
However, confidentiality is not always required for syslog over DTLS because
[insert reason here].
..because section 8.8. (Message Observation) in RFC 5424 says:
vvvv
While there are no strict guidelines pertaining to the MSG format,
most syslog messages are generated in human-readable form with the
assumption that capable administrators should be able to read them
and understand their meaning. The syslog protocol does not have
mechanisms to provide confidentiality for the messages in transit.
In most cases, passing clear-text messages is a benefit to the
operations staff if they are sniffing the packets from the wire. The
operations staff may be able to read the messages and associate them
with other events seen from other packets crossing the wire to track
down and correct problems. Unfortunately, an attacker may also be
able to observe the human-readable contents of syslog messages. The
attacker may then use the knowledge gained from those messages to
compromise a machine or do other damage.
Operators are advised to use a secure transport mapping to avoid this
problem.
^^^^
I think you'll need to add some text that says if confidentiality is
required, the NULL cipher suites MUST NOT negotiate NULL encryption ciphers.
I'm hoping that we can keep the part about MUST NOT support NULL integrity
and authentication algorithms in Section 5.3. But, add a new last sentence
that says something like:
When confidentiality is provided by [insert mechanism here], then NULL
encryption algorithms MAY be negotiated.
Let's change that to:
When confidentiality is desired but without the overhead of using DTLS
encryption, then it may be provided by provisioning a physically
secured network. In that case the NULL encryption algorithm may be
negotiated.
Does that work?
<some more elided for brevity>
That may take care of 9 and 9A. What about 9B?
> ===============================================
> Issue 9B -
> Sean also suggests:
> #6) Section 9. Tim pointed out that because this I-D relies on
> self-signed certificates it needs to say something about certificates
> (I looked in DTLS/TLS and they don't point to 5280), keeping the
> private key private, generating good random #s, and taking care when
> installing trust anchors. Most of this is in RFC 5280 so if we add it
> to the first line of the security considerations we're good except for
> the make a good private key and installing the trust anchor.
> Suggested text below:
>
> OLD:
>
> The security considerations in [RFC5425], [RFC5246] and [RFC4347]
> apply to this document.
>
> NEW (yes I reordered them so Alfred won't complain later):
>
> The security considerations in [RFC4347], [RFC5246], [RFC5425], and
> [RFC5280] apply to this document.
>
> and we should add two new paragraphs:
>
> 9.2 Private Key Generation
>
> Transport receiver and transport sender implementations
> generate their own key pairs. An inadequate random number
> generator (RNG) or an inadequate pseudo-random number generator
> (PRNG) to generate these keys can result in little or no security.
> See [RFC4086] for random number generation guidance.
>
> 9.3 Trust Anchor Installation and Storage
>
> Trust anchor installation and storage is critical. Transmission of
> a trust anchor, especially self-signed certificates used as trust
> anchors, from transport receiver to transport sender for
> installation requires an out-of-band step(s). Care must be taken to
> ensure the installed trust anchor is in fact the correct trust
> anchor. The fingerprint mechanism in Section 5.3.1 can be
> used by the transport sender to ensure the transport receiver's
> self-signed certificate is properly installed. Trust anchor
> information must be securely stored. Changes to trust anchor
> information can cause acceptance of certificates that should
> be rejected.
>
>
> ACTION: I'm also going to ask for more discussion on this.
Thanks,
Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
