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

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

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

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