Re: [Isms] wg last call followup - e-mail address

["tom.petch" <cfinss at dial.pipex.com>]

<inline three times of which the last one matters most to me>

Tom Petch

----- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: <j.schoenwaelder at jacobs-university.de>; "'tom.petch'"
<cfinss at dial.pipex.com>
Cc: "'Jeffrey Hutzelman'" <jhutz at cmu.edu>; <isms at ietf.org>
Sent: Tuesday, March 03, 2009 5:57 PM
Subject: RE: [Isms] wg last call followup - e-mail address


>
>
> > -----Original Message-----
> > From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On
> > Behalf Of Juergen Schoenwaelder
> > Sent: Tuesday, March 03, 2009 10:51 AM
> > To: tom.petch
> > Cc: Jeffrey Hutzelman; isms at ietf.org
> > Subject: Re: [Isms] wg last call followup - e-mail address
> >
> > On Tue, Mar 03, 2009 at 02:27:15PM +0100, tom.petch wrote:
> >

<snip>

> > Sorry, I
> > > But it would be really really helpful if we had consensus
> > on whether this is
> > > acceptable or not.  Wes is the first to say not, Pasi
> > didn't, I sat on the
> > > fence.  If it is unacceptable, I can produce any number of
> > EOPs that fix it, but
> > > I think that producing EOPs and then having to reverse
> > engineer the design and
> > > then to speculate on the requirements is one reason why I
> > am disappointed with
> > > progress.  But you know that:-)  So let's have a design and
> > then the EOPs and a
> > > requirement as well would be lovely.
>
> I agree that it is not obvious why we are doing this, or what the
> implications are, and they need to be spelled out better. Wes and I
> are working on this now.
>
> I think the current discussion is missing the major motivation for
> this - it is not about NOs, it is about SSH. This is the way SSH
> works, and we need to acommodate it. It comes into play mostly with
> NOs, because with NOs, we initiated the session using an SSH user@
> format stroed in a MIB module. It could be used just as well by a CG
> or a proxy application - any application that initiates the SSH
> session.
>
> > > > We need to move this discussion to the concrete text in
> > the documents.
> > > > If we find text that handles this, we are done and can close
> this
> > > > technical issue. If not, we hopefully get closer to know what
> text
> > > > needs to be added where.
> > > >
> > > > So far I understand:
> > > >
> > > > - There should be a better motivation why user at host addresses
> are
> > > >   supported (to make NOs work better).
> > >
> > > Yes please, a requirement, in -tmsm (yes, really).   My
> > less facetious take is
>
> (no, really) - this is a SSH-specific behavior, and belongs in the
> secshell document, not in tsms. It does NOT apply to USM. It may or
> may not apply to other secure transports. And other secure transports
> might use a different format for specifying the transport user to be
> authenticated. This format and its processing is specific to SSH,
> SSHTM, and SnmpSSHDomain addresses.

As in my other response to Dave and Wes, this format of address is in tsm along
with a brief explanation thereof and again, I think it could be of general
architectural use so would put it in tmsm.  I agree that it does not apply to
USM but I do not find that argument persuasive; I suspect that there is much in
tmsm that does not apply to USM, even though the aim is to retrofit a transport
subsystem that is SM neutral.  But the my first aim is to have it somewhere.

>
> Some of your recommended text looks good to me; other parts not. I
> will try to make sure we get an explanation in the (sechell) document
> in a manner that satifies you.
>
> > >
> > > "The transportAddress, as passed by the application may
> > take the form
> > > user at example.com:port
> > > The 'user' part may be used as a user address to establish
> > a transport and then
> > > be used by the remote engine as securityName.  The local
> > engine still uses
> > > securityName; two names are now in use, one for the local
> > engine and the other
> > > for the remote engine.
> > >
> > > The use case for this is when, as with Notifications, the
> > access control check
> > > is performed in the local engine, using the local
> > securityName, as opposed to a
> > > Command Responder when the access control check is
> > performed in the remote
> > > engine, using the name supplied as part of the
> > transportAddress and associated
> > > security credentials."
> > >
> > > I do not think that I have grasped the point of this yet; I
> > well know the
> > > Notification problem but how does this solve it?
> > securityName is never
> > > authenticated so is this a solution?
>
> securityName is not authenticated for an outgoing notification. The

