Subject: [Isms] #32: is the securityName=username default OK?

From: "David B Harrington" <[email-masked]>
Date: Thu, 13 Oct 2005 18:09:56 -0400

#32: For an incoming message, is using a default securityName mapping
the right thing to do?

David Harrington
[email-masked]

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Oct 2005 07:50:03 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> #32: For an incoming message, is using a default
    David> securityName mapping the right thing to do?

Can you explain this in more detail?

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 24 Oct 2005 10:35:17 -0400

Hi,

The issues I presented are all related to discussion needed to
complete specific sections of draft-ietf-isms-secshell-00.txt.

To understand the context of issue #32, search for "[discuss] #32" in
the document; to understand the context of other issues, substitute
the chosen issue # in your search pattern. I think that may answer
many questions.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Monday, October 24, 2005 7:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] #32: is the securityName=username default OK?
>

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 24 Oct 2005 10:58:52 -0400

Hi,

This issue is related to the "Elements of Procedure" in
draft-ietf-isms-secshell-00.txt section 5.7, step 10).

Following the elements of procedure of USM as closely as reasonable,
the text says the mapping from the SSH authentication-method-specific
tmSecurityName to a model-independent securityName should be contained
in the Local Configuration Datastore (LCD):

"10) Information about the value of tmSecurityName is extracted from
   the Local Configuration Datastore (LCD) to provide conversion from
   the SSH authentication-method-specific tmSecurityName to a model-
   independent securityName."

However, we are attempting to eliminate the need for lots of
preconfiguration, so we may want to define a default mechanism for
algorithmically determining the mapping to securityName. Therefore
section 10) has some default logic (I've added some clarifications in
[] markers):

   "If no information is available for the username in the LCD, then
the
   securityName is set to the username associated with the session.
   Note that USM at this point would return an unknownSecurityName
error
   to the caller, because [USM] didn't automatically assign a
securityname
   from the model-specific parameters.  The message should never reach
   us if it didn't pass [client] authentication [during session
establishment], so tmSecurityname should always
   be present [in the session information]. "

So, if the mapping between a mechanism-specific "username" and a
corresponding securityname is not explicitly specified in the Local
Configuration Datastore, then is setting securityName to the username
(tmSecurityname) associated with the session the right thing to do?

David Harrington
[email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Oct 2005 11:14:23 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> So, if the mapping between a mechanism-specific "username"
    David> and a corresponding securityname is not explicitly
    David> specified in the Local Configuration Datastore, then is
    David> setting securityName to the username (tmSecurityname)
    David> associated with the session the right thing to do?

On the ssh server, probably yes.

On the ssh client, probably not.

My answers to #8 expand on the issues involved here.