Subject: [Isms] Issue#10 - TSM aggregated security names

From: "David Harrington" <[email-masked]>
Date: Fri, 30 May 2008 13:20:10 -0400

Hi,

If a system supports both SSH-TM and TLS-TM, and we use a default 1:1
mapping from the mechanism-specific principal to securityName, we
could hit a situation where SSH:David and TLS:David are actually
different principals, but get assigned the same securityName by the
TSM. 

I think this is a problem. I also think that without giving
mechanism-specific knowledge to the TSM, the TSM cannot solve this on
its own.

Should TSM have a table that specifies how the mapping should be done
per transportModel supported? This table would be agent-generated and
contain a row for each supported TM. A writable column would support
four admin-configurable options; the default setting for each
supported TM would be #1:
1) use the default mapping specified by the TM (usually this will be
some type of algorithmic 1:1 mapping); 
2) Do not allow a specific transport model to be used at all (do not
assign a securityName to any identity authenticated by the specific
transport model);
3) use an optional admin-configurable table that provides explicit
mappings from an mechanism-specific and implementation-specific
algorithmically derivable identity to a user-chosen securityName (and
vice-versa). Only identities found in this table are allowed to be
assigned securityNames. Wildcards might be supported.
4) The same table as 3), but if a name is not found in the table, then
fallback to using the default mechanism.

Comments?

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

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

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 30 May 2008 14:17:21 -0400

David Harrington writes...

> If a system supports both SSH-TM and TLS-TM, and we use a default
> 1:1 mapping from the mechanism-specific principal to securityName,
> we could hit a situation where SSH:David and TLS:David are actually
> different principals, but get assigned the same securityName by 
> the TSM.
> 
> mechanism-specific knowledge to the TSM, the TSM cannot solve this
> on its own.

I think this is a more general problem.  Any time you draw identities
multiple name-spaces and use that identity in an interchangeable fashion
without a name-space tag, you have a potential problem.

To use a simplistic example, host names are often ambiguous unless they are
represented as fully qualified domain names.

The fact that you have multiple secure transports does not automatically
mean you have multiple name-spaces.  If SSH-TM and TLS-TM are both using the
same RADIUS server for authentication of the principal, the names will be
from the same name-space.  Conversely if you have a single secure transport
that somehow uses multiple authentication sources (e.g. RADIUS and LCD) at
the same time, name collision can occur.

The simplest solution is to require (administratively) one of: (a) all
secure transports utilize the same source of authentication, i.e. a single
name-space, or (b) all names to be represented in a fully qualified format,
e.g. name@name-space.