Re: [Isms] d) was dublin isms meeting minutes

[Jeffrey Hutzelman <jhutz at cmu.edu>]

--On Tuesday, September 02, 2008 03:18:32 PM +0200 "tom.petch" 
<cfinss at dial.pipex.com> wrote:

> ----- Original Message -----
> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: <isms at ietf.org>
> Sent: Friday, August 29, 2008 3:44 PM
> Subject: [Isms] dublin isms meeting minutes
>
> <snip>
>
>>    d) We can assume that SSH provides to us a suitable user name
>>     that does not need a specific mapping. For SSH authentication
>>     mechanisms such as GSSAPI, we can assume that SSH internally
>>     maps into a user name that can be used outside of SSH.
>
> This puzzles me.  To quote Jeff from the thread on  'mapping here ...',
>
> "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."
>
> which sounds suspiciously like a requirement for a mapping in SSHTM to me.

Not at all.  It's a requirement for not emitting names longer than 32 
characters.  A mapping might be a way to achieve that, but so is a length 
limitation.  In fact, starting in the very next sentence after that quote, 
I propose a length limit, with longer names being an error.  I also suggest 
that it would be reasonable to allow implementations to provide a mapping 
mechanism.

> In previous discussions on this, it was posited that user names might be
> (lengthy) OIDs or fingerprints and that DOCSIS had particular
> requirements here (not sure what they were).

ssh usernames will never be OID's or fingerprints; they are strings.  If 
another secure transport identifies clients with something more complex 
than a string, then the TM for that transport will need some form of 
transport-specific mapping from those objects to strings that can be used 
as SNMP security names.  For an example, see Wes's DTLS TM.

> And, when this came up before, there were doubts about compatability of
> character set.
>
> I take it that
>
> "         this
>           information is represented using the ISO/IEC
>           IS 10646-1 character set, encoded as an octet
>           string using the UTF-8 transformation format
>           described in [RFC2279]."
>
> is essentially the same as
>
> "user name on the client host in ISO-10646 UTF-8 encoding [RFC3629]
> ?

Yes.  3629 obsoletes 2279.  See RFC3629 section 12 for a list of 
differences.

-- Jeff
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms