Subject: Re: [Isms] authoritative

From: "Tom Petch" <[email-masked]>
Date: Mon, 3 Oct 2005 11:46:22 +0200

I work from the principle that if it is not needed, don't do it:-)

Authoritative engine id does not appear in the body of VACM [RFC3415] and only
appears as a gloss for securityEngineID in ARCH [RFC3411] and MPP [RFC3412] so
in that sense, the term seems to add nothing and can be dispensed with.

In MPP, when generatng a message, securityEngineID is taken from snmpEngineID
for Response and Internal Class PDU and from the target entity's snmpEngineID
for Confimed and Notification Class, which in turn is determined in an
implementation dependent manner .

The only time I see it used is in MPP, on receipt of a Confirmed Class PDU, when
the securityEngineID must match the snmpEngineID else the message is discarded.
So it appears to provide an additonal check that the message really got to the
intended engine.

All of which I am sure you know already.

In the case of SSH, I expect the secure, authenticated tunnel to provide the
assurance that the message has been delivered to the intended engine.  To
preserve the ASI, the ssh security model could take it from snmpEngineID thereby
ensuring the MPP check succeeds.  More complicatedly, it could be passed
transparently in the security parameters.

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>; "'David T. Perkins'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, October 01, 2005 8:59 PM
Subject: RE: [Isms] authoritative

> Hi Tom,
>
> Can you rephrase this into
> "Here are the requirements that led to its being part of STD62" and
> "Here's why those requirements do not apply to SNMPv3 with SSHSM"?
>
> David Harrington
> [email-masked]
>
>
>
> > -----Original Message-----
> > From: Tom Petch [mailto:[email-masked]]
> > Sent: Saturday, October 01, 2005 6:05 AM
> > To: David T. Perkins; David B Harrington
> > Cc: [email-masked]
> > Subject: Re: [Isms] authoritative
> >
> > <inline>
> > Tom Petch
> > ----- Original Message -----
> > From: "David T. Perkins" <[email-masked]>
> > To: "David B Harrington" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Saturday, October 01, 2005 9:09 AM
> > Subject: Re: [Isms] authoritative
> >
> >
> > > We (dbh and I) have gone over this multiple times, and
> > > it seems like we still disagree whether or not
> > > "authoritative engines" is a SNMPv3 concept or
> > > a USM concept. I believe it is purely a USM concept
> > > and has no requirement to be in other security models.
> >
> > Agree absolutely, it is an unnecessary complication; scrap it!
> >
>
>

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 3 Oct 2005 08:26:23 -0400

Hi Tom,

You analysis and my analysis are very similar, and we've reached
similar conclusions about how to preserve the ASIs when using SSH.

Unfortunately, many standards are defined capturing the solution, but
not the thinking that led to the solution. So it is unclear what
requirements were being met by having an authoritative engine, and
it's been a long time since those discussions, and my recall of the
requirements is fuzzy.

To the rest of the WG, what are the reasons we need to maintain the
concept of authoritative? Does the authoritative securityEngineID need
to be passed in the message when using SSH or other external security
substrate?

Two proponents of the authoritative engine were Steve Waldbusser and
Jeff Case. I have asked them to join in this discussion, in the hopes
they can recall the requirements in more detail than I.

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Monday, October 03, 2005 5:46 AM
> To: [email-masked]; 'David T. Perkins'
> Cc: [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Oct 2005 20:42:26 -0700

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Tom Petch'" <[email-masked]>; <[email-masked]>; "'David T. Perkins'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, October 03, 2005 5:26 AM
...
> to be passed in the message when using SSH or other external security
...

My recollection is that the only thing that the authoritative EngineID is
needed for is to figure out whose boots/clock information to use in
the anti-reply logic of USM.  Conceptually, it goes back to the field
snmpPartyIdentity described in RFC 1352, though the details of the
timeliness algorithms are different.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Oct 2005 21:02:57 -0700

Hi -

> From: "Randy Presuhn" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, October 03, 2005 8:42 PM
...
> timeliness algorithms are different.

Oh, it is also used with the user name to allow the recipient to know
which keys to use to authenticate and decrypt!

But, to the point of David Harrington's question, does it need to be
repeated on the wire in every message for every possible security model?
I'd say no, since that information would be associated with the connection,
assuming (1) there is a one user per connection limitation, and (2) we don't trip
ourselves up by confusing the user name for an Inform with the the user name
for a Trap.  (2) may be OK as an operational simplification, but we need to
be sure we're doing it consciously.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Oct 2005 07:39:27 +0200

On Mon, Oct 03, 2005 at 09:02:57PM -0700, Randy Presuhn wrote:

> [...] (2) we don't trip ourselves up by confusing the user name for
> an Inform with the the user name for a Trap.  (2) may be OK as an
> operational simplification, but we need to be sure we're doing it
> consciously.

Randy,

can you please elaborate on this? What do you think is the difference
between a user name for a trap and an inform? It sounds like you
believe there is a feature to have these different...

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Oct 2005 07:55:49 +0200

> believe there is a feature to have these different...

While I didn't think that's where Randy was going I do wonder what the 
operational difference between trap and inform would be in the case of 
SSHSM.

Eliot

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Oct 2005 10:04:00 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, October 03, 2005 10:39 PM
...

I'd say it's more an artifact of USM rather than a "feature", but it will
affect operational policies.

<Background>
In USM, the USM user name's "scope" is limited to
a particular engine, thus the indexing structure of the USM user table.
Nothing in USM requires or assumes that user "joe" on system A has
any relationship whatsoever to user "joe" on system B.

With USM, even if the security policy has been rationalized so that the
same model-independent security name is used for all systems in
an administrative domain (let's not worry about federation) there is
still good reason to use different USM user names for informs and
traps.  That reason is key localization.

For traps, the sender is authoritative, meaning it is the sender's
localized keys that are used for authentication and privacy.  Compromise
of the sending SNMP engine does not allow an attacker to impersonate any
other SNMP engine, and enables attacks only on the compromised device.

For Informs, the recipient is authoritative.  Compromise of the sending
SNMP engine allows an attacker to generate authenticated Get, Get-Next,
and Set requests that will look like they came from the Inform's intended
destination.  For this reason, the USM user names used for Informs
should NOT be ones that map to model-independent security names
that belong to VACM groups with vacmAccessReadViewName or
vacmAccessWriteViewName that permit access to anything sensitive,
on *ANY* system in the administrative domain.  (I'd set them both to "").
</Background>

You can see why I'd call it an "artifact" rather than a feature.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Oct 2005 10:17:22 -0700

Hi -

Ooops, I got it wrong.  It's been too long.  :-)
Corrections below.

Randy

> Sent: Tuesday, October 04, 2005 10:04 AM

> traps.  That reason is key localization.

so far, so good.

> destination.

s/intended destination/sender/

Add: It also allows Informs to be sent as though they were coming from
any other system.

>               For this reason, the USM user names used for Informs