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

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 14 Oct 2004 11:25:37 -0700

Hi Wes,

I've tried (without success) to figure out how to
write a short I-D that satisfies your requests below.

A few thoughts I had:

- EngineID could be derived by a hash of the PKI
  certificate of the SNMP Agent

- otherwise, EngineID discovery looks impossible
  to me (because a DTLS agent should NOT accept
  or respond to ANY traffic not authenticated
  at the DTLS session level)

- usm/vacmSecurityName could reasonably be derived
  by truncating the SHA-1 (160-bit) hash of the
  PKI certificate of the requester (SNMP Manager)
  to 128 bits and converting nibbles to hex digits
  (to satisfy 'SnmpAdminString' constraints),
  which would yield 32 octets.

- authentication and message integrity must be
  handled by DTLS

- encryption (if any) must be handled by SNMPv3,
  because otherwise the USM MIB won't work with DTLS

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: Wes Hardaker [mailto:[email-masked]]
Sent: Sunday, October 10, 2004 10:23 PM
To: McDonald, Ira
Cc: 'Juergen Quittek'; [email-masked]
Subject: Re: [Isms] Reminder: ISMS proposals due October 18th

>>>>> On Sun, 10 Oct 2004 09:14:00 -0700, "McDonald, Ira"
<[email-masked]> said:

Ira> I'm strongly in favor of consideration of TLS (or rather DTLS,
Ira> per Eric Rescorla's draft, so that connection-mode
Ira> issues/behaviors are not introduced).

Part of the motivation the ADs had in making a early deadline was to
not delay for protocol options that don't have energy behind them.  In
my view, there are two solutions which meet my security needs: SBSM
and the potential TLS.  Thus, I would love to see a TLS solution
documented so we should consider it.  Eric's draft, however, is not a
solution that can be considered by the WG, IMHO.  It is a building
block (a very good one), but it itself is not complete.  There are
many other issues to be worked out.

I guess the chairs will have to decide what a minimum candidate must
consist of.  But just saying "lets use TLS" isn't sufficient, IMHO
without a better description of how it will be used, how
authentication will be done within it, how it will be passed to the
SNMPv3 layer, how any other SNMPv3 specific things will be done on top
of it (such as engineid learning), etc.  I think all these problems
are solvable, and I'd encourage someone to put together a quick draft
describing the architecture they'd like to propose that solves the
whole problem not just the transport problem.

-- 
Wes Hardaker
Sparta

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Oct 2004 22:03:23 +0200

>   at the DTLS session level)

Not sure I can follow. What is the problem with engine ID discovery?
 
>   which would yield 32 octets.

Sounds pretty ugly. I think what is needed is user authentication
on top of an encrypted secure channel. And that should tie into
existing authentication mechanisms. (I think this was what people
really asked for - but I admit that I have not been at the BOF so
I might be totally disconnected.)
 
> - authentication and message integrity must be

I don't think DTLS does authentication.
 
>   because otherwise the USM MIB won't work with DTLS

I think the primary purpose of TLS or DTLS is to do encryption. Am 
I confused?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 14 Oct 2004 13:15:26 -0700

>>>>> On Thu, 14 Oct 2004 11:25:37 -0700, "McDonald, Ira" <[email-masked]> said:

Ira> I've tried (without success) to figure out how to
Ira> write a short I-D that satisfies your requests below.

Good!  (well, not the without success part...  but maybe I can help)

Ira> - EngineID could be derived by a hash of the PKI
Ira> certificate of the SNMP Agent

I don't think that existing implementations should be required to
change their existing context engine IDs because a different security
model is suddenly needed.  The security model should not need to
dictate the format of the context engine ID, thus I wouldn't consider
this solution.

Ira> - otherwise, EngineID discovery looks impossible
Ira> to me (because a DTLS agent should NOT accept
Ira> or respond to ANY traffic not authenticated
Ira> at the DTLS session level)

I don't think so.  DTLS should get things started from a
secure-transport point of view, which it will do.  The context engine
ID isn't needed till the first processing of a real request is needed.

The context engineID could be learned through security parameter
settings being passed either through the DTLS session inside the
protected portion of the DTLS session or by doing it afterward (DTLS
comes up and the first request through it should be an empty GET which
will trigger a DTLS-specific engineID report like USMs, or a GET to a
special OID that always returns the default contextEngineID).  The
later solution requiring an extra round trip though.

Ira> - usm/vacmSecurityName could reasonably be derived
Ira> by truncating the SHA-1 (160-bit) hash of the
Ira> PKI certificate of the requester (SNMP Manager)
Ira> to 128 bits and converting nibbles to hex digits
Ira> (to satisfy 'SnmpAdminString' constraints),
Ira> which would yield 32 octets.

