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

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

Hi Ken,

Right - it's the interlayer security dependencies that
are at issue.  SASL by itself is fine.

Cheers,
- Ira

PS - Thanks for the excellent SASL tutorial - I'm just
reading it.

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

>Per the thread with Ken, client authentication at a 
>'higher layer' (SASL) really can't be made to work,
>without some unacceptable weakening of security.

Please note that I was talking about the combination of SASL and an
external encryption layer (like TLS).  If you just did SNMP-SASL over
TCP and used the encryption provided by SASL, I think that security
would be perfectly reasonable (I'm not saying that there wouldn't be
other problems with such a proposal ...  I'm just saying that I can't
see any security related issues).

--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: "Fleischman, Eric" <[email-masked]>
Date: Mon, 18 Oct 2004 09:02:38 -0700

Yes, it is problematic that there are a number of valid key management alternatives to leverage and that no one choice is likely to satisfy everyone. That is why I prefer approaches that support all of the "heavy hitters" (i.e., a single approach that permit bindings to kerberos, PKI, etc.). That way everyone's itch can be scratched.

From: Juergen Schoenwaelder [mailto:[email-masked]]

<snip> 

>I am using SASL enabled protocols all the day and so 
>I would think that authenticating SNMP users via SASL 
>should fit at least some operational requirements. 
>Sure, in a kerberos environment, leveraging kerberos
>services makes sense. The problem I see is that not all
>environments are the same nor that all SNMP interaction 
> patterns are the same. So searching for the holy grail 
>is kind of doomed to failure (and that
>probably reduces my enthusiam here a bit).
 
<snip>

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 18 Oct 2004 09:11:12 -0700

Ira,

No one system will meet everyone's need. While a PKI system would be the best choice for the environments in which I work, it would be fairly unusable in other environments. That is why I favor alternatives supporting multiple key management systems because that way I can have my PKI and you can have your whatever-it-is-that-you-use.

--Eric

-----Original Message-----
From: McDonald, Ira [mailto:[email-masked]]
Sent: Saturday, October 16, 2004 12:22 PM
To: 'Ken Hornstein'; [email-masked]
Subject: RE: [Isms] Reminder: ISMS proposals due October 18th 

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

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