Subject: Re: [Isms] mapping here, mapping there, mapping everywhere

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 27 Aug 2008 20:34:29 -0400

--On Wednesday, August 27, 2008 04:00:57 PM -0700 Wes Hardaker 
<[email-masked]> wrote:

> A)  Drop the snmpTsmLCDTable.  I think the usage of the ssh: and dtls:
>     prefixes actually removes the need for the more complex mapping (and
>     in fact that was the purpose of the string prefixes: to meet in a
>     middle ground for complex mapping vs no mapping).

+1

> B)  Drop the sshtmLCDTable mapping support.  The only real reason this
>     is needed if we do have a string: prefix would be to map long user
>     names to short ones and I don't think it's needed based on current
>     usage at least.  We would likely need a counter for
>     "userNameTooLong" or something just to provide failure reason
>     detection.

+1 but don't preclude implementations from providing support for a mapping 
here, specifically to deal with the long username problem.  It may turn out 
that this is a problem e.g. in deployments where ssh is authenticated by 
GSS-krb5 using the organization's windows domain, with usernames being the 
user's actual full name.

I'm not sure what the snmpTsmLDCDomainTable transformation you describe in 
step 6 is for.  It seems to provide a more complex mapping which should be 
eliminated by the boolean strip-the-prefix-or-not behavior we seem to have 
settled on.

-- Jeff
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 28 Aug 2008 07:59:58 -0700

>>>>> On Wed, 27 Aug 2008 20:34:29 -0400, Jeffrey Hutzelman <[email-masked]> said:

>> B)  Drop the sshtmLCDTable mapping support.
[...]

JH> +1 but don't preclude implementations from providing support for a
JH> mapping here, specifically to deal with the long username problem.

Agreed.  In fact the DTLS draft *has* to have a separate mapping table
because of the length of x509 identifiers.

JH> It may turn out that this is a problem e.g. in deployments where ssh
JH> is authenticated by GSS-krb5 using the organization's windows
JH> domain, with usernames being the user's actual full name.

Yep.  Or realm based suffixes.  However, even that is most typically
less than 32-strlen("ssh:") though there are definite exceptions at that
point.

Soapbox: Technically, I actually think we should have one long-to-short
mapping table in the TSM since I think it's a likely common issue
between the transports.  However, many vocal opinions of the past
thought we should have minimal mapping support at the TSM layer because
not much needed it at the moment (SSH names are rarely longer than 8 in
most common real-world deployment today).  It actually turns out that
for X509 cases I really needed a table within the DTLS draft anyway,
though, so in the end it wouldn't have saved my anything by having
common infrastructure.  (the DTLS draft needed a table to specify
whether to use a generic commonname field straight up by a trusted CA vs
doing a individual mapping per every individual...  So configuration was
already needed for mapping at the DTLS TM specific level).

JH> I'm not sure what the snmpTsmLDCDomainTable transformation you
JH> describe in step 6 is for.  It seems to provide a more complex mapping
JH> which should be eliminated by the boolean strip-the-prefix-or-not
JH> behavior we seem to have settled on.

Right...  I agree.  The only real purpose it serves now is to provide
configuration for completely turning off a service (the disable(3)
value).  Although, the scalar flip to passing the prefix and not
providing authorization accomplishes the same thing it does require more
overhead since it doesn't actually turn of the service (with all the
crypto calculations attached).
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Aug 2008 11:09:49 -0400

> crypto calculations attached).

Neither does the table, if it is implemented by TSM as its name suggests. 
By the time TSM gets control, the transport connection has already been 
established, and the hard work is already done.

The right way to disable a transport is to disable the transport, not to 
configure TSM to reject messages arriving via that transport.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 28 Aug 2008 08:42:47 -0700

>>>>> On Thu, 28 Aug 2008 11:09:49 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> Neither does the table, if it is implemented by TSM as its name
JH> suggests. By the time TSM gets control, the transport connection has
JH> already been established, and the hard work is already done.

