Subject: Re: [Isms] authoritative

From: "David T. Perkins" <[email-masked]>
Date: Sat, 1 Oct 2005 00:09:32 -0700 (PDT)

HI,

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.
Also, I believe that USM could have been designed
so that either SNMP engine could have been the
authorattive engine. Also, USM as specified does
not require that certain engines have an engineID
assigned to them. I believe that only engines that
have a "persistent" transport address need an
engineID. I also believe that SNMPv3 talks about,
but leaves out the development and definition of
an important "role", which I have called "observer"
over the years.

Thus, I believe, putting aside proxies, there are
the following SNMP interactions and roles:

 SNMP MGT APP------GET/SET/BULK------>SNMP AGENT
             <--------RESPONSE-------

In the above SNMP messages, the contextEngineID is that
of the SNMP agent.

 SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP AGENT
                        -------RESPONSE----->
In the above SNMP messages, the contextEngineID is that
of the SNMP agent.

 SNMP NOTIFICATION RCVR<------TRAP/INFORM----SNMP OBSERVER
                       -------RESPONSE------>

In the above SNMP messages, the contextEngineID is that
not that of the SNMP observer, but that of the SNMP agents
in the system that is being observered (monitored).

In the above, ONLY the SNMP AGENT and SNMP NOTIFICATION RCVR
need to have a persistent transport address.

On Fri, 30 Sep 2005, David B Harrington wrote:
> Hi,
> 
> In SNMPv3, we have the concept of authoritative. We need to discuss
> what that means for the SSH security model. 
> 
> I am especially interested in hearing from those who helped develop
> SNMPv3 and the notion of authoritative engines in the first place, and
> those who fought for the manager being authoritative for Informs (of
> whom I am one). 
> 
> Obviously everybody is welcome to get in involved, but I'm really
> trying to understand whether the historical requirement is stll valid,
> and if you don't know what that historical requirement was, you
> probably cannot answer the question very well.
> 
> Once we establish the requirement, we can determine whether SSH meets
> the requirement, in both normal mode and the proposed callback mode.
> 
> David Harrington
> [email-masked]

Enjoy,
/david t. perkins

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

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 1 Oct 2005 13:25:42 -0400

Hi,

I think maybe the concept should have been limited to USM, and would
like to eliminate it from the SSH security model if possible, but I
need to gain WG consensus to do this, and before we make such a
decision, we need to understand why the concept exists at all. That's
why I'm starting this discussion about the requirement of having an
authoritative engine.

Please note that the authoritative engine is related to the
securityEngineID, never the contextEngineID, even though both
securityEngineID and contextEngineID are related to snmpEngineID. This
discussion is explicitly NOT about whether we need an snmpEngineID or
contextEngineID; that's a different discussion.

The RFCs as written show the "authoritative" securityEngineID to be an
RFC3411 requirement (i.e. independent of the message version). The
"authoritative" securityEngineID is described in the RFC3411
architecture's ASIs. However, it is only found in
generateRequestMsg(), processIncomingMsg(), and generateResponseMsg()
- all of which exist in the message-processing-to-security-model
interface.

Its USAGE shows it to be an SNMPv3 requirement. RFC3412 has two parts
- sections 1 through 6 are about the message processing **subsystem**;
section 7 is about the **version 3 message processing model**. 

securityEngineID is set in section 7.1 (Outgoing message EOP)
paragraph 8a, in the generateResponseMsg() ASI to the local
snmpEngineID, paragraph 9a for the generateRequestMsg() ASI to the
local snmpEngineID or to the target snmpEngineID, depending on the
message Class.

For outgoing messages, the USM security model sets the
securityEngineID in section 3.1 paragraph 1a to the local snmpEngineID
(if it is a response or a report), or the value specified in the
generateRequestMsg() ASI is used to perform lookup in the USM tables.
Subsequently, securityEngineID is passed in the
msgAuthoritativeEngineID field of the securityParameters. (The format
and contents of securityParameters are security-model-dependent. In
the SSHSM, we may not need msgAuthoritativeEngineID.) 

Note that USM also uses a zero-length msgAuthoritativeEngineID to
cause discovery of a remote engine's snmpEngineID.

For incoming messages, the USM security model caches the
securityEngineID from msgAuthoritativeEngineID in section 3.2,
paragraph 2) and returns it to the message processing model in an OUT
parameter of the processIncomingMsg() ASI.

