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

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 18 Oct 2004 09:13:59 -0700

Hi,

I agree that an ISMS that depends on only one key management
alternative will be unsatisfactory.

I also agree with Ken that SASL _all_by_itself_ could be used
with SNMP.  Because of the inner/outer security layer linkage
needed for SASL over TLS, I fail to see the value of TLS (or
conversely, of SASL).

There are TLS standardized bindings to many authentication
schemes, but even there, exporting that knowledge up into the
SNMP application layer looks complicated.

Unfortunately, TLS falls off the edge for ISMS, because we
didn't have sufficient discussion and concensus on a TLS
approach to get an I-D out today.

But this perceived requirement to support multiple key
management and authentication schemes should certainly be
applied when reviewing other ISMS alternatives (e.g., an all
RADIUS approach should not be accepted).

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: Fleischman, Eric [mailto:[email-masked]]
Sent: Monday, October 18, 2004 12:03 PM
To: [email-masked]
Cc: Wes Hardaker; McDonald, Ira; [email-masked]
Subject: RE: [Isms] Reminder: ISMS proposals due October 18th

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>

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 18 Oct 2004 09:41:12 -0700

>>>>> On Mon, 18 Oct 2004 09:13:59 -0700, "McDonald, Ira" <[email-masked]> said:

Ira> But this perceived requirement to support multiple key management
Ira> and authentication schemes should certainly be applied when
Ira> reviewing other ISMS alternatives (e.g., an all RADIUS approach
Ira> should not be accepted).

I'm not sure "not be accepted" is the right wording.  Personally, I
think its not what would be ideal for the operators out there as it
wouldn't meet everyones needs.  However, I think the proper wording
would be more like "must be weighted carefully".  I don't think an end
goal of "must support at least 10 mechanisms" is wise either.  I think
we need to strike a balance, make one mandatory to implement
(probably) and hopefully use a fairly extensible solution so adding
new authentication mechanisms in the future would be easy.  For SBSM,
eg, it takes about a page of text to describe how to add another
authentication mechanism without modifying the rest of the document.
I think this is a good thing, as it allows for future expansion if we
ever needed it (but that doesn't mean I think we should support
everything under the sun either; just the most needed).  [Many other
protocols have taken similar lines.  EAP, etc, also allow for easy
future expansion because they have recognized that environments
differ greatly and that the future is far from certain]

-- 
Wes Hardaker
Sparta

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 18 Oct 2004 13:22:36 -0400

>needed for SASL over TLS, I fail to see the value of TLS (or

To be fair ... SASL does provide an architecture that supports
authentication (the piece that TLS is generally deficient in) and it
can do encryption (_if_ the SASL mechanism supports it), and there is a
reasonable set of APIs that exist to get the authentication information
to the application.  So SASL alone would be fine, IMHO.  Well, it
would be a challenge to get some of the back-ends in there (e.g.
RADIUS), but I don't think it's insurmountable.

--Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Oct 2004 22:21:53 +0200

> approach to get an I-D out today.

Just for the record: I submitted an ID which is still in its infancy
stage. It is up the chairs whether they want to consider or right 
away defeat it. What we were trying to do was to start work on how 
a security mechanism which is part of a transport (in terms of the 
SNMP architecture) could fit into the SNMP architecture. This is
the SNMP architecture part of the work that needs to be done. 

The other part of the work is to identify how TLS and/or how SASL
would be a viable secure transport. I tried to collect some of the
wisdom of recent messages here on the list but there is lots of
work to be donw in order to get something meaningful. Our motivation
is more that the SNMP architecture work needs only be done once and
then we can add secure transports as they come and go.

The ID will be called <draft-schoenw-snmp-tlsm-00.txt> once it is
being posted. We plan to continue work on this before the IETF so 
any suggestions and contributions are welcome.

/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: Mon, 18 Oct 2004 15:00:00 -0700

>>>>> On Mon, 18 Oct 2004 22:21:53 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> Just for the record: I submitted an ID which is still in its infancy
Juergen> stage.

Infancy drafts are acceptable, as previously discussed.  If you want
it to be considered, I suggest you say so really quickly since the
deadline was technically this morning ET and we haven't heard about it
until now.  It sounds like this is sort of a message saying that, but
you weren't very explicit.

-- 
Wes Hardaker
Sparta

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Oct 2004 00:45:25 +0200

> Juergen> Just for the record: I submitted an ID which is still in its infancy

I have submitted an ID and I think this is what was required. It has not
shown up so I was waiting to see that I actually managed to get all the
formalisms we have to follow these days right.

At the end, I think it is the job of the chairs to decide whether they
accept the ID. So thanks for reminding me.

/sj