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

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Apr 2005 09:41:28 +0200

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

---

From: Sam Hartman <[email-masked]>
Date: Sun, 17 Apr 2005 15:35:32 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Dave, You're exactly correct that OBTW means Oh By The Way.
    Eliot> The substantial surgery that would need to be done is that
    Eliot> if you are authenticating against the thing you are
    Eliot> tunneling into (say, SSH keys with SSH or SASL or TLS with
    Eliot> something else like BEEP), I do not think it a good idea to
    Eliot> retransmit any additional authentication information in the
    Eliot> encapsulated SNMP PDU.  In other words, what would happen
    Eliot> if the SSH user authenticates as "eliot" and the PDU
    Eliot> contains "dave"?  That shouldn't happen.

Sure it should happen if the authentication level identity elliot is
allowed to act as the SNMP-level identity dave.  You need to have an
authorization level mapping for this, but the apps community has found
that allowing such proxy authorization is often useful.

There's a discussion of this concept in draft-ietf-sasl-rfc2222bis but
the working group seems to believe that discussion needs more work so
it may not be as clear as you would like.

Also, note that SASL has its own mechanism for conveying the inner
identity.  So if you were using SASL you might want to decide that you
didn't need an identity in the SNMP PDU.

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 17 Apr 2005 13:32:11 -0700

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

-- 
Wes Hardaker
Sparta, Inc.

---

From: Marcus Leech <[email-masked]>
Date: Mon, 18 Apr 2005 11:07:10 -0400

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.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 18 Apr 2005 11:23:40 -0400

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 18 Apr 2005 11:39:08 -0400

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 

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 18 Apr 2005 09:16:41 -0700

>>>>> On Mon, 18 Apr 2005 11:07:10 -0400, Marcus Leech <[email-masked]> said:

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

Right, that's pretty much what I said.

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

Note that all of the architectures could likely use USM for message
protection if that was the choice (I don't think it's the right
choice, but thats another story).

-- 
Wes Hardaker
Sparta, Inc.