securityEngineID is subsequently USED in RFC3412 section 7.2 (Prepare
Data Elements from an Incoming SNMP Message - part of the SNMPv3
message processing elements of procedure) paragraph 13a , where it is
verified for a confirmed message to be equal to the local
snmpEngineID. If it is not equal, then the cache is cleared, the
message is discarded, and a FAILURE is returned.

I don't see the securityEngineID being used elsewhere in the RFC341x
specs.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David T. Perkins
> Sent: Saturday, October 01, 2005 3:10 AM
> To: David B Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] authoritative
> 
> HI,
>

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 1 Oct 2005 14:11:25 -0400

Hi,

David and I have discussed this before, many times, since
"authoritative engines" was a contentious issue in the SNMPv2 wars.
Hopefully, we can keep the WG discourse civil this time.

I have changed the subject line of this thread to contextEngineID. 

While both securityEngineID and contextEngineID refer to an engine's
snmpEngineID, and while they frequently refer to the same engine,
securityEngineID and contextEngineID serve different purposes, and do
not always refer to the same engine. An "authoritative engine" is
always related to the securityEngineID being passed in the
RFC3411/RFC3412/RFC3414 ASIs. The authoritative engine is not about
contextEngineIDs. 

Comments inline.

> and has no requirement to be in other security models.

See my other mail under the topic "authoritative"

> authorattive engine. 

Others disagreed with this.

> Also, USM as specified does
> assigned to them. 

I concur that USM does not require this. But SNMPv3 requires a
contextEngineID in the scopedPDU.

> I believe that only engines that
> engineID. 

One purpose of the snmpEngineID is to identify a datastore gathered
from an engine, independent of the address. If the engine changes its
address, presumably via DHCP, or has multiple addresses, on a router
for example, then an NMS can correlate the datastores gathered from
multiple addresses as being from the same engine. This can be
important for maintaining historical trending data, or eliminating
redundant icons in an NMS GUI.

In addition, the engineID identifies the datastore that was the source
of information, regardless of the transport address of the last hop.
This is important when a scopedPDU is passed through a proxy or a
trap-forwarder or a NAT, to be able to identify the engine that
sourced the data.

> I also believe that SNMPv3 talks about,

Yes, the contextEngineID identifies the source of the data.

But the point of the "authoritative" discussion is authoritative
engines, and the authoritative engine is NOT always the same as the
contextEngineID, even when putting aside proxy. 

And when used in a proxy situation, an application that is part of
STD62, the "authoritative" engine is NEVER the contextEngineID.

> need to have a persistent transport address.

Your argument is about who needs a persistent transport address. That
is not the purpose of the "authoritative" thread, nor do I see it
being impotant as an aspect of the comntextEngineID discussion.

I consider the following comment to be out of scope for this WG:

I'm not sure I agree with your contention that the SNMP agent
necessarily needs a persistent transport address. An NMS that monitors
the network for new transport adddresses being added to the network
and monitors fo rnon-reachability of known addresses (both common
features of NMS platforms), could correlate any new addresses to the
datastore associated with their snmpEngineID, and eliminate
non-reachable addresses from association with existing datastores,
thus adapting to non-persistent transport addresses. 

This would be more difficult for notification generators since they do
not typically perform a network monitoring function like NMS platforms
do.

David Harrington
[email-masked]

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 1 Oct 2005 12:05:01 +0200

<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

> and has no requirement to be in other security models.

Agree absolutely, it is an unnecessary complication; scrap it!

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 1 Oct 2005 14:59:47 -0400

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]

> From: Tom Petch [mailto:[email-masked]] 
> Sent: Saturday, October 01, 2005 6:05 AM
> To: David T. Perkins; David B Harrington
> Cc: [email-masked]

---

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

contextEngineID I saw as a given for isms, since it appears part of the
ScopedPDU [RFC3412] and we are not meant to change the PDU.

I also saw it as a reasonable part of the context, that is contextName would not
be globally unique but contextEngineID.contextName would be.  There is then the
challenge of determining the snmpEngineID of the target entity in an
implementation
dependent manner [RFC3412], soluble but tedious, no different for USM, SSH, etc
etc.

The one thing that gives me pause is the ASI in RFC3412 which an application
uses to register itself for processing pdu, where it provides pduType,
naturally, and
contextEngineID - eh? can this be anything other than the snmpEngineID?  can
there be more than one in an SNMP entity as the adjacent text suggests?  That
ASI I have never understood.

