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

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Apr 2005 17:57:08 +0200

Ok, Dave, but the whole point is to be able to use the authentication 
from the external mechanism...

Thanks,

Eliot

David B Harrington wrote:
> As sam points out, if eliot is authorized to proxy for dave, that also
> would be acceptable. (I hope I got the wording right).
> 
> dbh 
> 
> 
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of David B Harrington
>>Sent: Monday, April 18, 2005 11:24 AM
>>To: 'Eliot Lear'
>>Cc: 'Sam Hartman'; [email-masked]
>>Subject: RE: [Isms] SSH / Reusability / etc
>>
>>Hi Eliot,
>>
>>I don't think authenticating as eliot and having dave in the PDU is
>>bad; but dave would need to be independently authenticated. For
>>example, I don't have a problem authenticating a TLS transport, and
>>then passing SNMP packets through that transport that would be
>>SNMP-authenticated (e.g. via USM or RADIUS). Of course, one would
> 
> need
> 
>>to be careful of man in the middle attacks.
>>
>>dbh
>>
>>
>>>-----Original Message-----
>>>From: Eliot Lear [mailto:[email-masked]] 
>>>Sent: Sunday, April 17, 2005 3:41 AM
>>>To: [email-masked]
>>>Cc: 'Blumenthal, Uri'; 'Sam Hartman'; [email-masked]
>>>Subject: Re: [Isms] SSH / Reusability / etc
>>>
>>>Dave,
>>>
>>>You're exactly correct that OBTW means Oh By The Way.  The 
>>>substantial 
>>>surgery that would need to be done is that if you are
> 
> authenticating
> 
>>>against the thing you are tunneling into (say, SSH keys with 
>>>SSH or SASL 
>>>or TLS with something else like BEEP), I do not think it a 
>>>good idea to 
>>>retransmit any additional authentication information in the 
>>>encapsulated 
>>>SNMP PDU.  In other words, what would happen if the SSH user 
>>>authenticates as "eliot" and the PDU contains "dave"?  That
>>
>>shouldn't 
>>
>>>happen.
>>>
>>>That's all I'm saying.
>>>
>>>Eliot
>>>
>>
>>
>>
>>_______________________________________________
>>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: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 18 Apr 2005 13:24:55 -0400

It is not even an "overload". usmUserName is merely an indeitifier to
bind together the packet with security information in the local table.
As you say, an "index".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Marcus Leech
Sent: Monday, April 18, 2005 8:07 AM
To: Wes Hardaker
Cc: Sam Hartman; [email-masked]
Subject: Re: [Isms] SSH / Reusability / etc

Unless I'm mis-reading the existing USM spec, the existing username
field
  *could* conceivably be "overloaded" with a session identifier 
instead--which
   would be a logical index into a table containing the keys, username, 
etc, etc.

That would be useful in an architectural direction where USM gets
touched
  either very little, or not at all, with OOBK.

Wes Hardaker wrote:

>>>>>>On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman
<[email-masked]> said:
>>>>>>            
>>>>>>
>
>Sam> Also, note that SASL has its own mechanism for conveying the
>Sam> inner identity.  So if you were using SASL you might want to
>Sam> decide that you didn't need an identity in the SNMP PDU.
>
>[FYI, this (and the other examples) are exactly why the SBSM running
>message has a numeric session identifier rather than a user string in
>it...  The user string is pulled from the authentication exchange and
>is stored by both sides and referenced via the session identifier.
>I'd expect TLS, SSH, or anything else that did the authentication
>elsewhere to do something similar (and yes, a USM user name field in
>the USM security model parameters could in theory be warped into a
>session identifier as well.  I'd argue heavily against that scheme
>using the same security model number even if the packet format was
>otherwise the same)]
>
>  
>

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 18 Apr 2005 10:53:19 -0700

From: David B Harrington [mailto:[email-masked]] 
>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.

I trust that you are not objecting re-using an enterprise-wide Kerberos
or PKI authentication system for ISMS?

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 19 Apr 2005 14:28:42 -0400

> In your message, you said that you wanted two SNMP security models.
> The first to set up a session, and the second to use the parameters
> that were set up to exchange SNMP data messages.

Yes.

> And you said that your motivation was to "allow interchanging
> keying mechanisms and data protection mechnisms independently."

Yes.

> My question was why could you not have two phases in a single
> SNMP security model, since other protocols do so?

To allow one keying model to be able to provide for more than one
data-protecting model.

Also to allow more than one keying model (then I might separate
RADIUS-based keying from SSH-based keying, for example).

Also to simplify data-protecting model(s) - otherwise it will have to
deal with different classes of traffic: establishment traffic and data
traffic. IPsec cleanly separates between the two, and I like it.

> However, I was planning on bootstrapping a prototype by
> first doing the "running" (your second security model)
> assuming a fixed set of parameters, and then adding the
> first phase that did the mutual auth, session keying, etc.

I don't know.

> So, maybe it might work out to be a little easier.
> Note that both the VACM "to group" and the "access"
> tables use the security model as an index. Which of
> the two security model identifiers were you going
> to use?

The second one, of course. The "data-protecting" one. Since VACM is
about the data. RADIUS etc. are about whether a given RADIUS (or SSH)
user is allowed to access this SNMP engine at all.