Subject: [Isms] Proposed changes to draft-ietf-isms-transport-security-model

From: Wes Hardaker <[email-masked]>
Date: Wed, 04 Mar 2009 14:03:01 -0800

Here are some proposed changes to the TSM document that removes the
reference to the user@ in the example in appendix A.  Does anyone see
any issues with these changes:

  http://www.hardakers.net/temp/tsm-diffs.html

-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Mar 2009 17:24:23 -0500

I'm OK with these changes.

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Wednesday, March 04, 2009 5:03 PM
> To: [email-masked]
> Subject: [Isms] Proposed changes to 
> draft-ietf-isms-transport-security-model
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 04 Mar 2009 17:49:54 -0500

> I'm OK with these changes.

 Mee too

---

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

>   http://www.hardakers.net/temp/tsm-diffs.html

OK with me (speaking as technical contributor)

/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: <[email-masked]>
Date: Fri, 6 Mar 2009 10:58:19 +0100

Wes,

I do not like this change -- it will make the example considerably
harder to understand, since the reader can't possibly figure out 
how the NO actually initiates the SSH connection (since it requires
a SSH user name, and it's certainly not "alice").

While user@host syntax is indeed specific to SSHTM, this particular
example *is* about SSHTM. And transport addresses are *always* specific 
to some TM, so any example showing a transport address will be specific 
to some TM.

(There's no requirement that TMs use the "<hostname>:<port>" syntax;
e.g. a DCCP-based TM would need a syntax that includes the DCCP 
service code, and HTTP-based TM would use URIs.)

Best regards,
Pasi

> Behalf Of ext Wes Hardaker
> Sent: 05 March, 2009 00:03
> To: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Mar 2009 07:04:08 -0800

>>>>> On Fri, 6 Mar 2009 10:58:19 +0100, <[email-masked]> said:

PE> I do not like this change -- it will make the example considerably
PE> harder to understand, since the reader can't possibly figure out 
PE> how the NO actually initiates the SSH connection (since it requires
PE> a SSH user name, and it's certainly not "alice").

Well, we could make it more clear that the ssh user name will be alice
in the text.

I don't think the example will benefit from adding the alice@ prefix
since the object of the text is to discuss how configuration of
notifications works from a bunch of other perspectives (ASIs, MIBs, etc).

PE> (There's no requirement that TMs use the "<hostname>:<port>" syntax;
PE> e.g. a DCCP-based TM would need a syntax that includes the DCCP 
PE> service code, and HTTP-based TM would use URIs.)

Except that having a required port matches every TC produced to date and
matches the way the previous UDP and TCP TCs worked so it helps the
understanding.  And since the SSH TC requires it, we can't leave it out
of the example anyway.
-- 
Wes Hardaker
Sparta, Inc.

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 16:19:10 +0100

Wes Hardaker wrote:
> 
> PE> I do not like this change -- it will make the example
> PE> considerably harder to understand, since the reader can't
> PE> possibly figure out how the NO actually initiates the SSH
> PE> connection (since it requires a SSH user name, and it's
> PE> certainly not "alice").
> 

In current examples, the prefix is "rtr-nyc4@", not "alice@".

Using "alice" as SSH user name here doesn't really make sense.
"alice" is our (notification originator's) name for the receiver
(used for VACM); the SSH user name has to be the receiver's
name for us (the originator).

Since how exactly the SSH user name works was one of the 
topics that took even the WG many years to understand,
I think it's important to be as clear as possible in
the examples here.

Best regards,
Pasi

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Mar 2009 07:27:35 -0800

>>>>> On Fri, 6 Mar 2009 16:19:10 +0100, <[email-masked]> said:

PE> Since how exactly the SSH user name works was one of the 
PE> topics that took even the WG many years to understand,
PE> I think it's important to be as clear as possible in
PE> the examples here.

I agree.  I think the text should state that the SSH user name
will be taken from the securityName value.

And the prefix definitely needs to be well explained in the SSH draft.

-- 
Wes Hardaker
Sparta, Inc.

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 16:30:48 +0100

> will be taken from the securityName value.

But the example is about *notification originator*, and that's the 
one case where taking SSH user name from securityName doesn't
make much sense! So although that's the default (in absense
of "user@", this is a situation where the "user@" prefix would
almost always be used (and the example should show a typical
or common case, not something so rare it probably never happens).

Best regards, 
Pasi

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Mar 2009 10:42:11 -0500

Hi Pasi,

I disagree. 

In the TSM document, we are focused on helping readers understand how
TSM works, not SSHTM. In SSHTM, if the transportAddress does not have
a "user@" component, then we default to using the securityName (in
this case, "alice") for the SSH user name. So the example in TSM is
not wrong, and since it does not introduce the special SSH addressing
mode, is clearer for purposes of explaining TSM.

dbh

> Behalf Of [email-masked]
> Sent: Friday, March 06, 2009 10:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] Proposed changes 
> todraft-ietf-isms-transport-security-model
> 
> Wes Hardaker wrote:
> >

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Mar 2009 07:44:22 -0800

>>>>> On Fri, 6 Mar 2009 16:30:48 +0100, <[email-masked]> said:

PE> But the example is about *notification originator*, and that's the 
PE> one case where taking SSH user name from securityName doesn't
PE> make much sense!

No, it MAY make perfect sense.  Even a lot of the time.  We don't have a
huge amount of data to say how often it'll make sense or not.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Mar 2009 10:47:50 -0500

> Sent: Friday, March 06, 2009 10:28 AM
> To: [email-masked]
> Cc: [email-masked]

***I disagree***
Please state that it is taken from the administratively-configured
MIB, or other implement-dependent datastore, but please do not say it
is taken from the securityName value, because that may not always be
true for all uses of TSM.

I really think we do not want the TSM document discussing any of the
details of how SSHTM works! This is a modular architecture.

---

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

Hi,

So are you saying that within an enterprise, operators rarely use the
same naming conventions across their different SSH entities? In my
small home network, I use the same identity for all my SSH endpoints.
SSH is not my area of special expetise, but I would expect that SSH
naming might be consistent within an administrative domain.

And to my knowledge, SNMP is usually used within, not across,
administrative domains. 

dbh

> Sent: Friday, March 06, 2009 10:31 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 06 Mar 2009 12:37:28 -0500

> naming might be consistent within an administrative domain.

No, he's saying that when an NO sends a notification with securityName 
"alice", then "alice" describes the NR, not the NO.  It is highly unlikely 
that, when the NO originates an SSH connection, it is going to use the 
username "alice", because _the NO is not alice_.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Sat, 7 Mar 2009 12:15:50 +0100

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 06, 2009 4:19 PM

> I think it's important to be as clear as possible in

Pasi,

I think that the mechanics of this combination of securityName and e-mail format
transportAddress are relatively straightforward to describe and understand.  It
is when the descriptions get more abstract, referrring to authenticated
receivers, that I see confusion arising; and this is perverse for me, since I
usually want less mechanics and more abstractions in the snmp I-Ds.

I have a fixed view of authentication; Alice makes an assertion and offers
security credentials to authenticate it which Bob uses to perform such
authentication as he thinks necessary.  This idea sometimes jars with the
language used in the three I-Ds but that I can cope with.

The two gaps in my understanding were having two separate securityNames, one in
NO and the other in NR, which I had not seen as permitted, although a careful
study of RFC3411 shows those clever authors of RFC3411 did not exclude it "A
securityName is a human readable string representing a principal.": and that the
securityName used in the NO was not authenticated in the sense I understand it -
Juergen pointed out that the securityName in the NO is bound to the
authenticated host name of the ssh server.  I had not see this last as secure
enough but when those with more security expertise than I say it is ok, then I
will accept that.

So, should the example be in tsm?  I think yes, but the wording needs adjusting,
addressing the two points that I was hung up on.

Is, as the example says, the e-mail format address model independent?  I am
happy to see it as such, certainly not specific to Notifications.

Tom Petch