Whatever, I still see contextEngineID (unlike securityEngineID) as something
that stays unchanged in isms.

Tom Petch

---

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

Hi Tom,

I agree that contextEngineID is still needed, even if we can eliminate
securityEngineID and/or the authoritative concept. There are ways to
accomplish similar things that contextEngineID permits, such as
overloading the contextName, but changes to the PDU are outside the
scope of this WG.

As I recall, there were a number of cases where multiple engineID/PDU
registrations could occur. 

1) In SNMPv1, there were cases where a community string could be
fashioned as "public@deviceB" or "deviceB:public" and so forth, and
the SNMP engine would send the message to deviceB, typically using the
"public" community extracted from the compound-style community name.
If device B has an assigned engineID (even if only the engine with the
PDU registration knows it, and deviceB doesn't actually support an
snmpEngineID, existing systems could use that mechanism to proxy
messages. Of course, we also designed a proxy-forwarder that could be
used, but that would not be backwards compatible with the
"public@deviceB" approach.

2) The forwarding protocol may or may not be SNMP; the STD62 "proxy
forwarder" is only one type of possible proxy mechanism, one that can
translate between SNMP versions. One could proxy using a "command
responder" application that actually queries a device using non-SNMP
management protocols and reports the result using SNMP. (I think this
is similar to the "observer" role that Dave Perkins mentioned.)

3) an engine could be composed of multiple processor units
(applications) - one could have a contextEngineID that refers to the
processing to be done by an SNMPv1 "command responder" and a different
one for an SNMPv3 "command responder" (and possibly another for an
SNMPv4 command responder, etc.).

These are edge cases, but the SNMPv3 WG thought it important to offer
the flexibility for these and other cases.

Discovery of the contextEngineID can be difficult, especially in the
case of proxy. USM discovers securityEngineIDs using Reports, or
through implementation-defined mechanisms. If we don't need
securityEngineID for SSHSM, we might be able to have a discovery
mechanism that simply GETs the snmpEngineID from the
SNMP-FRAMEWORK-MIB, and is provided in another way for those engines
that don't support the SNMP-FRAMEWORK-MIB. Stay tuned.

David Harrington
[email-masked]

> Sent: Monday, October 03, 2005 12:10 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Isms] contextEngineID
> 
> > > > those who fought for the manager being authoritative for
Informs
> > (of

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 05 Oct 2005 20:12:53 -0700

David H. and Bert asked me to give some background on this because I 
represented one end of a long debate on this issue about 10 years ago.

My point back then was that it is very important for responders to be 
authoritative (as opposed to initiators being authoritative)

In this type of communication, one end is deemed authoritative and 
typically has keys stored in long-term storage. The other end either 
gets the key from a human or has a "cached" copy of the key (I say 
"cached" because in the event the authoritative end says the key is 
wrong, it is simply discarded at which point the usual fallback is to 
prompt the user for the correct key).

We are very accustomed to the situation where the responder is 
authoritative and I guess we don't give it much thought. A transaction 
initiated by a user asks the user for the key and sends it. If the 
responder says the key is wrong, the user is prompted for a new one. If 
the transaction is initiated by unattended software, the key must be cached.

But imagine the case if the initiator was authoritative. Then the 
responder must be the end with the human and/or the cached key. When a 
request arrives at the responder, a human can't react quickly enough to 
a prompt to type the key within the retransmit period so this doesn't 
work (and there may not be a human or the right human sitting at the 
responder anyway). So basically we are forced to cache the key. That's 
not so bad until we ask which keys are we going to cache? Unfortunately, 
one answer is *all of them*. If there are 1000 potential initiators each 
with 10 users, then I have to cache all 10,000 keys because only the 
initiators will know if they ever have any intention of sending me a 
transaction and I need to be prepared in case they do. An alternative is 
to treat it as a provisioning task: when I configure a system to 
initiate transactions, I must load the key into all systems that I plan 
to communicate with which is a burden best avoided. Plus it seems that 
having all of those keys floating around might not be in the best 
interests of security.

To summarize, making the initiator authoritative means either:
- a massive configuration of all possible initiators in all possible 
responders; or,
- an additional, expensive provisioning step for setting up a new 
initiator (or even if I'm just adding a new communications target for an 
existing initiator).

Most apps (email, fileshare, web, ssh) follow the "responder is 
authoritative" model. I can't think of any exceptions.

I haven't been following your discussion so I might be wrong about the 
implications, but it seems to me that the implication is that the notion 
of authoritative is really a snmpv3 notion and not just a USM notion.

Steve

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 7 Oct 2005 19:16:19 +0200

I'm puzzled, on a number of counts, primarily on what authoritative means.

Reading the SNMPv3 RFC, excluding USM, I find the term used as a gloss for
securityEngine ID and that only appears on the ASI of the security model and is
only used, in MPP, on receipt of a Confirmed Class PDU, when
the securityEngineID must match the snmpEngineID else the message is discarded
ie it appears to provide an additional check that the message really got to the
intended engine.

Within USM, it is described as protecting against message replay, delay and
redirection which I see as a problem for USM that SSH takes care of by setting
up a secure tunnel.

This makes me see it as a USM, rather than an SNMPv3, concept.

Another puzzle is your reference to ssh following the "responder is
authoritative" model.  ssh always authenticates the server (with client
authentication as optional); does not this make the initiator authoritative?

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Oct 2005 21:01:59 +0200