Ack.  No!  Please!  If so, at a minimum please provide a mapping table
so that you could map a certificate to a SM compliant security user
name.  Please don't use a raw hash result.

Ira> - authentication and message integrity must be
Ira> handled by DTLS

Yes.

Ira> - encryption (if any) must be handled by SNMPv3,
Ira> because otherwise the USM MIB won't work with DTLS

Why does it need to?

-- 
Wes Hardaker
Sparta

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 14 Oct 2004 13:20:25 -0700

>>>>> On Thu, 14 Oct 2004 22:03:23 +0200, Juergen Schoenwaelder <[email-masked]> said:

>> at the DTLS session level)

Juergen> Not sure I can follow. What is the problem with engine ID
Juergen> discovery?

In a new security model based on DTLS or TLS how does the manager
learn the default contextEngineID of the agent?

Either:

1) this must be "learned" somewhere in the protocol (tools
   implementing USM do this now by assuming that the contextEngineID
   will be the same as the securityEngineID if the user doesn't
   explicitly specify one, though this practice is not documented in
   the RFCs I don't think).

2) The contextEngineID under a new TLS based protocol will be forced
   to be entered by the manager.  This is not scalable in my opinion.

-- 
Wes Hardaker
Sparta

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Oct 2004 22:43:25 +0200

> later solution requiring an extra round trip though.

Forgive me my ignorance, but is it not possible to discover the 
engine ID in pretty much the same way as we do it today with USM?
Perhaps we can even run USM (or a slightly simplified version of 
that) in noAuth/noPriv mode if there is a secure transport providing 
encryption, integrity protection and so on.

The real question is actually how to do the user authentication and
where to fit that into the architecture we have. Technically, it would
be cool to have a SASL hook for that (TLS and SASL seems to be a common
combination which I use daily - even to ship this email to you).

The end of all this, however, is that it is not going to be very
lightweight in terms of the number of messages required. So for polling
something that fits into a single packet every once in a while, SNMP
over [D]TLS will be expensive and we still need to figure out how much
benefit there actually is in using DTLS/UDP instead of TLS/TCP...

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 14 Oct 2004 14:28:12 -0700

>>>>> On Thu, 14 Oct 2004 22:43:25 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> Forgive me my ignorance, but is it not possible to discover the 
Juergen> engine ID in pretty much the same way as we do it today with USM?
Juergen> Perhaps we can even run USM (or a slightly simplified version of 
Juergen> that) in noAuth/noPriv mode if there is a secure transport providing 
Juergen> encryption, integrity protection and so on.

Thats one of the things I just suggested in a different note, yes.

