Subject: RE: [Isms] Reminder: ISMS proposals due October 18th

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 15 Oct 2004 10:17:54 -0700

Hi,

One more assumption:

(4) SNMP over DTLS requires a separate well-known
    port (like the much-maligned HTTPS), because
    the client (SNMP Manager) must know that the
    DTLS handshake always comes first (the use
    of an Upgrade header like RFC 2817 in the
    application traffic doesn't make any sense).

Cheers,
- Ira

PS - Ken just made a very good point about the lack
of hooks in SASL and TLS (OpenSSL) APIs for passing
the cryptographic hash back and forth - that should
convince people to force mutual authentication in
the DTLS layer.

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of McDonald, Ira
Sent: Friday, October 15, 2004 12:33 PM
To: 'Ken Hornstein'; [email-masked]
Subject: RE: [Isms] Reminder: ISMS proposals due October 18th 

Hi,

I've been looking at this very differently, because of
the unlinked SASL (or whatever) above TLS encryption,
which allows a whole bunch of man-in-the-middle attacks,

I've assumed:

(1) DTLS with _both_ CLIENT (SNMP Manager) and SERVER
    (SNMP Agent) public key certificate-based 
    authentication during the DTLS handshake
    (no anonymous DTLS sessions allowed).

(2) Use of the TLS session resume option (which works
    fine with DTLS) to make even the short exchanges
    efficient, after creating an initial DTLS session.

(3) Optional use of DTLS encryption (if there is strong
    mutual authentication and message integrity hashes,
    then the need for encryption is not automatic).

I would urge that SASL (or any other mechanism) _not_
be introduced - no additional security is achieved.

I suggest using TLS Server Name Indication, Client 
Certificate URL, and Trusted CA Indication extensions
defined in RFC 3546 (which documents TLS extensions 
useful for wireless clients, i.e., resource-constrained
clients).

I'll be off the air for about 24 hours, because of a
trip out-of-town.  I'll tune in again Saturday.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ken Hornstein
Sent: Friday, October 15, 2004 11:05 AM
To: [email-masked]
Subject: Re: [Isms] Reminder: ISMS proposals due October 18th 

>Not sure I understand this. Many protocols use TLS and SASL in
>combination. Are you saying they are all broken?

Many protocols provide the _option_ to do both.  I think doing one _or
the other_ is fine.

>Or are you saying
>that cleartext SASL authentication over TLS is broken and you should
>really be using a stronger SASL mechanism?

If you're doing a cleartext SASL authentication over TLS ... well, I
hesitate to call that "SASL", even.  I consider that basically TLS
(yes, I know it's using the SASL framework, but let's put that aside
for the moment).

I'll try to give you a clearer example.  Let's say that someone
authenticates a SASL protocol via GSSAPI (aka Kerberos) but encrypts
the session via TLS (and for the sake of argument, let's say that it
was anonymous TLS, but I don't think that's an unfair assumption).
Now, you _might_ think that you were protected against a
man-in-the-middle attack, because Kerberos protects against that ...
but, sadly, you are not.  The TLS connection is not "signed" by the
GSSAPI authentication; due to the layers involved, it doesn't even know
that it's happening.  That means that after you authenticate via
GSSAPI, a sufficiently sophisticated attacker could insert any commands
he or she wants into the data stream.

This gives Kerberos people fits, because they know that if you either
used the SASL-provided encryption (which in the GSSAPI case uses a
session key derived from the Kerberos exchange, which is protected
against MITM) or had some way of signing the TLS DH parameters via the
GSSAPI authentication exchange, you'd be protected.  There has been
some work on the latter front (see the "channel bindings" draft by Nico
Williams, draft-williams-gssapi-channel-bindings-00.txt), but I'm
not sure it will be ready in time for what we need.

If you don't consider this a huge problem, then that's fine ... I just
feel I would be remiss if I didn't bring it up.

--Ken

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 15 Oct 2004 13:30:37 -0400

>    application traffic doesn't make any sense).

Another minor nit ... I always hear protocol geeks gnash their teeth
about running TLS-based protocols on a different port (that's why many
protocols now have STARTTLS or something similar with them).  It may
not be possible to turn on DTLS in-line (I will confess that I don't
fully understand it all yet) but I'm sure someone's going to complain
about it.

--Ken

>convince people to force mutual authentication in

I have to echo Wes's comments here ... one requirement of the output of
this working group is that the security system fit in with _existing_
infrastructures, not require the creation of new security
infrastructures (this was a major complaint of USM).  This is
non-negotiable.  A PKI-only solution is a non-starter, IMHO (not
speaking as a WG chair here).

--Ken