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

From: "tom.petch" <[email-masked]>
Date: Tue, 2 Sep 2008 15:18:32 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
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.

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).

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]
?

Tom Petch

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Sep 2008 12:17:52 -0400

--On Tuesday, September 02, 2008 03:18:32 PM +0200 "tom.petch" 
<[email-masked]> wrote:

> 32-character limit for security names, keep that same limit in TSM, and
> arrange for SSHTM to never emit names longer than that."
>

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.

> (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.

> "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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 2 Sep 2008 12:26:38 -0400

Hi,

The character set used for snmpAdminString and the character string
used for SSH user name are consistent. RFC2279 cited for
snmpAdminString and RFC3629 cited for SSH user name are different, but
the changes between 2279 and 3629 were determined to have no effect on
snmpAdminString or SSH user name.

In addition, binary fields required by a specific athentication method
are separate from the user name field in SSH user-auth messages.

>From RFC4252:
" All authentication requests MUST use the following message format.
   Only the first few fields are defined; the remaining fields depend
on
   the authentication method.

      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name in ISO-10646 UTF-8 encoding [RFC3629]
      string    service name in US-ASCII
      string    method name in US-ASCII
      ....      method specific fields
"

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of tom.petch
> Sent: Tuesday, September 02, 2008 9:19 AM
> To: Juergen Schoenwaelder; [email-masked]
> Subject: [Isms] d) was dublin isms meeting minutes
>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 2 Sep 2008 12:39:06 -0400

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

> Behalf Of Jeffrey Hutzelman
> Sent: Tuesday, September 02, 2008 12:18 PM
> To: tom.petch; Juergen Schoenwaelder; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] d) was dublin isms meeting minutes
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Sep 2008 22:24:34 +0200

On Tue, Sep 02, 2008 at 03:18:32PM +0200, tom.petch wrote:
> "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."

The statement d) essentially says that we can assume that SSH gives us
a user name to work with, independent of which user authentication
mechanism is actually used by SSH. This is different form the question
whether an SSH user name can be used directly without a mapping as an
snmpSecurityName.

>From the character set perspective, we seem to be fine with using SSH
user names as snmpSecurityNames. The only problem seem to be length
restrictions. SSH says it is a string, so the architectural limit is
2^32 bytes carrying UTF-8 characters. I am sure implementations will
have much smaller limits. (I just played with my openssh and I got the
impression that it actually silently truncated around some 100 ASCII
characters but I have not verified this. But this limit is if it
exists an implementation limit, not a protocol imposed limit.)

We have (depending on whether the prefix needs to be accounted for or
not) 32 or 28 bytes available, which is not really much. There is a
growing tendency to use email addresses as identifiers for people
(lets not discuss whether this makes sense) and then 28 bytes is
pretty much nothing. The same is true for names written in a script
that requires several bytes per character in UTF8. So it seems we have
to provide an answer what happens if we run into length issues. And
David wants all this to be predictable, that is not implementation and
thus vendor specific.

One potential solution could be an SSHTM mapping table which has the
following properties:

if (matching user name exists in the table) {
    use the associate securityname
} else {
    if (length(user name) < N) {
       use the user name
    } else {
       drop the session and bump an appropriate counter
    }
}

/js (speaking as technical contributor)

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

---

From: "Ira McDonald" <[email-masked]>
Date: Tue, 2 Sep 2008 16:56:28 -0400

Hi,

Further than RFC 3629 is needed, to prevent pesky
security attacks, I think.

RFC 5198 compliant normalization (NFC) of the security
name presented by SSHTM should be REQUIRED.

My two cents,
- Ira

-- 
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: [email-masked]
winter:
 579 Park Place Saline, MI 48176
 734-944-0094
summer:
 PO Box 221 Grand Marais, MI 49839
 906-494-2434
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "tom.petch" <[email-masked]>
Date: Wed, 3 Sep 2008 08:38:28 +0200

----- Original Message -----
From: "Ira McDonald" <[email-masked]>
To: <[email-masked]>; "tom.petch" <[email-masked]>;
<[email-masked]>; "Ira McDonald" <[email-masked]>
Sent: Tuesday, September 02, 2008 10:56 PM
Subject: Re: [Isms] d) was dublin isms meeting minutes

> name presented by SSHTM should be REQUIRED.
Ira

The two passages I quoted without a citation were from the SNMP and SSH
standards respectively, on the limits on 'user names', and I wasn't sure if the
RFC and the two different ISO references were 100% compatible (and if they are,
why do we have two different documents? sigh:-(

I think it difficult to fit RFC5198 into the pre-existing structure of SSH and
SNMP.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2008 11:43:05 +0200

> name presented by SSHTM should be REQUIRED.

I think the SNMPv3 specifications never talk about normalization of
SnmpAdminStrings. So the issue is of much larger scope and to tackle
this, someone needs to write a separate document about UTF-8 string
normalization in the whole SNMP framework. But this then is clearly
not in the scope of ISMS.

All ISMS could do is to require normalization for TSM and SSHTM but
that would not really solve the general problem as long as all other
configuration tables and in particular VACM are agnostic to string
normalization.

Perhaps someone should write a best practices like document that
SnmpAdminString values really should be normalized (but that causes
nasty length changes) or that SnmpAdminString values should be
normalized before any comparisons are done.

/js

---

From: "Ira McDonald" <[email-masked]>
Date: Wed, 3 Sep 2008 12:29:00 -0400

Hi,

Oops - a can of worms here.

Let me clarify, I hope.

The vast majority of uses of SnmpAdminString in IETF and private MIBs
are for simple description objects that need to be internationalized - no
normalization is needed - string comparisons would be a design flaw.

But the Unicode Consortium and others have written extensively about
why *names* (of principals, protocols, etc.) MUST be normalized to avoid
some rather serious security problems.

SSHTM is already constraining SSH usage, so security name normalization
seems appropriate.

Separately (as Juergen has pointed out), the whole use of UTF-8 in VACM
and other MIBs probably needs to be addressed - but changing SNMPv3
was deemed out-of-scope for ISMS - why? - the undeployability of SNMPv3
is the whole point of the ISMS WG, I thought?

Cheers,
- Ira

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 03 Sep 2008 13:25:38 -0400

> some rather serious security problems.

Some of us, at least, understand the issues here quite well and don't need 
them reviewed for us.  However, fixing this problem in either SSH or SNMP 
is simply not in scope for us.

> SSHTM is already constraining SSH usage, so security name normalization

Firstly, no, we're not really "constraining" SSH usage.  We're using SSH, 
but we place no constraints on SSH's choice of algorithms or authentication 
methods, and we make no changes to the SSH protocol.  Making changes to the 
SSH protocol would be out of the scope of both our charter and our 
expertise (while there are some SSH people here, myself included, the WG as 
a whole does not have the right expertise for that).

Now, you could decide to normalize usernames you get out of SSH, but that 
doesn't really solve the problem, because it doesn't address the issue of 
comparisons done inside SSH that affect whether you get in at all.

> is the whole point of the ISMS WG, I thought?

The point of ISMS is to provide the tools needed to integrate SNMP with 
operators' existing security infrastructures.  It is specifically intended 
not to change either SNMP or SSH, but simply to make them work together. 
The goal is to describe how to plug the existing pieces together, not to 
change those pieces to suit our liking.

While, again, we could normalize SNMP security names in the security model 
before passing them along, that wouldn't solve the problem.  It doesn't 
solve the problem because it doesn't fix USM, or other security models, and 
it also doesn't fix the other ways in which VACM gets security names, such 
as via the MIBs that define the access controls it enforces.  In fact, this 
means that not only would normalization in the SM not fix the problem, it 
could actually make it worse.  Suppose you have a SM that normalizes every 
name it sees to NFC, but some operators clients (including those used to 
configure VACM) run on a platform which has input methods that tend to 
produce decomposed forms?  Now the SM's normalization practically 
guarantees that the security names it passes to vacm won't match anything 
in its database.

The answer to this is normalization-insensitive comparison, which is to 
say, normalizing values to be compared at the last possible moment before 
the comparison.  But that has to be done in VACM, and changing the behavior 
of VACM is very much out of scope for this WG, as it should be.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2008 23:45:47 +0200

> normalization is needed - string comparisons would be a design flaw.

SnmpAdminStrings are used as identifiers in several places in SNMPv3
MIB modules and these strings are compared during the processing in
the elements of procedure. Are you saying SNMPv3's usage of UTF-8 is
flawed? Perhaps it is, but to be fair it must be noted that SNMPv3 was
done about 10 years ago and UTF-8 normalization was probably not that
well understood at that point in time.

If SNMPv3's usage of UTF-8 is flawed, someone should write up a
document explaining the issue and proposing ways to fix things and
then it can be discussed if and where in the IETF this work should be
done.  Looking at the current ISMS charter, I don't think ISMS is the
place to do this.

/js

---

From: "Ira McDonald" <[email-masked]>
Date: Wed, 3 Sep 2008 20:32:51 -0400

Hi,

Right - as Jeff and Juergen have said - the topic's out-of-scope.

Perhaps in Security Considerations a one-liner referencing
RFC 5198, UTR36 (Security Considerations), and UTR39
(Security Mechanisms)?

Juergen - Yes - the use of UTF-8 for identifiers without normalization
(in SNMPv3 or anywhere else) is flawed - that's not new news.

Cheers,
- Ira