Subject: Re: [Isms] wg last call followup - sshtm openSession

From: "tom.petch" <[email-masked]>
Date: Sun, 1 Mar 2009 12:45:10 +0100

Not sure if this is editorial, I suspect not.

sshtm openSession used to be

   openSession(
   IN   destTransportAddress     -- transport address to be used
   IN   tmSecurityName             -- on behalf of this principal
   IN   maxMessageSize           -- of the sending SNMP entity
    )

and is now

   openSession(
   IN   tmStateReference       -- transport information to be used
   OUT  tmStateReference       -- transport information to be used
   IN   maxMessageSize           -- of the sending SNMP entity
    )

Why the change? That OUT parameter looks strange to me.

Tom Petch

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 26, 2009 8:53 AM
Subject: [Isms] wg last call followup

> On November 4th 2008, I started WG last call on the ISMS document set:
> 
> [1] Transport Subsystem for the Simple Network Management Protocol (SNMP)
>     <draft-ietf-isms-tmsm-15.txt>
> [2] Transport Security Model for SNMP
>     <draft-ietf-isms-transport-security-model-10.txt>
> [3] Secure Shell Transport Model for SNMP
>     <draft-ietf-isms-secshell-13.txt>
> [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple
>     Network Management Protocol (SNMP) Transport Models
>     <draft-ietf-isms-radius-usage-04.txt>
> 
> We received some comments and the subsequent mailing list discussions
> have led to some changes to the ISMS core documents. David just posted
> revised IDs of the core documents:
> 
> [1] Transport Subsystem for the Simple Network Management Protocol (SNMP)
>     <draft-ietf-isms-tmsm-16.txt>
> [2] Transport Security Model for SNMP
>     <draft-ietf-isms-transport-security-model-11.txt>
> [3] Secure Shell Transport Model for SNMP
>     <draft-ietf-isms-secshell-14.txt>

---

From: "tom.petch" <[email-masked]>
Date: Sun, 1 Mar 2009 12:58:40 +0100

This is probably not editorial but I cannot tell.

I commented during the last round time how hard I find it to understand parts of
these I-Ds and a concrete example of this is the e-mail address format we now
have for transportAddress.

Assume I read all of RFC341x, then tmsm, tsm and sshtm and am almost at the end
of my journey of discovery and then I encounter
"      (If the session was not opened locally with a [email-masked]
      formatted tmTransportAddress, ..."

Hang on, what have I missed?  Re-read all the foregoing and I am none the wiser;
this is indeed the first reference.  Why have e-mail format addresses? What
function do they serve?  Reverse engineer the ASI and EOP and I am fairly sure
that they do not work, or more likely I cannot understand the relevant text.  I
thought this when Wes proposed wording for it last month; I waited for the
complete I-Ds before I tried again but am still none the wiser.

I have read every post on this list for years ... but that helps me none.  The
nearest is Jeff saying that this overcomes an asymmetry in SSH.  Well, yes, I
track SSH and understand its asymmetry; and am none the wiser:-(

What I think essential is an expanatory paragraph, much earlier, in tmsm even
(thinking that another transport model might find a use for this) saying eg

"The transportAddress, as passed by the application may take the form
[email-masked]:port
The 'user' part may be used to establish a transport and then be used by the
remote engine as securityName.  The local engine still uses securityName as well
and so has two names, one of which is used somewhere and the other elsewhere
making this specification hard to understand, dysfunctional even.  This
capability meets no known requirement but there is a good reason for it being
present".

Well, you might find a better pair of the last two sentences but after expending
so much effort, I am a tad frustrated at my lack of understanding:-).  I really
would like to understand why we introduced this and how it works.  My current
focus is on a Command Generator as ssh client and the processing of outbound
Request and inbound Response; forget about Command Responders and Notification
engines for the moment.

Wes?
Jeff?
Dave?
Dave?

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 26, 2009 8:53 AM
Subject: [Isms] wg last call followup

> Please take a look at the changes. Let us know by March 6th if there
> are any major technical problems with the changes that must be fixed
> before submitting the documents to the AD for publication.  Please
> keep in mind that we are going for Proposed Standard, the entry-level
> maturity level for the standards track.
>
> If you find editorial issues, please report them clearly marked as
> editorial issues.
>
> /js

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 01 Mar 2009 08:20:04 -0500

--On Saturday, February 28, 2009 08:45:09 PM +0100 "tom.petch" 
<[email-masked]> wrote:

> I am still struggling with the 'Pasi problem' that he raised last
> November and although I recall seeing a message from him that he was
> satisfied, I cannot understand how it works in the current I-Ds; I cannot
> understand part of the I-Ds so tell me first what is meant to happen.
>
> Suppose securityName is alice and transport address is [email-masked]:ssh
> in a Command Generator.
>
> For a Request, sshtm passes bob to SSH and that is used for the session
> setup as per s5.3 3 1.  The Command Responder uses bob for access control
> etc.  The response will come back, SSH will pass a name of bob (s5.1 2)
> to stm as a securityName via tmStateReference which will pass it on to
> tsm which may or may not prefix it (s5.2 3) and then it will get passed
> to the application.
>
> So the application specified alice and got back bob.
>
> Is this how it is meant to work?

That won't happen.  In your scenario, the CR does not "use bob for access 
control".  TSM compares the name reported by SSH (bob) with the 
securityName in the SNMP message, and when they don't match, rejects the 
request.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 01 Mar 2009 08:35:42 -0500

--On Sunday, March 01, 2009 12:58:40 PM +0100 "tom.petch" 
<[email-masked]> wrote:

> What I think essential is an expanatory paragraph, much earlier, in tmsm
> even (thinking that another transport model might find a use for this)
> saying eg
>
> The 'user' part may be used to establish a transport and then be used by
> the remote engine as securityName.  The local engine still uses
> securityName as well and so has two names, one of which is used somewhere
> and the other elsewhere making this specification hard to understand,
> dysfunctional even.  This capability meets no known requirement but there
> is a good reason for it being present".

Well, we're not going to have a paragraph like that, because it takes 
totally the wrong tone.  The feature is present because it _does_ need a 
requirement and is needed.  But yes, there should be a paragraph describing 
the transport address format; I'm surprised if that's not in there.

> Well, you might find a better pair of the last two sentences but after
> expending so much effort, I am a tad frustrated at my lack of
> understanding:-).  I really would like to understand why we introduced
> this and how it works.  My current focus is on a Command Generator as ssh
> client and the processing of outbound Request and inbound Response;
> forget about Command Responders and Notification engines for the moment.

