Re: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT

[Chris Lonvick <[e-mail]>]

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