Subject: RE: [Isms] SSH / Reusability / etc

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 15 Apr 2005 20:24:28 -0400

Dave H,

I think we're on the same page. I agree with all the 4 points you've
made.

Minor clarification: if using USM, then "securityName" would be the name
authenticated say, by RADIUS, and "usmUserName" would be an  ephemeral
name generated for this session. I mean, auditing based on ephemeral
names is harder than that based on the RADIUS-authenticated ones.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B Harrington
Sent: Friday, April 15, 2005 5:12 PM
To: 'Wes Hardaker'; 'Sam Hartman'
Cc: [email-masked]
Subject: RE: [Isms] SSH / Reusability / etc

Hi,

So there is no ambiguity, 

1) I do not support copying the keys from another protocol to stuff
into USM. I think that approach creates the potential for exposure of
the keys, which would weaken both protocols.

2) I can live with having the SNMP keys delivered to an SNMP security
model over a secure protocol, but that would not be my preference
because I think it creates the potential for exposure of the keys.
This could be slightly problematic remaining in sync with a
centralized server ( a fired operator whose credentials are removed
from RADIUS, might still have access to SNMP devices until the keys
were removed from the SNMP entity.)

3) My preference is to have SNMP be ignorant of the authentication
credentials used by another protocol, and to have that protocol simply
inform the SNMP security model of the authenticated user identity. The
security model might then dynamically stuff the securityname and other
necessary parameters into the USM MIB or a similar MIB so the SNMP
engine components can utilize the securityName to provide access
control, audit logging, etc. based on the securityName.

4) I would like to see the authentication server also provide
authorization information that ties into the VACM groupname table or a
similar approach to identifying which acceess control "policy" should
be applied for this security principal. I support the use of RADIUS or
other AAA server as one source for authorization policy.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wes Hardaker
> Sent: Friday, April 15, 2005 4:26 PM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: [Isms] SSH / Reusability / etc
> 
> >>>>> On Fri, 15 Apr 2005 12:45:11 -0400, Sam Hartman 
> <[email-masked]> said:
> 
> Sam> no.  It is OK to explore use of the ssh keys, although 
> I'm personally
> Sam> against it.  As an AD, you'd need to get the secsh wg's 
> cooperation.
> 
> Sam> Re use of the ssh protocol is clearly OK if you can make it
work.
> 
> I think there have been multiple people who have "almost" suggested
> using another protocols like TLS and SSH in such a way as to
bootstrap
> USM with the keys, and then dump the other transport since it was
only
> used to define keys.  IE, I think there are a number of people that
> want to functionally this:
> 
>   1) start SSH or TLS between a command generator (CG) and a command
>      receiver (CR), for example (obviously not limited to just CG/CR
>      pairs).  This would include user authentication in the process
>      (anything from Radius, SASL, SSH-keys, ... works here)
> 
>   2) once that secure "link" is open, steal its keys (Ks).
> 
>   3) close transport
> 
>   4) throw Ks into engines for CR/CG
> 
>   5) continue with SNMP/USM (over the standard transport port 161 or
>      whatever) using Ks and, um, some user name and engineID as yet
>      not well discussed.
> 
> I *think* people are hinting at this, but no one has stated it
clearly
> so I can't be sure.
> 
> 1) I really don't see the benefit in this.  You're starting up
>    perfectly secure transport that is actually more secure and
>    flexible than USM and then dumping it so you can fall back use
>    something that isn't needed.  I don't see how this is simpler
than
>    merely tunneling SNMP through TLS/SSH or whatever as DTLS wants
to
>    do.  Heck, you could even do USM processing of the resulting SNMP
>    packet that was tunneled if you wanted as long as you ignore the
>    results and the security model number was actually different.  I
>    won't go farther into this unless someone agrees that what I've
>    described is actually what they're wishing to do.
> 
> 2) this is, in fact, an out of band keying mechanism *not* a
>    encapsulated keying mechanism and I hope everyone sees that.
[not
>    that it couldn't be a solution, but there is a difference].
> 
> -- 
> Wes Hardaker
> Sparta, Inc.
> 
> _______________________________________________
> 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: "David B Harrington" <[email-masked]>
Date: Fri, 15 Apr 2005 20:40:30 -0400

Hi Uri,

It would help if you were more specific about "using USM" - My
comments were about using the USM MIB or a similar MIB. This is
distinct from using the USM processing rules.

The securityName would be a long-lived human-readable
security-model-independent identifier of the security principal, in a
mode similar to usmUserSecurityName. In your example, the securityname
might be the same as that stored in a RADIUS server to identify a
security principal (e.g. an employee name). This would be useful for
audit logging, and is required for the SNMPv3 ASIs.

If there is a session identifier or other ephemeral identifier, that
would be a model-specific identity in a manner similar to usmUserName.

David Harrington
[email-masked]

> From: Blumenthal, Uri [mailto:[email-masked]] 
> Sent: Friday, April 15, 2005 8:24 PM
> To: [email-masked]; Wes Hardaker; Sam Hartman
> Cc: [email-masked]
[mailto:[email-masked]]