Then you're not going to understand, because it's not intended for that use 
case.  It's specfically for the case of a Notification Originator as an SSH 
client, where the SNMP securityName names the recipient of the 
notification, not the originator.  In this case, using the securityName as 
the SSH username is almost certainly the _wrong_ thing to do, and the 
user@host transport address format provides a way to specify the correct 
username (which in fact likely has nothing to do with any other identity 
that SNMP knows about).

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Sun, 1 Mar 2009 08:58:24 -0500

Whoa!!!!!!

There is NO securityName in the message. 
Where do you think the message contains a securityname?

IN 4.2, TSM 
   3) Set securityParameters to a zero-length OCTET STRING ('0400').

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jeffrey Hutzelman
> Sent: Sunday, March 01, 2009 8:20 AM
> To: tom.petch; Juergen Schoenwaelder; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] wg last call followup - sshtm
> 
[...]
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 01 Mar 2009 09:04:33 -0500

>    3) Set securityParameters to a zero-length OCTET STRING ('0400').

OK; I haven't had much sleep, so maybe my memory is wrong, and I certainly 
need to go back and re-read the draft.  But, I think it is essential to 
actually transport the security name and level in the SNMP message, and for 
TSM to verify that they are the saem.  Otherwise, among other things, you 
can run into the situation Tom describes, where the two ends disagree on 
what the securityName is.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Sun, 1 Mar 2009 09:30:06 -0500

H Jeff,

I am finding some inaccuracies in your statements. Please check the
drafts before making statements, please, so we do not get off into the
weeds.

inline. 

> Sent: Sunday, March 01, 2009 8:36 AM
> Subject: Re: [Isms] wg last call followup - e-mail address
> 
> > What I think essential is an expanatory paragraph, much 
> earlier, 

agreed.
The definition of the format is in the MIB. An exlanatory paragraph
earlier would be helpful. I didn't realize we didn't have it discussed
adequately.

> in tmsm

this is specific to SnmpSSHDomain and SnmpSSHAddress
The only transport model that should process SnmpSSHDomain is the
SSHTM.

> the transport address format; I'm surprised if that's not in there.

If you had looked, you would have found it in the MIB.

> notification, not the originator.  

I think that is a misstatement. Per RFC3411 modularity, any
application should be able to use that format of domain/address. A CG
could use this format just as well as a NO can. The proxy application
defined in RFC3413 should be able to use this format just as well as a
NO. 

> In this case, using the 
> securityName as

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 01 Mar 2009 09:48:22 -0500

> If you had looked, you would have found it in the MIB.

Hrm.  I didn't look, only because I figured Tom had, and if he couldn't 
find it, then perhaps we haven't said it prominently enough.

> defined in RFC3413 should be able to use this format just as well as a

It's _intended_ for the case I described, where deriving the SSH username 
from the SNMP securityName is likely to produce the wrong answer.  In the 
case of a CG, deriving the SSH username from the SNMP securityName probably 
will produce the correct answer, so the user@host address format is much 
less likely to be used by a CG.  But you're right; that doesn't mean it 
_can't_ be used by a CG.

Nonetheless, I think my previous statement is true -- an NO is the use case 
for the user@host address format, so it's difficult to understand why it is 
useful without considering that case.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Sun, 1 Mar 2009 09:58:53 -0500

Hi,

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Sunday, March 01, 2009 9:05 AM
> To: David Harrington; 'tom.petch'; 'Juergen Schoenwaelder'; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isms] wg last call followup - sshtm
> 
> TSM to verify that they are the saem.  

The securityLevel and securityModel are transported in the message,
and the specified securityModel will (presumably, but definitely in
the case of USM and TSM) verify the securityLevel is at least as
strong as specified in the message.

securityName, on the other hand, is a security-model-dependent
parameter, and only exist sin the message if the sending TSM includes
it in the message, and presumably the incoming TSM processes it. For
USM, it is included because USM authenticates that securityname. In
TSM, it is not included because TSM relies on the transport model to
provide a proposed securityname in the tmSecurityName. TSM does not
validate the tmSecurityName at all; it accepts it as being the
securityName for subsequent use for access control for the associated
incoming message.

For SSH, the two sides do not have to agree on the same securityName.
The principal known as alice in snmp entity#1 might be known as bob in
snmp entity#2. The securityname is a local construct. I don't think
that was the intenrtion of the SNMPv3 WG, but the asymmetric nature of
SSH has forced it to be so, and the RFC34xx do not seem to require
that it be so (despite my expectations).

Basically, if the MIB information being sent in a message is from a
local MIB, then verify that the local securityName is allowed to send
the data. There are three current applications that send data from the
local MIB -

1) NO - the securityName used for access control is a prinsipal known
tot he local system, via the NOTIFY-MIB, for example. ACM verifies
that the local principal is allowed to send data off the box. It does
not matter to whom it is being sent; either they are allowed to send
the data or not. 

2) CR - the securityName used for ACM is based on the principal that
was authenticated during the receipt of the message. If
[email-masked] was authneticated by SSHTM, and SSHTM sets
tmSecurityName to "bob" as a result (or to fred, or to barney, or to
[email-masked]), then the value passed by SSHTM in tmSecurityName
becomes securityName, and ACM uses that securityName.

3) proxy - I have not checked this thoroughly, but the information
passed to the proxy application for an incoming message should be the
same as what would be passed to a CR for an incoming message. The
information used for an outgoing message comes from the the proxy-mib
(and associated mibs) just like in the NO case. In some instances, the
same tabl;es are used for transportdomain/address and security
parameters as the NO use case. 

The proxy use case is important if, say, SNMPv1 security model is used
within an enterprise network, but USM is used to send SNMP data over
the Internet. The router that separates the enterpise network form the
Internet might act as the proxy. Proxy could be used if the enterprise
network used USM security model, and SSHTM+TSM was used to forward
SNMP messages over the Internet.

> Otherwise, among other 
> things, you

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 01 Mar 2009 11:25:52 -0500

--On Sunday, March 01, 2009 09:58:53 AM -0500 David Harrington 
<[email-masked]> wrote:

> The securityLevel and securityModel are transported in the message...
> securityName, on the other hand, is a security-model-dependent...
> For SSH, the two sides do not have to agree on the same securityName...

