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

From: "McDonald, Ira" <[email-masked]>
Date: Sat, 16 Oct 2004 12:22:15 -0700

Hi,

I concede that a PKI-only solution is no help.

So, what about:

(1) TLS with Kerberos Authentication (RFC 2712)
    - used with the DTLS connectionless substrate

and/or

(2) TLS with Secure Remote Password
    - SRP is one-time password (diminishing numbers
      of repetitive hashes of the seed to yield the
      current value one password, which when used
      immediately expires)

Refereences:
[RFC2945] The SRP Authentication and Key Exchange System
          September 2000

[TLS-SRP] Using SRP for TLS Authentication
          <draft-ietf-tls-srp-08.txt>, August 19, 2004

Both of these avoid the need for PKI deployment and both
are fairly widely deployed today.

As to the dedicated port issue, since we aren't allowed 
to modify or extend the SNMP protocol operations, we'd
have to have some kludge (i.e., Set serial number and 
some string value to some MIB object) to pass STARTTLS
in the SNMP application datastream.  Do we think the
SNMP purists will swallow such a kludge to avoid a
dedicated port?

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 1:31 PM
To: [email-masked]
Subject: Re: [Isms] Reminder: ISMS proposals due October 18th 

>(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).

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

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

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

_______________________________________________
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: Wes Hardaker <[email-masked]>
Date: Sat, 16 Oct 2004 13:04:16 -0700

>>>>> On Sat, 16 Oct 2004 12:22:15 -0700, "McDonald, Ira" <[email-masked]> said:

Ira> (1) TLS with Kerberos Authentication (RFC 2712)
Ira> - used with the DTLS connectionless substrate

I'd hesitate to require kerberos since it isn't used everywhere
(certainly less than other authentication DBs like radius, etc).
However, I do think the result should include the ability to use
kerberos in an ideal world.

Ira> (2) TLS with Secure Remote Password
Ira> - SRP is one-time password (diminishing numbers
Ira> of repetitive hashes of the seed to yield the
Ira> current value one password, which when used
Ira> immediately expires)

Again, not everyone wants one-time passwords.  Flexibility is the key.

I'd suggest writing a draft that documents how we'd use TLS and which
authentication mechanisms we'd allow and thus allow both 1 and 2 above
and document how the login information is passed to the higher SNMP
layer.  I think flexibility will be key in the results to ensure we
don't have to go down this road again in 5 years when some new
authentication mechanism becomes popular.

Ira> As to the dedicated port issue, since we aren't allowed to modify
Ira> or extend the SNMP protocol operations, we'd have to have some
Ira> kludge (i.e., Set serial number and some string value to some MIB
Ira> object) to pass STARTTLS in the SNMP application datastream.  Do
Ira> we think the SNMP purists will swallow such a kludge to avoid a
Ira> dedicated port?

I don't think you need to do that.  You can write new security
protocols that make use of new fields in the security parameters
section of the SNMPv3 message without modifying the base.  In these
parameters you could pass TLS start information.  (Both KSM and SBSM
make use of security-model specific parameters that extend the base
packet format with parameters specific to each of these security
models...  They didn't require modifying the protocol).

However, I don't think Ken was saying you couldn't require a separate
port.  Just that we need to make that decision carefully, as some
people don't like it.  It may or may not be possible to reuse port 161
by carefully encapsulating the start-TLS requirements.  However,
unlike TCP where the data is contained and thus its easier to
encapsulate future packets within a stream below the SNMP layer
so-as-to-hide the fact it went over a secure transport, I suspect this
will be more difficult with DTLS and the SNMP stack will have to be
much more involved.  Thus I'm not yet convinced this is the right way
to go and I think a separate port would be less work for most stacks
which would be a win in the end.

-- 
Wes Hardaker
Sparta