Its not that its not solvable (I've thought of multiple ways)...  It's
just it needs to be decided how its going to be done.

Juergen> The real question is actually how to do the user
Juergen> authentication and where to fit that into the architecture we
Juergen> have.

Thats the other piece, as discussed in the other messages as well
(with no solution and I had been waiting for you to mention SASL so
thanks ;-)  Now, do you have an architecture for using it with DTLS
and SNMP yet that you can share (quickly!)?

Juergen> The end of all this, however, is that it is not going to be
Juergen> very lightweight in terms of the number of messages
Juergen> required. So for polling something that fits into a single
Juergen> packet every once in a while, SNMP over [D]TLS will be
Juergen> expensive and we still need to figure out how much benefit
Juergen> there actually is in using DTLS/UDP instead of TLS/TCP...

Can you write up a TLS/TCP architecture before Monday?  I'd love to
read it!

I actually think someone should write up a generic one for TLS for the
common pieces (authentication mapping; engineID discussions) in general
and leave the UDP/TCP transport half to its own part which was
independent from the other things that need to be solved.

-- 
Wes Hardaker
Sparta

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Oct 2004 23:55:00 +0200

> and SNMP yet that you can share (quickly!)?

I am thinking first. There are some non-trivial questions to answer
and I first want to get a good feeling how to work things into the
architecture we have. (Perhaps hacking an implementation is easier
than getting things folded into the architecture. ;-)
 
> Can you write up a TLS/TCP architecture before Monday?  I'd love to

I'd love to read it as well. There is not much time left.
 
> independent from the other things that need to be solved.

I think there are differences between TLS/TCP and DTLS/UDP. With TCP,
you can easily have an endpoint which accepts plain SNMP/TCP and
SNMP/TLS/TCP connections and you can keep the easily separate. With
DTLS, this won't be as easy.

There are also a bunch of question how you would support SASL. Do you
do an ad-hoc SASL exchange before you declare the SNMP/TLS session to
be open for SNMP or do you SNMP style messages to actually wrap a SASL
exchange, potentially running the SASL exchange as part of the security
model box of the architecture. There are serious design decisions here
and it is unlikely that these will be solved by Monday.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 14 Oct 2004 15:11:17 -0700

>>>>> On Thu, 14 Oct 2004 23:55:00 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> There are also a bunch of question how you would support
Juergen> SASL. Do you do an ad-hoc SASL exchange before you declare
Juergen> the SNMP/TLS session to be open for SNMP or do you SNMP style
Juergen> messages to actually wrap a SASL exchange, potentially
Juergen> running the SASL exchange as part of the security model box
Juergen> of the architecture. There are serious design decisions here
Juergen> and it is unlikely that these will be solved by Monday.

The chairs would have to answer how much of an complete architecture
it needs to have to be considered.  I'd write up both possibilities
most likely and say the choice needs to be made in the future.  The
intent of the deadline was to have a thought out architecture that was
believed to be suitable so we could consider it as a path forward.  I
don't think it needs to be perfect, just plausible.  I'd assume that
it'd be ok to define both solutions or pick one that you like and we
can debate whether that solution was right after it gets selected as
the candidate to work on.

If there are so many people interested in a TLS solution, how come
no-one is willing to do the work?  If thats the case, then even if we
all agreed that TLS is the right way to go would be we better off if
no one agreed to do it?  We need an author to step forward with
enthusiasm ASAP.

-- 
Wes Hardaker
Sparta

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 15 Oct 2004 10:19:29 -0400

>and it is unlikely that these will be solved by Monday.

One point to bring up regarding the combination of SASL & TLS:

Crypto geeks that I know scream bloody murder when people do things
like perform a SASL authentication and use TLS for link encryption.
This is because there is no binding between the authentication of the
session and the encryption, and since most of the time TLS is
negoitated anonymously, that means you can be put in the unenviable
position of having a successful authentication complete, but be
completely open to a man-in-the-middle attack.  If you're going to do
just TLS, then that's fine ... the positives and negatives of that
approach are well understood.  But if you're combining SASL & TLS, you
might be giving yourself a false sense of security.  Most SASL people
would prefer that you use the encryption offered by SASL mechanisms
(when it is available, of course ... not all mechanisms support
encryption).

--Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Oct 2004 16:41:08 +0200

> (when it is available, of course ... not all mechanisms support

Not sure I understand this. Many protocols use TLS and SASL in
combination. Are you saying they are all broken? Or are you saying
that cleartext SASL authentication over TLS is broken and you should
really be using a stronger SASL mechanism?

/js

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 15 Oct 2004 11:05:02 -0400

>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

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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 15 Oct 2004 08:56:32 -0700

>>>>> On Fri, 15 Oct 2004 11:05:02 -0400, Ken Hornstein <[email-masked]> said:

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

I'm not a SASL expert at all as its one of the systems I haven't
looked much into the details of.

More generically, however, the standard solution is to provide a
cryptographic binding between the inner authentication layer and the
outer layer secure transport.  The only way to do this, generally, is
to have a generated key passed between the two layers so that they can
be bound together through an authentication hash that ties the two
connections together.  I'm not sure if a TLS/SASL combination can
support this but I'd hope so.

-- 
Wes Hardaker
Sparta

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 15 Oct 2004 12:35:56 -0400

>support this but I'd hope so.

Sure, everyone agrees that this is what _should_ happen.  It's just
that there is no defined protocol to exchange this hash, no one has
decided on which hash algorithm to use or how to negotiate the hash
algorithm, nor the format of this hash, and AFAIK neither the SASL or
TLS APIs provide a way to get or set the necessary key.  So,
essentially, this _doesn't_ happen today.  And if we defined a TLS/SASL
authentication framework for SNMP, it wouldn't happen unless we waited
for the community (likely the SASL community) to solve the problem.
They're working on it, but I get the sense it's not going to happen
anytime soon.

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 15 Oct 2004 12:43:49 -0400

>than getting things folded into the architecture. ;-)

<wg chair hat on>

As a WG chair, I'd gladly accept a submission for consideration even if
it wasn't fully fleshed out.  From the note I sent out a little while
ago:

Submissions do not need to be full-fledged, but should at least give a
general overview of the proposed solution.

So even if there are unanswered questions, I get the sense you have
enough now to get it on the table.

<wg chair hat off>

--Ken