I'm still short on sleep, but this sounds sane to me, and I'm fairly 
convinced there is not a problem -- as long as we believe it's OK that the 
two parties to a transation might not use the same securityName.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Sun, 1 Mar 2009 21:04:05 +0100

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "David Harrington" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 01, 2009 3:48 PM
Subject: Re: [Isms] wg last call followup - e-mail address

> useful without considering that case.

Jeff

I am sorry if you found my facetiousness offensive.  It has been over three
years for me, trying to make sense of the mappings, and being convinced with
each successive I-D that either it will not work or I cannot understand it or
...

My point was not that there is not some more information about e-mail format
addresses, but that the text I quote is the first anyone will ever hear about it
if they read the SNMPv3 documents in a sensible order.  And as an introduction,
that sentence is dire (IMO).  The later sentences flesh out the format, the
implementation detail if you like, but there is no statement anywhere of why
this complication is introduced especially as this feature brings fresh
problems, as all the mappings we have had have done.  In particular, it creates
the 'Pasi problem', Command Generator sends a Request with securityName of
Alice, gets a Reponse with securityName of Bob.  Pasi described it as
surprising.  I say unacceptable.  And that is why I specified this scenario in
my other post.  By all means explain that it solves an NO problem - well I think
that that is essential - but if the solution leads to unacceptable results with
CR/CG, then our job is not done.

I say that a paragraph is needed saying what the problem is with NO and how this
solves it ie requirements and design, to me the foundation of my practice as an
engineer.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Sun, 1 Mar 2009 21:04:37 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Jeffrey Hutzelman'" <[email-masked]>; "'tom.petch'"
<[email-masked]>; "'Juergen Schoenwaelder'"
<[email-masked]>; <[email-masked]>
Sent: Sunday, March 01, 2009 3:58 PM
Subject: RE: [Isms] wg last call followup - sshtm

> SNMP messages over the Internet.

David

I agree but my concern is the one Pasi expressed, that in the Command Generator,
the application will send a Request with securityName of alice and the Response
within the Command Generator (forget CR, that I do not have a problem with) will
have a securityName of bob.  Pasi called it surprising, I would suggest
unacceptable, and in need either of preventing or of warning people of the
consequences.

And I think we also need a warning that the two engines can have different views
of securityName, I think that that is not something to be expected from the
RFC341x series.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Sun, 1 Mar 2009 21:17:06 -0500

Hi,

I have the same concerns. I feel very uneasy about this.

I think that the way to resolve it is to have sshtm record the
SnmpSSHAddress and the tmSecurityName for outgoing messages, and match
them up to incoming messages. If the principal identity matches the
user part of an SnmpSSHAddress in email format, and that is different
than the tmSecurityName used with that transport adddress for the
outgoing message, then use the tmSecurityName that was used for the
corresponding outgoing message.

If we send the message to "[email-masked]", then I presume the
response will come back from "bob" at remote.com's address. However,
we might have used a domain address (remote.org) on the outgoing, I am
not sure whether we get a response from remote.org or from <10.1.9.34>
(an address that remote.org resolves to).

I have documented the elemts of procedure as well as I can given my
current understanding.

dbh

> From: tom.petch [mailto:[email-masked]] 
> Sent: Sunday, March 01, 2009 3:05 PM
> To: David Harrington; 'Jeffrey Hutzelman'; 'Juergen 
> Schoenwaelder'; [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 13:25:30 -0500

--On Sunday, March 01, 2009 09:17:06 PM -0500 David Harrington 
<[email-masked]> wrote:

> response will come back from "bob" at remote.com's address.

NONONO.  If we send the message to "[email-masked]", then we are sending 
the message to the host remote.org, and using "bob" as _our_ SSH username 
for use in authenticating to that host.  It is _not_ an email address, and 
"bob" is not the name of the agent we're sending to.  It is the name the 
agent we're sending to (actually, the SSH server we're connecting to) uses 
to describe _us_.

If we send a message...

... the response will come back _over the same ssh session_.  Period.
We don't get a response back from a particular IP address or hostname or 
user.  We get a response back over the channel _we_ opened.  This is 
exactly what tmSameSecurity is fore.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 2 Mar 2009 14:32:47 -0500

Alright, let me write up some introductory text that describes this.
IIRC, I think I already edited the EOP to reflect this, based on Wes's
comments.

dbh

> Sent: Monday, March 02, 2009 1:26 PM

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 02 Mar 2009 11:48:28 -0800

>>>>> On Mon, 02 Mar 2009 13:25:30 -0500, Jeffrey Hutzelman <[email-masked]> said:

This is the important part that everyone needs to understand.  I'm sort
of confused why we're rehashing stuff that was long ago discussed and
even agreed upon (I thought by a fairly big majority of the people!).

JH> ... the response will come back _over the same ssh session_.  Period.
JH> We don't get a response back from a particular IP address or hostname
JH> or user.  We get a response back over the channel _we_ opened.  This
JH> is exactly what tmSameSecurity is fore.

Stream based transports like SSH or even DTLS (which is defining a
cryptographic stream, even if it's not a packet based stream like a TCP
stream) performs things in an order:

  1) start up the stream, sharing and negotiating information like
     certificates, names, passwords, options, etc.

     Alice <----  ----> Bob

     The result of this negotiation is almost always some sort of "handle"
     and in most implementations is a file-descriptor socket at the heart
     of it all (IE, an integer number identifying the stream to the
     kernel/what-have-you).

  2) Send traffic through the stream.  It's important to note that pretty
     much every protocol *does not send the user name /etc again*.  It'd
     be highly redundant to keep sending messages saying "oh, and this is
     from Bob again".  The stream user on one side is expected to know
     that already (regardless of whether they initiated or accepted the
     connection).

  3) close the connection upon request

For the SSHTM we just recently added wording (I thought; I have yet to
check the new draft) that basically says that the tmSecurityName needs
to be cached/consistent during the life of a session.  That way when
Alice sends a first message with a securityName of "alice" but that says
"open [email-masked]" where bob@ is the SshTransportAddress convention,
alice's stack remembers that "alice" is the security name for the
lifetime of the session on our end.  When it gets *any* messages from
the other side, it passes up "alice" as the tmSecurityName in the
upward-bound traveling tmStateReference.