JH> The right way to disable a transport is to disable the transport, not
JH> to configure TSM to reject messages arriving via that transport.

I agree.  Though I have suspicions that people implementing it wouldn't
follow the architecture quite so rigorously and thus it still provides a
switch.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Thu, 28 Aug 2008 11:48:13 -0400

Hi,

> most common real-world deployment today). 

Complexity is the enemy of security. We need to provide a
simple-to-configure secure solution. 

I have no objection to having mappings tables in TSM.
I object to having mandatory-to-implement tables that not everybody
needs.
I object to having the optional tables described as part of TSM, when
they could simply be independent MIB modules that people do or do not
choose to implement.

I think VACM fails the simple-to-configure rule. VACM is way more
complex than most operators need. The learning curve is huge because
it has options up the whazzoo (did I get that spelling right?). I
liken this to taking a space shuttle to the store to buy milk; you can
do it, but who would want to pay for it and learn how to use it when
they could just walk, bike, or drive? 

I do not want to see ISMS produce specs with lots of options for some
small segemnts of the industry. RFC3411 was designed to allow the IETF
to develop standardized models for the 80% solution, and then the
small segments that want extra features can design their own models.
History has shown that the segments who "require" these extra features
in SNMPv3 do not find it required enough to develop alternate models.
This approach is a good way to focus on the essentials and eliminate
the nice-to-haves.

I have concerns that we are going to change the SSHDomain to add
sending to somebody other than the current user name, because a small
segemnt of the industry might use it. Write another model that
supports this! Do not make it a requirement of SSHTM to support a
small segment of the community.

I am concerned about adding mapping tables to TSM because a small
segement of the population might use a technology that has longer than
32-character names. Write another model that supports longer names!
Don't make it something that everybody has to deal with. Even if it
has nice defaults (and I'm sure the space shuttle has lots of nice
defaults too), it increases the complexity and the learning curve and
the operational costs.

KISS - Keep ISMS's SNMP simple!

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 28 Aug 2008 09:30:10 -0700

>>>>> On Thu, 28 Aug 2008 11:48:13 -0400, "David Harrington" <[email-masked]> said:

DH> I object to having mandatory-to-implement tables that not everybody
DH> needs.

Sorry to bring your blood-pressure up.  I added the paragraph for Jeff's
benefit to document that it's been discussed and the WG has pretty much
opted not to go there.

Drat.  I responded.  I said I'd make this short and then blew it.  Feel
free not to read it David, because I'm not even arguing that we change
past decisions.  I'm merely explaining my rational behind my statements.

DH> I think VACM fails the simple-to-configure rule. VACM is way more
DH> complex than most operators need. The learning curve is huge because
DH> it has options up the whazzoo (did I get that spelling right?).

There is a rather deployed base out there that offers an interface that
completely hides the complexity of the VACM for those that don't need
complex configurations.  All the users of the simplistic wrapper never
complain it's hard to use.  Many do, however, start needing more
flexibility in their authorization rights and some of them certainly do
start asking questions about the best way to do the in-depth
not-easy-wrapped VACM configuration.  This actually proves to me,
however, that the need for those complex configurations is well above
even 10%.

In fact, I originally thought the VACM was over the top in many areas
and was more complex than it needed to be.  Because of my direct
interactions with users that fall into both extremes of the usage model,
I actually have retracted my original feelings and think it's a good
middle ground solution.

Thus, the VACM example doesn't work for me.

DH> I am concerned about adding mapping tables to TSM because a small
DH> segement of the population might use a technology that has longer than
DH> 32-character names.

I think that there is a huge discrepancy here between what we consider
the user base to be.  I actually think there is a fairly large segment
of the population that will be using longer-than-32-character names over
potentially multiple transports.

I agree that if we have only this:

  SSH -> TSM -> VACM

It doesn't matter where we stick the limiting agent that reduces longer
names to < 32 octets.  In fact, because the 95% SSH use case out there
is of usernames < 8 octets it probably doesn't need to exist.

