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

["David Harrington" <ietfdbh at comcast.net>]

Hi,

The (two-way) mapping should be predictable so operators can know what
values to SET (or otherwise configure) into MIB modules such as the
RFC3413 MIB modules, the VACM tables, the EVENT-MIB, the DISMAN-MIB,
etc. for use with incoming or outgoing messages.

Preferably, the predictability should be consistent across
implementations.

Therefore, allowing implementation-specific mapping mechanisms would
seem to be problematic if the resultant mappings would be inconsistent
across implementations.

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Jeffrey Hutzelman
> Sent: Tuesday, September 02, 2008 12:18 PM
> To: tom.petch; Juergen Schoenwaelder; isms at ietf.org
> Cc: jhutz at cmu.edu
> Subject: Re: [Isms] d) was dublin isms meeting minutes
> 
> --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
> 

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