If alice didn't want it this way and actually wanted "bob" to be
securityName, she would have set the initial tmStateRerence's
tmSecurityName correctly.  It'd be *her* fault for not tying them
together.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 02 Mar 2009 11:49:43 -0800

>>>>> On Sun, 1 Mar 2009 21:17:06 -0500, "David Harrington" <[email-masked]> said:

DH> I think that the way to resolve it is to have sshtm record the
DH> SnmpSSHAddress and the tmSecurityName for outgoing messages, and match
DH> them up to incoming messages.

I don't think you need to cache the address.  And I thought a recent
patch had required we cache the securityName (I forcefully say this is
the DTLS draft).

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 02 Mar 2009 11:50:17 -0800

>>>>> On Sun, 01 Mar 2009 11:25:52 -0500, Jeffrey Hutzelman <[email-masked]> said:

JH> I'm still short on sleep, but this sounds sane to me, and I'm fairly
JH> convinced there is not a problem -- as long as we believe it's OK that
JH> the two parties to a transation might not use the same securityName.

Which, I'll say again: we already agreed upon as a WG that it was OK.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 02 Mar 2009 11:55:50 -0800

>>>>> On Sun, 1 Mar 2009 21:04:05 +0100, "tom.petch" <[email-masked]> said:

tp> In particular, it creates the 'Pasi problem', Command Generator
tp> sends a Request with securityName of Alice, gets a Reponse with
tp> securityName of Bob.

No!  That never happens.  A CG that opens a request with a securityName
of "Alice" but a transport address of "[email-masked]" will get back a
securityName of "Alice", ***NOT*** Bob.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Mar 2009 09:37:53 +0100

> securityName of "Alice", ***NOT*** Bob.

Wes or DBH, can you point to the exact place in the IDs where this is
described?

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@host addresses are
  supported (to make NOs work better).

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

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 Mar 2009 06:27:59 -0800

>>>>> On Tue, 3 Mar 2009 09:37:53 +0100, Juergen Schoenwaelder <[email-masked]> said:

WH> No!  That never happens.  A CG that opens a request with a securityName
WH> of "Alice" but a transport address of "[email-masked]" will get back a
WH> securityName of "Alice", ***NOT*** Bob.

JS> Wes or DBH, can you point to the exact place in the IDs where this is
JS> described?

If you'll look at the other message I sent (Subject: "security name
relevant text from the current SSH draft and needed changes"), I listed
the text where it sort-of-ish says the above.  I also suggested that the
text needs to be changed and suggested the beginnings of that text.
Jeff agreed with me.  Read the logical steps in that and if it's agreed
that's what we meant, then we should change the wording to reflect that
so we can move on.

JS> - There should be a better motivation why user@host addresses are
JS> supported (to make NOs work better).

I'm not sure how much we need to concentrate on documenting motivations
for each small item.  But putting such text in wouldn't hurt.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 14:27:15 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>
Cc: "tom.petch" <[email-masked]>; <[email-masked]>; "Jeffrey Hutzelman"
<[email-masked]>
Sent: Tuesday, March 03, 2009 9:37 AM
Subject: Re: [Isms] wg last call followup - e-mail address

> Wes or DBH, can you point to the exact place in the IDs where this is
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.

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.

>   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
[email-masked]: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?

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

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 14:58:09 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; "'tom.petch'"
<[email-masked]>; "'Juergen Schoenwaelder'"
<[email-masked]>; <[email-masked]>
Sent: Monday, March 02, 2009 8:50 PM
Subject: Re: wg last call followup - sshtm

> Which, I'll say again: we already agreed upon as a WG that it was OK.

Weell, I was asleep at the time:-(  I am confident that it was never called out
as an issue and rough consensus declared, that I would have noticed.  May be it
was at an IETF meeting, I am rarely at those.

Whatever, I am not against it, just need to clear we have rough consensus on it.
In which case, it demands a mention in the architecture, ie tmsm, since I expect
it to be a surprise to some users of this.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 15:05:00 +0100

Wes

You probably have the text in sshtm s.5.2 4) 2) in mind which, unlike this
e-mail, makes no mention of caching the tmSecurityName. Hence the problem. alice
is not recorded anywhere and so cannot be presented to the application with the
Response message.

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; "'tom.petch'"
<[email-masked]>; "'Juergen Schoenwaelder'"
<[email-masked]>; <[email-masked]>
Sent: Monday, March 02, 2009 8:48 PM
Subject: Re: wg last call followup - sshtm

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Mar 2009 16:50:50 +0100

> the wording came from Wes and has been accurately incorporated by David into the

Sorry, I have trouble to follow...
 
> authenticated so is this a solution?

I think Jeff pretty much explained why support user@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@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?

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 Mar 2009 08:16:36 -0800

It was heavily discussed in Dublin and on the mailing list prior to
Dublin (and I thought afterward too, but I'm not positive).

tp> In which case, it demands a mention in the architecture, ie tmsm,
tp> since I expect it to be a surprise to some users of this.

It is a SSH specific thing.  It does not relate to every possible TM and
thus doesn't belong in TMSM.  For example, the DTLS draft I've placed in
the repository doesn't make use of the convention.  It's specific to the
SSHTM's address TC.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Dave Shield <[email-masked]>
Date: Tue, 3 Mar 2009 16:30:37 +0000

2009/3/3 Wes Hardaker <[email-masked]>:
> It is a SSH specific thing.

Is it inherently specific to *just* SSH?
Or might it conceivably be relevant to
some other secure transports as well?

>  It does not relate to every possible TM and
> thus doesn't belong in TMSM.

That doesn't necessarily follow.
If it's only ever going to apply to SSH (and not to any other possible TM),
then I'd agree - this belongs in the SSH draft (and nowhere else).

But if a similar situation could potentially arise in some other TMs,
then it's worth briefly covering the basic principles in TMSM (while
mentioning that this may not be relevant to all TMs)

The detailed syntax of how (and whether) a particular TM
can specify this information obviously belongs in the specs
for that individual TM.  But if it's likely to arise in more than
one TM, then it doesn't feel unreasonable to prepare the ground
in the overview document.

Dave

Disclaimer:  I haven't actually read the last couple of drafts yet.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 3 Mar 2009 11:57:16 -0500

> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, March 03, 2009 10:51 AM
> To: tom.petch
> Cc: Jeffrey Hutzelman; [email-masked]

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.

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

> > Yes please, a requirement, in -tmsm (yes, really).   My 

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

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

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 3 Mar 2009 12:15:34 -0500

Hi,

Actually, I think it is incorrect to say that no mention is made of
caching the tmSecurityName. 

The openSession takes a tmStateReference that already contains a
tmSecurityName, and openSession adds the corresponding tmSessionID to
the tmStateReference cache. This binds the tmTransportAddress and the
tmSecurityName and the tmSessionID together.

When a response is received, it will be received over the existing
session. And by looking up the tmSessionID, we find both the
corresponding tmSecurityName and the correspnding "user@"
transportAddress to pass up the stack. 

Apparently you didn't find that obvious ;-) 

We'll try to make it more obvious.

> Sent: Tuesday, March 03, 2009 9:05 AM
> To: Wes Hardaker; Jeffrey Hutzelman
> Cc: David Harrington; 'Juergen Schoenwaelder'; [email-masked]
> > >>>>> On Mon, 02 Mar 2009 13:25:30 -0500, Jeffrey Hutzelman 
> <[email-masked]>
> said:
> >

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 Mar 2009 09:19:00 -0800

>>>>> On Tue, 3 Mar 2009 16:30:37 +0000, Dave Shield <[email-masked]> said:

>> It is a SSH specific thing.

DS> Is it inherently specific to *just* SSH?
DS> Or might it conceivably be relevant to
DS> some other secure transports as well?

It may be.  But the TMSM doc is relevant to them all.  It's a design
decision to be made per-transport.  And it greatly depends on the
architecture of the transport address.

Now, on the other hand asymmetric identities is something that is likely
to be common to most modern transports (including DTLS, but the details
are quite different).  Talking about that aspect generically certainly
could go into the TSMS draft if we wanted to slow things down even
further.  I, personally, think the draft is good enough for a proposed
standard as is and we can decide to fluff it up further for draft status
if it's needed.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 15:08:55 -0500

> standard as is and we can decide to fluff it up further for draft status

I agree.  Let's avoid premature generalization here.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 20:10:31 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Wes Hardaker'"
<[email-masked]>; "'Jeffrey Hutzelman'" <[email-masked]>
Cc: "'Juergen Schoenwaelder'" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, March 03, 2009 6:15 PM
Subject: RE: wg last call followup - sshtm

> Apparently you didn't find that obvious ;-)

Well now, you can if you have a session cache whose entries remain invariant for
the duration of the session.  Which is not what the I-Ds currently say to me.
5.1 2) says create a tmStateReference cache and that is now the thrust, that a
tmStateReference cache entry is created per inbound message and only lasts for
the duration of the transaction as opposed to a cache entry that is per session
and lasts for the duration of the session.  I think that such a cache must now
exist but see it as too much of a stretch to read that meaning into the current
text.  We are, I hope, writing this for those who have not spent five years
working on it.

Recall too that in November you said .
"The sessionID field that is contained in the tmState is used for one
and only one purpose - to match corresponding request and response
sessions to ensure sameSecurity. It is never used for any other
purpose. And it is opaque to the security model."

So I am now proposing - see another of my e-mails - a different use for
tmSessionID, that it is used as a session identifier between sshtm and ssh in a
Command Generator so as to match the request and response sessions, nothing to
do with sameSecurity in a Command Responder.

Also note that s.3 says
" SSH sessions are uniquely identified within the SSH Transport Model
   by the combination of tmTransportAddress and tmSecurityName
   associated with each session."
and this must now mean except when sessions are uniquely identified by
tmSessionID so I have a sentence to add there as well to the effect that there
must be a one-to-one correspondence between the unique
tmTransportAddress+tmSecurityName and the unique tmSessionId.

And as I already asked, why has openSession  been changed to

   statusInformation =
   openSession(

Or is this the obvious statement that the three parameters are cached
together:-)

Tom Petch
> > Subject: Re: wg last call followup - sshtm
<snip>

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 18:47:27 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "Dave Shield" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 03, 2009 6:19 PM
Subject: Re: [Isms] wg last call followup - sshtm

Wes

Look in tsm and you will find the e-mail format address there along with a brief
explanation of what it is about.  You might not find it at first, but it is
there so it is not just in the sshtm I-D.

And what it is about is having different securityName in sender and receiver
which to me is a change to the architecture.  I would have thought that RFC341x
precluded it somewhere, but, like dbh, I cannot see anything to stop us.  But I
do see it as different enough to need documenting, and tmsm is the place to make
architectural comments.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 20:41:36 +0100

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

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>
Cc: "'Jeffrey Hutzelman'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 03, 2009 5:57 PM
Subject: RE: [Isms] wg last call followup - e-mail address

<snip>

> > Sorry, I

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.

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

> 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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 Mar 2009 13:25:43 -0800

>>>>> On Tue, 3 Mar 2009 18:47:27 +0100, "tom.petch" <[email-masked]> said:
tp> And what it is about is having different securityName in sender and
tp> receiver which to me is a change to the architecture.  I would have
tp> thought that RFC341x precluded it somewhere, but, like dbh, I cannot
tp> see anything to stop us.  But I do see it as different enough to
tp> need documenting, and tmsm is the place to make architectural
tp> comments.

In USM the securityName is explicitly passed and thus is the same on
both sides.  341x would be broken if it specified they had to be
identical on both sides, because it would prevent us from doing useful
things like we're doing today.

For SSHTM it actually turns out that the user name presented by ssh can
be useful in deriving a tmSecurityName.

If you look at the slides I presented in Dublin about the DTLSTM, you'll
see it discusses why this isn't as straight forward for DTLS and the
mappings are quite a bit more complex because DTLS doesn't hand a
principal name to the infrastructure (it only hands a certificate which
fields that are potentially much larger than a usable securityName).

All that being said, I actually don't object to wording be added that
much.  But I don't think it's needed, and I don't think it's important
from an interoperability point of view.  I do think it will slow down
the progress of these drafts which have been worked on for way too long
and the ADs are rightfully pushing the WG to complete.

If you wish to add text to the document I strongly suggest you propose
the text and identify where it should go immediately so we can consider
it.  If no one is willing to propose text then I don't think it should
hold up the documents because it's not a "technical" problem.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Mar 2009 23:31:06 +0100

On Tue, Mar 03, 2009 at 06:47:27PM +0100, tom.petch wrote:
 