That was a missing brick in the wall for me; I assumed that something was needed
but could never see how so rather lost interest in secure Notifications.
Perhaps worth a mention in Security Considerations.  It is not that the I-Ds say
anything else but that the outcome is not obvious and may come as a surprise to
some.

> MIB that contains data that requires access control is the same MIB
> that contains a MIB module with the securityName to use for access
> control. We have to trust that operators will not put a securityName
> into the Target-mib et al, that is not allowed to send notifications.
> The ACM can be used to finetune which notifications that specified
> securityName can send. The only important decision for ACM is whether
> the securityName-principal is allowed to send notifications with
> specific managed objects in them.
>
> **The intended receiver of the notification is unimportant to access
> control. The address is not a parameter in the ACM subsystem ASI:
>
> statusInformation =              -- success or errorIndication
>      isAccessAllowed(
>      IN   securityModel             -- Security Model in use
>      IN   securityName              -- principal who wants to access
>      IN   securityLevel             -- Level of Security
>      IN   viewType                  -- read, write, or notify view
>      IN   contextName               -- context containing variableName
>      IN   variableName              -- OID for the managed object
>           )
>
> For incoming requests, the securityName represents the principal
> authenticated by the security model (possibly by delegating that
> responsibility to a secure transport model). And that authenticated
> principal is requesting access to the data in the MIB, and we do
> access control on that (principal, request).
>
> For incoming notifications, the securityName represents the
> authenticated principal. SNMP doesn't care very much because we do not
> do access control on incoming notifications.
>
> For RFC3413-proxy, we do not open the PDU, so we do no access control.
> We just forward the PDU as is, based on the administratively
> configured PROXY-MIB.
>
> Some of this discussion should be added to clarify the relationships
> for models like SSHTM.
>
> >
> > I think Jeff pretty much explained why support user at host helps with
> > notifications. The point is that for notifications, access control
> > uses securityName to identify the notification receiver while SSH
> uses
> > the SSH user name to identify the notification sender. In many
> cases,
> > these will not be the same. So the user at host format allows to make
> > this important distinction. Is this understandable? Do you support
> > this motivation? If yes, can the document editors make sure
> > appropriate text is added to the secshell document?
> >
> > > > - We need to make sure that the EoP provide a consistent
> > securityName
> > > >   for SNMP applications using this feature.
> > > >
> > > > Can we please sort this out quickly?
> > >
> > > Wish we could but be aware Juergen that I have a further
> > stack of comments in
> > > this area, since e-mail format (yes Jeff, I know this is
> > not e-mail:-) addresses
> > > have been added.  The EOPs do some odd things and I think
> > that they need
> > > clarifying or changing or both.  But these are the big two,
> > how and why, and if
> > > we agree on them, then the rest becomes clearer for me.
> > >
> > > The others mostly revolve around transport addresses, when
> > the user@ is or is
> > > not there and what then happens
>
> The user@ is present all the way from the application to the transport
> model. The transport model breaks it apart. We need to ensure that it
> is present in the transportAddress passed via the
> (non-tmStateReference) parameters in the ASIs for incoming messages,
> so the MPM can match responses to outstanding requests.

Yes that is what I read in the I-D; what I think could be clearer is 5.1 2)

          tmTransportAddress = the address the message originated from,

which Jeff's e-mail confirms for me means example.com, not the IP address
thereof, not the e-mail format (and without the port?) and which, for the ssh
client, is certainly NOT the address the message originated from but rather the
address that was passed to ssh in openSession.

The new paragraph that comes later starting "(If the session was not opened
locally ..." is the key to understanding this but by the time I get there, other
ideas have been confirmed in my mind by sentences like the one above.  Not an
easy read.

Tom Petch

> The tmStateReference's tmSecurityName needs to reflect the
> authenticated principal (which will not be in the user@ form).
>
> > /js