> I'm puzzled, on a number of counts, primarily on what authoritative means.

I agree. For me, the context in which you use the work authoritative
is import to understand where we are. In a layered system, one can
talk about:

a) Who is authoritative wrt. the information transported by a
   protocol. Lets call this "information authoritative".

b) Who is authoritative wrt. the keys used in a security protocol.
   Lets call this "key authoritative".

c) Who is authoritative wrt. the clocks used in a security protocol
   Lets call this "clock authoritative".

d) Who is authoritative wrt. to access control decisions. 
   Lets call this "access control authoritative".

In the contact of SNMP, I think the notification originator is
"information authoritative" for Notification Class PDUs while the
command responder is "information authoritative" for Read Class
PDUs. One could argue that the command generator is "information
authoritative" for Write Class PDUs.

Furthermore, it seems rather clear that USM defines clear roles for
the messages containing the various PDU types regarding who is "clock
authoritative". Obviously, this concept is USM specific since the
clock synchronization mechanism is USM specific.

A bit less clear is probably the notion of "key authoritativeness".
In a classic symmetric key protocol, one could argue that both peers
share the same authoritativeness. USM, however, uses localized keys
and one therefore might argue that the authoritativeness is not shared
equally. Still, I consider the question of who is "key authoritative"
a security model specific issue.

Regarding access control, it is rather clean in SNMP that the command
responder and the notification originater are "access control
authoritative".

Perhaps this helps to organize the discussion.

/js

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

---

From: Steve Waldbusser <[email-masked]>
Date: Mon, 10 Oct 2005 11:50:40 -0700

Juergen,

  Yes, it helps a lot. I've been speaking about "key authoritative".

Steve

---

From: Steve Waldbusser <[email-masked]>
Date: Mon, 10 Oct 2005 12:32:17 -0700

>authentication as optional); does not this make the initiator authoritative?
If a ssh connection setup fails because the server couldn't be 
authenticated, it doesn't throw away its keys and try again with a new 
pair. This is true of both the server authentication portion as well as 
the optional client authentication (as well as the typical "plain" 
password).

By "key authoritative", I mean that in the event of an authentication 
failure, the end that is key authoritative keeps its keys while the 
other end is forced to adapt by getting better keys, choosing not to 
communicate, getting the info from elsewhere, etc. And the end that is 
key authoritative better have those keys stored locally or a pretty 
quick means of getting them on demand.

Steve

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 13 Oct 2005 17:48:13 +0200

Juergen

I think I just found another, in the Entity MIB, namely,

"The authoritative contextEngineID that can be used to send
            an SNMP message concerning information held by this logical
            entity, to the address specified by the associated
            'entLogicalTAddress/entLogicalTDomain' pair.

Not sure how widespread a usage this is but it is not what I had in mind, which,
from your typology, is key authoritative.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Oct 2005 23:24:10 +0200

On Thu, Oct 13, 2005 at 05:48:13PM +0200, Tom Petch wrote:

> Not sure how widespread a usage this is but it is not what I had in
> mind, which, from your typology, is key authoritative.

This object belongs to the category "information authoritative" as it
is used to identify the context on an "agent" (called a logical entity
in the ENTITY-MIB terminology) which is authoritative regarding some
information on the "agent".

/js