> Look in tsm and you will find the e-mail format address there along
> with a brief explanation of what it is about.  You might not find it
> at first, but it is there so it is not just in the sshtm I-D.

Can you please tell us where? It helps me a lot if people try to be
explicit.

> And what it is about is having different securityName in sender and
> receiver which to me is a change to the architecture.  I would have
> thought that RFC341x precluded it somewhere, but, like dbh, I cannot
> see anything to stop us.  But I do see it as different enough to
> need documenting, and tmsm is the place to make architectural
> comments.

[Speaking as technical contributor.]

Since RFC3411 is silent about this (or RFC341x if you want), it can't
be a change of the architecture. I also believe the user@host feature
should be SSH transport specific at this point in time. 

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 3 Mar 2009 19:10:19 -0500

Hi,

I was totally confused by this whole thing myself. Then, to answer a
question from Joe, I researched it fairly thorughly through the
RFC341x series and realized my whole understanding was wrong, and then
explained it to Joe, who finally understood it. Now Tom has a problem.
(And I still slip into my old understanding and have to remember this
new approach). I expect that most operators will have an understanding
similar to my original understanding, which I think was the original
intention of the SNMPv3 WG. I think we are turning things on their
head here, and we better be sure operators understand.

Just to put some reality into this, I suspect the documents have lots
of places where the text is inconsistent as the result of this user@
usage. 

An example is the usage in the examples in TSM:
   The following example will configure the Notification Originator to
   send informs to a Notification Receiver at [email-masked]:PPP
   using the securityName "alice". "alice" is the name for the
recipient
   from the standpoint of the notification originator, and is used for
   processing access controls before sending a notification."rtr-nyc4"
   is the name for the recipient from the standpoint of the
notification
   receiver.

alice is actually the sender, not the recipient. That one obviously
slipped by.

I think it is unrealistic to expect that we will have this all sorted
out, and find all the incorrect usages, by the end of this week. I do
not expect to have another revision by deadline. If Wes or Joe are
available and in a masochistic mood, maybe they'll get another
revision done.

The next revision we publish will have to explain this whole thing
better so we are all on the same page (see there is a benefit to only
having 6 people in the WG; imagine the difficulty if more had to be on
the same page). Text welcome. Then we can really start to
fine-tooth-comb these documents for inconsistencies.

dbh

> Sent: Tuesday, March 03, 2009 5:31 PM
> To: tom.petch
> Cc: [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Tue, 3 Mar 2009 19:21:07 -0500

Hi Tom, 

> the duration of the session.  Which is not what the I-Ds 

Hmmm. Is it the odd-numbered or even-numbered drafts that always have
the MIB reappear?

> text.  

I think it is one of the many "implementation-dependent" cop-outs.

> We are, I hope, writing this for those who have not 
> spent five years
> working on it.

If we work on it a bit longer, maybe SNMP will be declared Historic
and we can all go home.

> purpose. And it is opaque to the security model."

I was lost and now I'm found.
Yup, we'll have to clean up those types of statements in the text.

> do with sameSecurity in a Command Responder.

Yup.

> tmTransportAddress+tmSecurityName and the unique tmSessionId.

Uh. maybe. I'm tired. I'll need sleep before concurring with this.

> Or is this the obvious statement that the three parameters are
cached

Yup. The EOP gets hard to read (grin) if we pass individual parameters
in this interface.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Mar 2009 08:24:22 +0100

> head here, and we better be sure operators understand.

The operators I know quite well how to use SSHs user@host notation and
only few worry about SNMP's _an_ architecture.

> available and in a masochistic mood, maybe they'll get another

[chair hat on]

If it is not possible to sort this out by Monday, I expect that this
will be resolved via email between the ID cutoff and the IETF meeting.
This WG has a tendency to defer things to the next IETF meeting and
during the WG meeting people figure out that working on the details of
the text in the documents is too difficult and should be done after
the IETF meeting.  We need to break this cycle. The ID repository
opens up again when the IETF meeting starts and I like to have
documents posted at that time latest that have all technical issues
resolved (and so far it seems the user@host notation is the only thing
left).

/js

---

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Mar 2009 12:45:59 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>
Sent: Wednesday, March 04, 2009 1:10 AM
Subject: RE: [Isms] wg last call followup - sshtm

> alice is actually the sender, not the recipient. That one obviously

David,

Actually, I see this one as ok:-)  It tells me that there is a recipient and
that the identifier for that recipient has two values, one, alice is used in the
NO, the other, rtr-nyc4, is used in the NR.  Well, ok as in correct, less ok as
in is it easy to read and understand.  I mentally duplicate that text replacing
recipient with originator and that is also ok ie I import the Architecture/USM
thinking that a transaction has one principal only now we use two different
identifiers for that principal, one in NO, the other in NR.

Whereas, as I say in my e-mail to Juergen, I cannot get the right meaning out of
the e-mail he posted yesterday.

"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@host format allows to make
this important distinction. Is this understandable?"

That does seem back to front to me but perhaps there is a reading of that that I
am missing.

Tom Petch

<snip>

---

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Mar 2009 13:53:28 +0100

Juergen

Apologies for being coy.

I had just said that if you read the documents in a logical order (RFC341x tmsm
tsm sshtm), then the statement I flagged in sshtm 5.1 2) is the first a reader
will encounter of this format and for me that, is too late.  Having it in the
sshtmTC (as Wes pointed out) is also inadequate IMHO.  As dbh has now pointed
out, I was alluding to the appendix in tsm which, being an appendix, I also see
as inadequate; I would not expect to read the appendices on my first pass
through the document set:-(.

In this instance, the information is there, but boy, do I have to work to find
it.  Placing that 'first encounter' in sshtm s.3 and rewording it slightly makes
a world of difference to the ease of understanding for me.

I would also reword 5.1 2) which says

either 'If the session was not opened locally with a [email-masked] ...'.

or 'If  the session is a client session, and openSession used  a
tmTransportAddress of the "[email-masked]" format'

which forces me to stop and think, are there other alternatives?; maybe there
are, so what happens then?.

By contrast, having
'If the session is a client session and openSession used a tmTransport Address
of the [email-masked]:port''
against
'In all other cases, ...'

well, I find that so much clearer.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Wes Hardaker" <[email-masked]>; "Dave Shield"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 03, 2009 11:31 PM
Subject: Re: [Isms] wg last call followup - sshtm

