Subject: [Isms] current naming agreement

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Jul 2008 03:37:32 -0700

I *think* that there is almost agreement on the following as a solution,
based on discussions on the list and in the hallways.  I think this is a
reasonable compromise on most sides (it's not the solution I myself
would pick, but I'm willing to accept it).  It combines elements from
multiple people and satisfies some of the issues some folks have.  None
of the elements are new, just combined.

Points:
* Defaults to no-configuration necessary for the easiest use case
** (IE, SSH user "david" will end up at the VACM as "david" unless the
   operator dictates otherwise).
* Doesn't require a complex management scheme
** Uses a single scalar for configuration.  It's not as flexible as some
   (including myself) may like, but it achieves the needed goal.
* Allows separation of TM protocols if needed by an operator.
* Assumes this is needed, which I'm not sure consensus has been reached
  on, but I think it's close.
* Puts the prefixing requirement in the TM instead of the TSM so the TSM
  can be TM agnostic (providing more architectural separation).
* Insanely simple to implement.  Searching for a mandatory : passed up
  by the lower level transport and stripping it is very little code and
  should be very fast.

Proposal Summary:
  In the TM document:
     "Documents defining a new TM implementation MUST define a security
     name prefix that will be pre-pended to all passed securityNames.
     This prefix MUST be from 1-4 securityName compatible octets
     followed by a ':' (ASCII 0x3a) character."

  In the TSM document:
     Add the following object (or similar) to the MIB:

     tsmStripSecurityNamePrefix OBJECT-TYPE
         SYNTAX      TruthValue
         MAX-ACCESS  read-write
         STATUS      current
         DESCRIPTION
             "This object indicates whether the transport modules string
             prefix will be removed before being passing the securityName
             to the message processing model.  If set to true, the string
             prefix will be removed.  If set to false, the string prefix
             will be left in place in front of the securityName passed up
             from the transport."
         DEFVAL { true }
         ::= { FILL }     

    (sorry David, I forgot the object name you wanted but I'll leave it
    to you to propose the scalar name you wished)

    Change bullet 4 in section 5.2 to read:

   4) Set securityName to the value of tmSecurityName from the cache
      referenced by tmStateReference.  If the tsmStripSecurityNamePrefix
      object indicates that the TM prefix should be removed, remove
      everything up to and including the first ':' (ASCII 0x3a)
      character in the securityName value to be returned.

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 29 Jul 2008 08:57:10 -0400

Jeffrey Hutzelman writes...

> It is a design feature of ISMS that we delegate to SSH the entire problem
> of mapping names coming from potentially disparate authentication
> namespaces into a common namespace which is provided to us.  This is a
> feature because SSH has to (and does) solve it anyway.
> 
> If we extend this approach to every future secure transport mapping, such
> that all such mappings can be expected to deal with any differences or
> false similarities between names used by their authentication mechanisms,
> then we are left only with the problem of dealing with differences and/or
> false similarities between names provided us by different possible secure
> transports.

Well, that's very nice and convenient.  I'm unaware of the document that
specifies this "identity disambiguation" behavior of SSH authentication and
that of other secure transports.  Would you please give me a pointer?
Thanks!

Wes Hardaker writes...
 
> of the elements are new, just combined.

Assuming that the behavior Jeff describes, above, is present (sorry to be a
Doubting Thomas), it seems reasonable to me, too.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 29 Jul 2008 09:17:16 -0400

Wes Hardaker writes...

>      followed by a ':' (ASCII 0x3a) character."

Will there be an IANA registry for this 1 to 4 character code?  Or will we
allow implementers to each make up their own set of abbreviations?  I think
an IANA registry is required, for purposes of interoperability.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jul 2008 14:36:50 +0100

--On Tuesday, July 29, 2008 08:57:10 AM -0400 "David B. Nelson" 
<[email-masked]> wrote:

> specifies this "identity disambiguation" behavior of SSH authentication
> and that of other secure transports.  Would you please give me a pointer?

I think perhaps you misinterpreted what I said.  I said that SSH solves the 
problem, and it does.  This is a basic part of the way SSH user 
authentication works.  Particularly, SSH does not try to map names used by 
a particular authentication mechanism onto SSH usernames.  Instead, a 
client which is trying to authenticate must indicate what SSH username it 
wants, and the SSH server makes an authorization decision as to whether the 
client is allowed to use that username.  The details of how that decision 
is made are mostly up to the particular userauth method used (and, to a 
large extent, up to the implementation and to local policy).

