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

From: Chris Lonvick <[email-masked]>
Date: Mon, 7 Jun 2010 08:20:09 -0700 (PDT)

Issue 9 - Tim Polk COMMENT

Comment:
Given that disclosure is one of the primary threats described in Section 
4, shouldn't the security considerations prohibit the use of cipher suites 
with NULL encryption?

Prpposed resolution by Sean:
vvv
A.5 of RFC 5246, which is where the cipher suites for both TLS and
DTLS end up pointing and is included in this I-Ds security
considerations, includes the following:

   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
   TLS connection during the first handshake on that channel, but MUST
   NOT be negotiated, as it provides no more protection than an
   unsecured connection.

I could see how this might be worth repeating, but waned to make you
aware it was in RFC 5246.
^^^

Tim responded:
vvv
Thanks for pointing out that text; that is helpful but not sufficient,
though.   I am actually worried about cipher suites that have 
authenticatio=
n
& integrity but NULL encryption as well.  There are a bunch of those:

       CipherSuite TLS_RSA_WITH_NULL_MD5                 =3D { 0x00,0x01 };
       CipherSuite TLS_RSA_WITH_NULL_SHA                 =3D { 0x00,0x02 };
       CipherSuite TLS_RSA_WITH_NULL_SHA256              =3D { 0x00,0x3B };
0x00,0x2C    TLS_PSK_WITH_NULL_SHA    [RFC4785]
0x00,0x2D    TLS_DHE_PSK_WITH_NULL_SHA    [RFC4785]
0x00,0x2E    TLS_RSA_PSK_WITH_NULL_SHA
0xC0,0x06    TLS_ECDHE_ECDSA_WITH_NULL_SHA    [RFC4492]

...among others.

(Pardon the formatting, pulled some from 5246 and others from the iana
registry...)
^^^

Sean responsed:
vvv
Ah! I see your point now.  How about we tweak the last paragraph in
section 5.3 (obviously I'd like author input on this):

OLD:

    Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the
    mandatory to implement cipher suite, which is
    TLS_RSA_WITH_AES_128_CBC_SHA.

NEW:

    Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a
    minimum support the mandatory to implement cipher suite, which is
    TLS_RSA_WITH_AES_128_CBC_SHA.  If additional cipher suites are
    supported, then implementations MUST NOT negotiate a cipher suite
    that employs NULL encryption, integrity, or authentication
    algorithms.
^^^

Sean's proposed resolution:
vvv
#3) Tim's point about restricting NULL cipher suites.  At the end of
section 5.3:

OLD:

    Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the
    mandatory to implement cipher suite, which is
    TLS_RSA_WITH_AES_128_CBC_SHA.

NEW:

    Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a
    minimum support the mandatory to implement cipher suite, which is
    TLS_RSA_WITH_AES_128_CBC_SHA.  If additional cipher suites are
    supported, then implementations MUST NOT negotiate a cipher suite
    that employs NULL encryption, integrity, or authentication
    algorithms.
^^^

Tom Petch responded:
vvv
I disagree.  The threat of disclosure comes from RFC5425 s2
"Some data in syslog messages is sensitive and may be
       useful to an attacker, such as the password of an authorized
       administrator or user."
but the fact that someone, somewhere may put a password in a syslog
message I do not see as grounds for requiring everyone else in the world
to encrypt everything.  Encryption is a pain, it costs, and we should not
require it
unless it can be justified; these are remote, low-powered network boxes
we are talking about, not enterprise servers.

So while I agree we should require authentication, I see no
justification for encryption.
^^^

Action:  I'd like to get some additional discussion going on this.

==============================================
issue 9A -

Sean also suggested this:
vvv
#3) Tim's point about restricting NULL cipher suites.  At the end of
section 5.3:

OLD:

    Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the
    mandatory to implement cipher suite, which is
    TLS_RSA_WITH_AES_128_CBC_SHA.

NEW:

    Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a
    minimum support the mandatory to implement cipher suite, which is
    TLS_RSA_WITH_AES_128_CBC_SHA.  If additional cipher suites are
    supported, then implementations MUST NOT negotiate a cipher suite
    that employs NULL encryption, integrity, or authentication
    algorithms.
^^^

ACTION:  Waiting on discussion for Issue 9.

===============================================
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.

---

From: "t.petch" <[email-masked]>
Date: Tue, 8 Jun 2010 10:22:57 +0200

I see two separate issues here, trust anchor and mandatory encryption, and it is
the latter I am absolutely against.  Just because someone, somewhere in the
world may send confidential data in a syslog message does not mean the IETF must
REQUIRE everyone, everywhere in the world to encrypt everything.  It's ......

The IESG had a go at SNMP over this but SNMP got its oar in decades ago by
specifying that authnopriv(acy) was a part of SNMP, and so it has remained, as
the mechanics of security have evolved.

If that is ok for SNMP, with all the important data it carries, I think it
suitable for syslog ie NULL encryption is fine and we would be doing our users
an injustice to deny them the option.

The argument based on our mention of disclosure as a threat in RFC5425 I find
spurious; it means that encryption must be an option, not that everyone must use
it all the time.

<mutter, mutter, mutter/>

Tom Petch

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 07, 2010 5:20 PM
Subject: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT

> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Jun 2010 16:44:40 -0400

> <mutter, mutter, mutter/>

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].

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.

spt

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 8 Jun 2010 19:25:59 -0700 (PDT)

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.
^^^^

> 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:
>

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?

Thanks,
Chris

---

From: [email-masked]
Date: Wed, 9 Jun 2010 08:10:25 -0400

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 
lastsentence 

>     secured network.  In that case the NULL encryption algorithm may be

Those words could work.  It would be better if the phrase "physically 
secured network" were "appropriately secured network".  I'm thinking about 
people who are using VLAN and other low level hardware technologies. 
Someone who understands the issues can decide whether their low level 
hardware approach is a suitable equivalent to "physically secured" so this 
is less imprtant.   Either wording results in implementations that can be 
configured to meet the need.

Kind Regards,

Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 
07660-2199, United States
http://www.agfa.com/healthcare/
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer

---

From: "t.petch" <[email-masked]>
Date: Tue, 15 Jun 2010 12:18:40 +0200

I agree with Robert that privacy can be achieved by means other than encryption,
but disagree that privacy is a MUST operationally.

As Chris pointed out, we have already said this in RFC5424
"In most cases, passing clear-text messages is a benefit to the
    operations staff if they are sniffing the packets from the wire.  "
which means I think we should say

"Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a
     minimum support the mandatory to implement cipher suite ,
    which is
     TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246].  If additional cipher suites are
     supported, then implementations MUST NOT negotiate a cipher suite
     that employs NULL integrity or authentication  algorithms.

   Where privacy is REQUIRED, then implementations must either negotiate
  a cipher suite that employs a non-NULL encryption algorithm or else achieve
  privacy  by other means, such as a physically secured network.

However, as [RFC5424] section 8 points out
'In most cases, passing clear-text messages is a benefit to the
    operations staff if they are sniffing the packets from the wire.'
and so where privacy is not a requirement, then it is advantageous
to use a NULL encryption algorithm.

Tom Petch