---

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Mar 2009 13:59:09 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: "'tom.petch'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 04, 2009 8:24 AM
Subject: Re: [Isms] wg last call followup - sshtm

> only few worry about SNMP's _an_ architecture.

Yes, and that is a concern for me.  When user@host was first mooted, I recall a
comment, Jeff I think, that this format was a commonplace in ssh. This means
that people will have expectations which isms may or may not meet. I do not know
what those expectations are.  I have trawled the documentation of various
manufacturers - eg Cisco, Juniper - for what they can do with ssh and see no
reference to it.  This does not surprise me, I probably need an programmer's
guide with ssh APIs in it, not the sort of thing Cisco would put on its web
site.  Doubtless such a thing is available in a toolkit for Linux but that is
not an area I am comfortable in.

So instead I want a little more clarity in our documentation so that those
coming from an ssh background with an intimate knowledge of what user@host will
do for them, can see whether or not we do what they expect.

Note too that yesterday, you said

Understandable yes, but this appears to be the exact opposite of my current
thinking.  I think that securityName identifies the principal in the
notification sender/originator and SSH user name identifies the principal  in
the notification receiver.

Which way round is going to be the expectation of all those SSH experts?

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Mar 2009 10:28:02 -0500

Hi, 

> only few worry about SNMP's _an_ architecture.

Agreed. But SNMPv3 was designed with a rather symmetric model of
security, and we need to be sure to verify that assumptions of that
model do not permeate our documents, such as that the securityName for
notifications gets authenticated. I may have allowed some to slip in
that i should not have, and we need to be sure others who make similar
assumptions are straightened out by our clear and unambiguous text.
 
> will be resolved via email between the ID cutoff and the IETF
meeting.

I am not sure there is much left to sort out. I think there is
significant work in modifying the document. And I have competing
priorities for this week. Assuming my other priorities do not use all
my time, I expect that we can get a new revision done before the IETF
meeting.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Mar 2009 16:40:22 +0100

On Wed, Mar 04, 2009 at 01:59:09PM +0100, tom.petch wrote:

> Yes, and that is a concern for me.  When user@host was first mooted,
> I recall a comment, Jeff I think, that this format was a commonplace
> in ssh. This means that people will have expectations which isms may
> or may not meet. I do not know what those expectations are.  I have
> trawled the documentation of various manufacturers - eg Cisco,
> Juniper - for what they can do with ssh and see no reference to it.
> This does not surprise me, I probably need an programmer's guide
> with ssh APIs in it, not the sort of thing Cisco would put on its
> web site.  Doubtless such a thing is available in a toolkit for
> Linux but that is not an area I am comfortable in.
>
> So instead I want a little more clarity in our documentation so that
> those coming from an ssh background with an intimate knowledge of
> what user@host will do for them, can see whether or not we do what
> they expect.

Take your average Unix system and do 'man ssh' and the user@host
syntax pops up immediately. On Windows, you find graphical clients
that tend to ask for

     Host:
     User:
     Password:

and this is the same thing in a GUI. Since this is a client issue, the
Cisco's of the world probably do not spend much effort documenting
this (but I actually did find screenshots on Cisco web pages). SSH's
user@host notation is very wide-spread if you ask me. You clearly do
not need a programmer's eye to use it.

> Understandable yes, but this appears to be the exact opposite of my
> current thinking.  I think that securityName identifies the
> principal in the notification sender/originator and SSH user name
> identifies the principal in the notification receiver.

When you send a notification, the ACM filters on the identity of the
receiver. We worked this out quite some time ago. In other words, I
have a securityName on the NO, say "trapsink" and I apply access
control such that "trapsink" only gets what it is allowed to see.
When I use SSH to connect to the NR, the SSH user name is used by the
NR to identify the sender of the notification while the notification
sender has to verify that the hostkey matches the expected hostkey
associated with the SSH transport address. So the binding between the
securityName "trapsink" on the NO and the SSH transport address given
by the local configuration is really the important part from the
notification sender's perspective.
 
> Which way round is going to be the expectation of all those SSH

They will understand that by putting "user@host" into the SSH
transport address, the NO will authenticate as "user" to the NR
running on "host". This is straight forward. 

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Mar 2009 10:54:44 -0500

Hi Tom,

inline. 

[...]
> NO, the other, rtr-nyc4, is used in the NR.  

And that is the confusion I had (or have) as well. I think saying that
alice is the recipient is wrong, if the bob@ format is used. 

In USM, the sender and recipient are the same.
In SSHTM, the sender and recipient are the same, **if** a user@
address is not used.
In SSHTM, if a bob@examp;e.com:PPP address is used, then alice is the
sender and "bob" is the recipient. 

> Well, ok as in 
> correct, less ok as

I believe that for notifications, SNMP uses securityname for access
control for the message **sender** not the notification receiver.

Because in USM the sender and receiver securityName/principal is the
same, this concept of access control for the sender, not the
recipient, did not come easy. And if Juergen said "access control uses
securityName to identify the notification receiver", then he is also
working under the same bad assumptions I was working under before I
grok'd the new reality.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 04 Mar 2009 09:00:15 -0800

>>>>> On Wed, 4 Mar 2009 10:28:02 -0500, "David Harrington" <[email-masked]> said:

DH> I think there is significant work in modifying the document.

I don't think so, assuming you're talking about the SSH document.  In
order to make the changes I made and posted yesterday (and again today)
I reviewed every place that securityName was mentioned in the SSH
document.  There isn't a huge number of references to it and the ones I
found were quickly modified.

It sounds like there is "some" consensus that the TMSM document doesn't
need references to the user@ syntax since it's SSH specific.

If the TSM document contains an @ reference, I'd suggest we remove it.
It's SSH specific.
-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Mar 2009 20:26:35 +0100

---- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 04, 2009 4:54 PM
Subject: RE: [Isms] wg last call followup - sshtm

> sender and "bob" is the recipient.
Right, but as I said in the bit you elided, I am comfortable turning  the roles
round in my head and use sender instead of recipient in the paragraph from the
tsm appendix can understand it whether alice is referred to as sender or
recipient.

To me, it's a philsophical tangle.  I understand the mechanics and agree they
work but also see that what wording makes sense may depend on somewhat abstract
views of identity and identifier.

So I am happy to see the wording in tsm changed as long as we spell out the
mechanics so that they are clear, which I think the appendix does already.

But I also want to see free standing text about this, in the main body of the
I-Ds, no later than sshtm section 3, and again I think that the example of
access control and Notifications needs including so that regardless of the words
used, the steps an implementation must follow are unambiguous.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Mar 2009 20:21:53 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 04, 2009 4:40 PM
Subject: Re: [Isms] wg last call followup - sshtm

> this (but I actually did find screenshots on Cisco web pages). SSH's

I will look again

> notification sender's perspective.

Ok, I now see that explanation too.  I understand and agree the mechanics so as
long as those are called out, as they are eg in the tsm appendix, then I can
live with the terminology.  I see the terminology of roles as more like a
question of philosophy, of identity and identifiers, and as long as we get the
mechanics across clearly, then the terminology actually used does not matter.

I will re-read those long e-mails of Wes from 2006 again, something I do every
so often, to see how our thinking on Notifications has evolved.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2009 10:55:39 +0100

On Wed, Mar 04, 2009 at 10:54:44AM -0500, David Harrington wrote:
 
> > Actually, I see this one as ok:-) It tells me that there is a
> > recipient and that the identifier for that recipient has two
> > values, one, alice is used in the NO, the other, rtr-nyc4, is used
> > in the NR.
> 

My understanding is that the NO creates the SSH session and this
results in the following:

- NO gets an authenticated SSH host identity
- NR gets an authenticated SSH user name

So in both cases (with or without the bob@ format), the NO does access
control against a locally known securityName that is bound to an SSH
transport address via local configuration and the engine has to make
sure that the SSH host is getting properly authenticated before
shipping the notification.

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 5 Mar 2009 11:57:30 -0500

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, March 05, 2009 4:56 AM
> To: David Harrington
> Cc: 'tom.petch'; [email-masked]

OK. I do not think the draft states this adequately. 

Should we add a version of this last paragraph in the security
considerations? in the SSH introduction? maybe section 3.3 for
notifications and proxy? 

should we separate the notification case from the proxy case, since
proxy does not do access control?

What does the engine have to make sure of for proxy?

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 Mar 2009 09:21:25 -0800

>>>>> On Thu, 5 Mar 2009 11:57:30 -0500, "David Harrington" <[email-masked]> said:

>> So in both cases (with or without the bob@ format), the NO does
DH> access
>> shipping the notification.

DH> OK. I do not think the draft states this adequately. 

DH> Should we add a version of this last paragraph in the security
DH> considerations? in the SSH introduction? maybe section 3.3 for
DH> notifications and proxy? 

I tried to put something like that in the security considerations
section for the document I posted yesterday.  Does it meet your needs?

DH> should we separate the notification case from the proxy case, since
DH> proxy does not do access control?

There are two separate cases:

Clients that does access control before sending (NOs only)
Those that don't                                (everything else)

I wouldn't spell out proxies generically since they're already lumped
into the other case.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2009 19:20:32 +0100

> section for the document I posted yesterday.  Does it meet your needs?

I think the text you posted is adequate.

/js

---

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Mar 2009 21:23:29 +0100

I have not got round to content yet but I keep saying the mention of e-mail
format addresses must appear in section 3 at the latest because that is where
the identification of sessions for sshtm is introduced, 3.1.4, so introducing
the e-mail format address there makes it so much clearer what is going to happen
in the EOPs, it plants ideas in readers minds.  Anywhere later is too late for
me.  The text I proposed was written to slot in there (and yes, with any
enhacements dbh wants to make).

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 Mar 2009 13:51:00 -0800

>>>>> On Thu, 5 Mar 2009 21:23:29 +0100, "tom.petch" <[email-masked]> said:

tp> I have not got round to content yet but I keep saying the mention of
tp> e-mail format addresses must appear in section 3 at the latest
tp> because that is where the identification of sessions for sshtm is
tp> introduced

And I can tell you haven't read it yet, because it's discussed there now.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Mar 2009 00:52:31 -0500

> section for the document I posted yesterday.  Does it meet your
needs?

section 3.3:
s/perform proxy/receive proxied messages/

local access control is only done for the NO. It is not done for a
proxied message, even if that proxied message is a notification.

/connection can succeed/connection is available or can be opened/

I recommend replacing the paragraph "Since outgoing messages may need"
with a paragraph explaining a common use case, another describing
client session establishment, and a third that discusses lifetime of
the association.

<old>
   Since outgoing messages may need to be sent to a different SSH
   principal name that does not or can not directly match the SNMPv3
   security name, the SnmpSSHAddress  specifies an [...]
</old>  
<new>
Because naming policies might differ between administrative domains,
many SSH client software packages support a user@hostname:port
addressing syntax that operators can use to align non-equivalent
account names. The  SnmpSSHAddress Textual Convention supports this
common SSH notation. 

When this notation is used in an SnmpSSHAddress, the SSH client uses
the "user" portion of the notation as the principal when establishing
a session with the remote SSH server. The "user" portion may or may
not match the tmSecurityName parameter passed from the security model.
If no "user@" portion is specified in the SnmpSSHAddress, then the SSH
client uses the tmSecurityName as the principal when establishing a
session with the remote SSH server. 

The SnmpSSHAddress and tmSecurityName associated with an SSH session
MUST remain constant during the life of the session. Different
SnmpSSHAddress values (with different hostnames, "user@" prefix names
and/or port numbers) will each result in individual SSH sessions.
</new>

section 4.1.1
I moved the lifetime association of session vs tmSecurityName into
section 3.3, where the lifetime associaiton of SnmpSSHAddress is
discussed, so the second sentence in section 4.1.1 is not necessary. 

possibly more later.

> I wouldn't spell out proxies generically since they're already
lumped

But in section 3.3, the NO and proxy are lumped together.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 6 Mar 2009 10:41:05 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Wes Hardaker'" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 06, 2009 6:52 AM
Subject: Re: [Isms] wg last call followup - sshtm

David

That looks excellent.

History tells me that I also need to see it in context since I sometimes then
find other sentences which need tweaking to bring them in line, and as I have
said, that takes me a bit longer to do; so agreement pro tem.

Tom Petch

---

From: "David B. Nelson" <[email-masked]>
Date: Sun, 08 Mar 2009 23:19:03 -0400

Juergen Schoenwaelder wrote:
> have led to some changes to the ISMS core documents.
I have just posted draft-ietf-isms-radius-usage-05.txt, which incorporates all the revised text we agreed to on the mailing list, arising out of the WGLC.