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

["David Harrington" <ietfdbh at comcast.net>]

> -----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:
> 
> > > Wes or DBH, can you point to the exact place in the IDs 
> where this is
> > > described?
> > >
> > By way of contrast, I can point to the logic that says it 
> does, based on my
> > understanding of the wording in the current drafts (either 
> or both of which
> > could be wrong).  And I see a post by Pasi - later echoed 
> by dbh - listing this
> > precise occurrent which reassures me that my reading, 
> sadly, is correct. AFAICT
> > the wording came from Wes and has been accurately 
> incorporated by David into the
> > I-D.
> 
> Sorry, I have trouble to follow...

Wes explained it to me, and wrote the text about the securityName and
address being associated with the session that is opened, and it must
remain consistent. I understood (eventually) and we modified the ID
with Wes's text.

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

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

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

> > 
> > Pushing out another I-D before the deadline is likely, 
> IMHO, to delay things.
> 
> We need to resolve this issue and it better be done quickly. We have
> several days to get this straight. The ISMS WG has been crawling for
a
> too long time and I am not interested in continuing this.
> 
> Tell me whether you understand and agree/disagree with the
motivation
> for the user at host format. Once we have an answer on this, we can
look
> where changes to the EoP are required. And we still have several
days
> for sorting this out.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>