But, eventually we may end up with:

  DTLS/K509----\
                V
  SSH/KRB   -> TSM -> VACM
                ^
  TLS/K509-----/
              /
  ???--------/

In which case sticking a mapping table in each of the transports no
longer scales as well and requires a lot more configuration tables, not
less.  "KISS now" just lost when we get to that point.  I don't think
it's farther way.  The world is moving far away from 8-character
identifiers as logins become more attached to X509 cert fields or email
addresses or Full names or ...

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Aug 2008 15:06:21 -0400

> small segment of the community.

On this point, I think you are confused.  We are changing the SSHDomain to 
allow specifying the username to use when connecting to the remote ssh 
server.  This is not "sending to somebody other than the current user 
name"; it is identifying ourselves (the notification originator) as 
somebody other than the current securityName, which names the notification 
recipient.  Since it is uncommon to send a notification to oneself, this is 
the rule, not the exception.

I'm also very concerned about what seems to be a desire to standardize as 
little as we can get away with and still support the single most common use 
case, marginalizing everyone else.  History has shown that those of us who 
want or need strong authentication for anything from remote login to 
filesystems to databases to network management _JUST LOSE_ because none of 
us are big enough to force the vendors to implement something nonstandard. 
This situation is not acceptable to me, and I am not interested in being 
part of the problem.

I agree that too much complexity in configuration creates problems, but I 
do not agree with the philosophy that "configuration is bad, less 
configuration is easier to use, so everyone should do it my way, and if you 
don't want to do it my way, you're SOL".  If that's how we think, then why 
not just tell everyone to run Windows and IOS and give up on 
standardization entirely?

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Aug 2008 15:13:16 -0400

--On Thursday, August 28, 2008 09:30:10 AM -0700 Wes Hardaker 
<[email-masked]> wrote:

> The world is moving far away from 8-character

No.  The world was done with 8-character user names 10 years ago.
Many modern UNIXes have no such limit.
Windows has no such limit.
No modern authentication protocol has such a limit.

And most importantly, random operators know of no such limit, and so they 
create accounts with whatever names seem useful.  Just because you and I 
live in environments with the 8-character username assumption embedded in 
decades-old code and policy doesn't mean that that assumption has any place 
_at all_ in defining standards for the Internet.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Thu, 28 Aug 2008 17:12:25 -0400

Hi,

We don't have an 8-character limit either. I don't know why we are
even talking about 8-character limits.

VACM limits us to 32 characters:
vacmSecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))

We are not chartered to change VACM.

The rest of the system does not appear to limit us:

RFC3413 doesn't limit us:
   snmpTargetParamsSecurityName OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The securityName which identifies the Principal on
            whose behalf SNMP messages will be generated using
            this entry."
       ::= { snmpTargetParamsEntry 4 } 

RFC3411 doesn't limit us:
SnmpAdminString ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "255t"
	...
    SYNTAX       OCTET STRING (SIZE (0..255))

and SSH user-auth (RFC4252) doesn't limit us:
      string    user name in ISO-10646 UTF-8 encoding [RFC3629]

USM has its own 32-character limit:
           msgUserName                  OCTET STRING (SIZE(0..32)),
and
usmUserName      OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
But those should not impact TSM or SSHTM.

We have a 32-character limit in the current revisions of TSM and SSHTM
LCDs; I am not sure we need this restriction, and I can remove it if
that is WG consensus:

snmpTsmLCDSecurityName      OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))

and here ...

sshtmLCDTmSecurityName      OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))

and here ...

sshtmLCDPrincipal      OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))

Is 255 (minus the SSH: prefix) large enough to satisy?

Assuming 255 is large enough, how do we define a table to map from an
unpredictable 255 character identifier for an authenticated entity
down to a 32 character snmpAdminString identifier for VACM that does
not introduce security risks?

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Thursday, August 28, 2008 3:13 PM
> To: Wes Hardaker; David Harrington
> Cc: 'ISMS WG'; [email-masked]
> Subject: Re: [Isms] mapping here, mapping there, mapping everywhere
>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 28 Aug 2008 17:23:29 -0400

David Harrington writes...

> ...how do we define a table to map from an
> unpredictable 255 character identifier for an authenticated 
> entity down to a 32 character snmpAdminString identifier for
> VACM that does not introduce security risks?

Um, allow the table entries to contain arbitrarily complex regular
expressions?  ;-)

I guess what you're asking is how can the operator know that there will not
be unexpected mapping "collisions" within the constraints of his/her
particular deployment?   That seems a less general (i.e. more tractable)
problem to solve.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Aug 2008 19:05:36 -0400

> even talking about 8-character limits.

Me either; it's Wes who keeps bringing them up.

>     SYNTAX       SnmpAdminString (SIZE(1..32))

So, VACM has this limit, but the architecture doesn't impose a limit on the 
length of the securityName produced by the MPM?  If USM has the same limit, 
then I'll bet no one has ever noticed there is a problem.

I suspect the best thing to do is to assume that the architecture has a 
32-character limit for security names, keep that same limit in TSM, and 
arrange for SSHTM to never emit names longer than that.  I think it is 
probably OK to say that...

- by default, the tmSecurityName produced by sshtm consists of the string
  "ssh:" followed by the SSH username
- if the tmSecurityName would exceed 32 characters in length, then sshtm
  MUST instead generate some error/drop the request/whatever

The thing we perhaps leave unstated is that it is permissible to provide an 
implementation-specific means to configure a non-default mapping, in which 
sshtm produces a tmSecurityName consisting of the string "ssh:" followed by 
something other than the SSH username.

Note that in the case of DTLS, the tmSecurityName is going to consist of 
the string "dtls:" followed by some string which is somehow derived from 
the DTLS client certificate.  I don't know how much configuration Wes is 
providing there, but IMHO it makes sense for the mapping in each case, to 
the extent that it is necessary, to occur in the TM, because the input to 
the mapping is a transport-specific form.

> Is 255 (minus the SSH: prefix) large enough to satisy?

I would think so, but then, people used to think 8-character userid's were 
enough.  My preference would be to avoid hard limits entirely, and instead 
support a soft limit ("implementations may limit the length of usernames, 
but names of up to NNN characters _must_ be supported").

However...

> not introduce security risks?

I'd rather not think about that, which is why I am suggesting we retain the 
32-character limit.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Aug 2008 08:52:03 -0700

>>>>> On Thu, 28 Aug 2008 19:05:36 -0400, Jeffrey Hutzelman <[email-masked]> said:

>> even talking about 8-character limits.

JH> Me either; it's Wes who keeps bringing them up.

It was an example of bad thinking from the past.  Sorry you
misinterpreted it as anything other than an example.

>> SYNTAX       SnmpAdminString (SIZE(1..32))

JH> So, VACM has this limit, but the architecture doesn't impose a limit
JH> on the length of the securityName produced by the MPM?

The weakest link in the chain is the VACM, I think we agree on that.
The only important point is that because of the weakest link if we do
anything that produces names longer than 32 octets we've broken the
chain.  Regardless of what would be ideal, if we're not going to change
the VACM then we simply must accommodate it's needs or our results won't
be usable.  I think we're *all* in agreement on that so we can restrict
ourselves to just the solution space instead.

>> Is 255 (minus the SSH: prefix) large enough to satisy?

(So no, this won't work when you add in the full chain).

JH> I think it is probably OK to say that...

JH> - by default, the tmSecurityName produced by sshtm consists of the string
JH> "ssh:" followed by the SSH username
JH> - if the tmSecurityName would exceed 32 characters in length, then sshtm
JH> MUST instead generate some error/drop the request/whatever

I'm not convinced that's the most scalable long term solution (still),
*but* I can live with it at least so I'm all in favor of adopting it in
the interest of forward progress.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms