Subject: [Isms] ISMS #2: tmSecurityName

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 21:46:34 +0100

ISMS #2: tmSecurityName
Status: open

Section 4.2 of draft-ietf-isms-secshell-09.txt contains the following
text:

   [TODO: standardize some dynamic mechanisms for SSHTM, per auth-
   protocol, such as user-auth, host-auth, etc.  Make the list of
   authProtocols expandable, and provide default algorithms.]  [DISCUSS:
   this cannot be implementation-dependent.  It used to identify the
   layer 8 principal for use in such things as logging and for access
   control policy assignment. it must generate a predictable
   securityName representing the principal, regardless of the
   authentication mechanism.  USM provides this by pre-configuration of
   the mapping of the auth protocol and auth-specific credentials to a
   securityName, in the usmUserTable.  We MUST have the similar mapping,
   preferably done dynamically rather than statically.  Therefore either
   the dynamic mapping algoruithm MUST be standardzied. or we MUST have
   a static mapping.]

My understanding here is that the core of the issue is to mandate a
specific mapping from the known SSH authentication mechanisms to the
tmSecurityName.

Q2.1: Is there agreement that we need to mandata a common mapping?

Q2.2: If yes, which user authentication protocols do we have to
      consider and how does the mapping for each one look like?

/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://www1.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jan 2008 16:14:28 -0500

Hi,

The issue here is a feature of USM and the SNMP architecture that may
be needed with transport security transport models.

Part of the purpose of securityName was to provide a consistent name
for the principal regardless of security algorithm used for authn.
Such a consistent name can then be used for logging, for configuring
tables of entries, such as for notifications and access controls, with
a known identifier for a principal.

If we use the identity mapping for all SSH authn protocols, then there
may be multiple securityNames generated for a given principal. That
means that the VACM securityToGroup table will need to be configured
with all the possible securityName variations for a given principal.
If RADIUS is used to perform the securityName-to-group mappping, then
the RADIUS server will need to be configured to recognize all the
various securityNames for a given principal, or RADIUS would need to
know all the various mappings from SSH authn protocols so the RADIUS
server can provide the authn-specific identity to a model-independent
securityName and groupName.

The USM usertable allows a principal to be authenticated using a
model-dependent identifier, and the authenticated identity is then
mapped to a securityName. Multiple entries in the table can generate
the same securityName, so a principal may have multiple ways they can
be authenticated and still end up with the same securityname.

How do we do this with a protocol like SSH, where we shouldn't even
necessarily know about the underlying authn protocols? If this is
done, it needs to be done by functionality that understands both SSH
authn and the SNMP securityName, which is presumably the transport
model.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2008 3:47 PM
> To: [email-masked]
> Subject: [Isms] ISMS #2: tmSecurityName
> 
> ISMS #2: tmSecurityName
> Status: open
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jan 2008 16:43:51 -0500

> authn and the SNMP securityName, which is presumably the transport

Well, that depends on what direction we're talking about.  SSH has one set 
of mechanisms that prove the identity of the SSH server to the SSH client 
(key exchange), and a second set which prove the identity of the SSH client 
to the SSH server (user authentication).

In the case of user authentication, ssh provides for a "user name" which is 
sent by the client, and the job of the userauth method is to prove that the 
client is authorized to act for that user.  The authentication name used by 
the underlying mechanism is, of course, mechanism-specific, but the 
resulting username is mechanism independent.  In the traditional case, the 
username corresponds to the name of an account on the machine where the SSH 
server runs, and any requests made by the client to do things like run 
subsystems or start shells are run as that user.  It seems quite clear to 
me that for SNMP, the SSH username should be used directly as the SNMP 
securityName, with no need for any further mapping.  The mapping from, say, 
a certificate or Kerberos principal name to the ssh username is handled by 
the particular userauth method in use.

The reverse direction is, as you know, much trickier.  This is partly 
because SSH has no formal model for naming servers, and partly because the 
practical ways to name such things do not look anything like usernames. 
For at least some cases, I believe we've agreed to solve this problem by 
requiring that responses be sent back along the same session as the 
request, eliminating the need to establish an SSH connection in the "wrong" 
direction.  There may be some open issues here; I simply don't recall.

-- Jeff