So, the only way you can have two different clients with the same username 
is if two sets of credentials are authorized to use the same username. 
Those could be different credentials for the same userauth method, or for 
different methods.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Jul 2008 16:43:08 +0200

>       character in the securityName value to be returned.

What happens if I send a notification? Is everything sane in this case?

/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
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 29 Jul 2008 22:38:29 -0400

> I think perhaps you misinterpreted what I said.

Well, that's entirely possible.
 
> So, the only way you can have two different clients with the same 
> username is if two sets of credentials are authorized to use the 
> same username.

Hmmm.  I'll go off and re-read the SSH authentication method documents and
see if I can reconcile this for myself.  If not, I may be back.  :-)

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Jul 2008 06:59:28 -0700

>>>>> On Tue, 29 Jul 2008 09:17:16 -0400, "David B. Nelson" <[email-masked]> said:

DBN> Will there be an IANA registry for this 1 to 4 character code?  Or
DBN> will we allow implementers to each make up their own set of
DBN> abbreviations?  I think an IANA registry is required, for purposes
DBN> of interoperability.

I think that some of the other registrations options could be just fine
too, but I think IANA is probably the best of that set of options.  So
yes, I agree, it'd require IANA text and action.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Jul 2008 06:58:40 -0700

>>>>> On Tue, 29 Jul 2008 16:43:08 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> What happens if I send a notification? Is everything sane in this case?

The remote side will still be tied to the securityName provided by (in
this case) the notification originator if the scalar was set to true
(strip the prefix).  It does beg the question, though, is if the scalar
is set to false then does the notification need to be set up (via the
target-mib) with the securityName "ssh:juergen" or just "juergen".  I
can argue it either way and actually don't care too much as long as it's
defined.

Since the VACM authorization is functionally done *before* the agent
tries to send the notification and it's using it's own data to do that,
it would likely make sense to require the prefix to be set up properly
already in both the target-mib and (obviously) the VACM tables.

It will, however, require probably another sentence in text talking
about stripping the prefix before opening a session where the
securityName used for openSession() would be expected to be prefixed.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2008 10:39:05 +0200

> can argue it either way and actually don't care too much as long as it's

If the prefix is dropped by TSM, then I think all the "higher" layers
in the SNMP engine should never see/worry about the prefix. So it is
TSM's job to put the prefix back in place again for outgoing
notifications. There is however an issue here with length
restrictions. If I setup a 30 byte security name, there is no space to
squeeze in a prefix anymore and we have to drop the message. This
might not be a show stopper as long as we have a proper error counter
for this.

> already in both the target-mib and (obviously) the VACM tables.

See above for an argument for a different position. ;-)

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 31 Jul 2008 02:41:12 -0700

>>>>> On Thu, 31 Jul 2008 10:39:05 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> If the prefix is dropped by TSM, then I think all the "higher" layers
JS> in the SNMP engine should never see/worry about the prefix. So it is
JS> TSM's job to put the prefix back in place again for outgoing
JS> notifications.

Well, except it's not the lower layers that actually care.  Really, the
thing that cares the most is the VACM which is where we need it.  The
"agent" is the one that needs the prefixed name since it can check the
VACM for ssh:juergen vs dtls:juergen when the scalar is set to false
regardless of whether it's checking the authorization of a SET or a INFORM.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2008 11:46:30 +0200

> regardless of whether it's checking the authorization of a SET or a INFORM.

But if I turn the 'drop magic prefixes' button on in TSM, I likely do
this because I do not want to distinguish between dtls:schoenw and
tls:schoenw, that is, I do not want to deal with this distinction in
VACM. So in this case, I would expect that TSM has to fill in the
right prefix, no?

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 31 Jul 2008 03:00:38 -0700

>>>>> On Thu, 31 Jul 2008 11:46:30 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> But if I turn the 'drop magic prefixes' button on in TSM, I likely do
JS> this because I do not want to distinguish between dtls:schoenw and
JS> tls:schoenw, that is, I do not want to deal with this distinction in
JS> VACM. So in this case, I would expect that TSM has to fill in the
JS> right prefix, no?

Yes, I guess that would make sense though I'm not sure who the consumer
is at this point.  I guess the TM will need to strip it from above as
well (always) before using it on the wire, but other than that it has no
impact on any other module, right?
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms