Subject: additional core draft nits in need of WG attention.

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 10 Nov 2003 02:12:10 -0500

transport draft:

> >5.  Section 4. SSH allows the client and server to employ different
> >algorithms for the data that they encrypt. This practice should be
> >discouraged somewhere in the document.  It is likely to cause
> >interoperability problems, and it offers no security advantage.

[this is section 5 in version -17]

suggested resolution:

immediately after this text:

   The ciphers in each direction MUST run independently of each other,
   and implementations MUST allow independently choosing the algorithm
   for each direction (if multiple algorithms are allowed by local
   policy.

insert:

   Note that there is no security advantage to using different
   algorithms in each direction; implementations SHOULD use the same
   algorithm in both directions when allowed by policy.

> >6.  Section 4.3, second paragraph. The document says: "...effective key
> >length of 128 bits or more". Yet, Triple-DES is the REQUIRED algorithm,
> >and it does not meet this goal.  Suggestion: "...effective key length of
> >96 bits or more".

so, this is a "how do we count the bits" issue.  three-key triple-des
is under some circumstances vulnerable to a particular attack which
takes 2^112 time and 2^112 storage.  It is not clear to me whether
this particular attack is possible against 3des as used by SSH.

Do we:
	- Lower the recommended limit?  (to what? 96 bits? 112 bits?)
	- Explicitly grandfather triple-des?
	- Make AES REQUIRED?

Others:

> >10.  Section 5, last paragraph. What is "implicit server
> >authentication?"  The whole paragraph is unclear.

Can someone provide some fill-in text?

> >13.  Section 6.1.  There is only one Oakley group defined, and it has an
> >equivalent strength of 80-bit symmetric encryption. There should be
> >additional Oakley groups that offer strength commensurate with the other
> >recommendations in the document. The document should explicitly reference
> >RFC 3526, and make use of group 14 (2048 bits).

Any opinions here?  "Use dh-group-exchange if you're paranoid".

draft-ietf-secsh-userauth-17:

> >3.  Section 2, last paragraph. Setting the SHOULD for the timeout to 10
> >minutes seems very long.  Doesn't it open up some denial-of-service
> >attacks. The SHOULD for the timeout ought to be for interoperability.

I'm reluctant to change that.  First, it's a SHOULD, not a MUST..
also, making it too short may cause issues for the handicapped
(consider the combination of slow typing rate and high error rate..)

> >4.  Section 5, last paragraph on page 9.  Saying that UTF-8 is the
> >encoding for passwords means that implementations need to check for valid
> >UTF-8 encoding.  This could lead to unexpected failures. It would be much
> >better to say that passwords are arbitrary binary strings with no
> >specified encoding.  Exact match of the binary strings ought to 
> >be sufficient.

Thoughts?  My understanding is that requesting exact match of
internationalized input is problematic under some circumstances..

					- Bill

---

From: [email-masked] (Niels Möller)
Date: 10 Nov 2003 12:02:48 +0100

I have a few comments, which I'm sending in separate mails.

> > >interoperability problems, and it offers no security advantage.

I don't buy this at all. As for interoperability problems, it's true
that it's a rarely used (and likely not well tested) feature. But
that's about all, implementations must keep separate encryption
contexts and independent NEWKEY key switching anyway, so that they at
the same time must use no encryption on one direction and the
new negotiated cipher on the other.

And no security advantage? The general assertion that there's no
security advantage is false. As always, it's a tradeoff that depends
on lots of circumstances. For example, assume that

  1. The end nodes have constrained cpu capacity.
  2. The intersection of supported ciphers at both ends is { arcfour,
     des3 }
  3. In *one* of the directions, you want to send data at a higher
     rate than can be encrypted with des3 by the particular nodes.
  4. You believe des3 to have better security properties than arcfour.

Then the feasible cipher choices are

  arcfour   arcfour  (arcfour both ways)
  arcfour   des3     (arcfour for the bulk data only)

and the second has a security advantage.

/Niels

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 10 Nov 2003 12:49:13 +0000

> 	- Explicitly grandfather triple-des?

Well my view would be to make AES required,  and 3des recommended or optional.

However I guess there may be some implementors who'd disagree.

Is there any current implementation that _doesn't_ now do AES?

DF

---

From: Markus Friedl <[email-masked]>
Date: Mon, 10 Nov 2003 14:04:07 +0100

> 	- Lower the recommended limit?  (to what? 96 bits? 112 bits?)

please not.

> 	- Explicitly grandfather triple-des?

yes.

> 	- Make AES REQUIRED?

yes, i'd prefer this.

---

From: [email-masked] (Niels Möller)
Date: 10 Nov 2003 17:24:58 +0100

> this particular attack is possible against 3des as used by SSH.

Is it out of the question to say "SHOULD have effective key length of
128 or more", and just note somewhere (DES description, or security
considerations) that there's a known 2^112 attack on des3?

If someone discovers a 2^112 attack (with huge storage requirements)
on some other supposedly 128-bit cipher, what would we do? Probably
note it in the security considerations, and try to add some better
cipher to the list.

> 	- Explicitly grandfather triple-des?

Making aes required seems fine to me, although I'm not sure how that
solves the problem. I don't think we can deprecate des3 at this time,
it's too early to say that aes is more secure than des3.

/Niels

---

From: [email-masked] (Niels Möller)
Date: 10 Nov 2003 17:28:45 +0100

> Can someone provide some fill-in text?

I think it refers to key exchange methods like the ones used in tls
and ssh1, where one party chooses the session key and encrypts it
using the other party's public RSA key. Then you must consider the
remote end unauthenticated until you have verified that she knows the
session key.

Do others share this interpretation? (I'd have to think some more
about the implications to be alble to write any precise text).

/Niels

---

From: [email-masked] (Niels Möller)
Date: 10 Nov 2003 17:31:24 +0100

> Any opinions here?  "Use dh-group-exchange if you're paranoid".

I'd say we should just add the group. The security concerns addressed
are different than for dh-group-exchange, and it's a lot simpler. I
think there were at least a few people in the group that argued for
this addition already when dh-group-exchange was proposed.

/Niels

---

From: [email-masked] (Niels Möller)
Date: 10 Nov 2003 17:36:46 +0100

> (consider the combination of slow typing rate and high error rate..)

I don't think the specification of the timeout is essential at all.
There are lots of other non-standardized authentication timeouts out
there, with login-program, various kinds of http authentication, etc,
and there doesn't seem to be a big problem to leave this to local
policy.

I don't think the DOS issue is particularly relevant, given that
unathenticated users can force the server to perform the cpu-intensive
key exchange protocol.

It's nice with some guidelines in the spec, and ten minutes sounds
reasonable to me. But as far as I'm concernedm it could be degraded to
a RECOMMEND or ripped out totally, if that makes anybody happier.

/Niels

---

From: [email-masked] (Niels Möller)
Date: 10 Nov 2003 17:52:03 +0100

At last, the final comment in this series...

> internationalized input is problematic under some circumstances..

This is confused. For both usernames and passwords, the server have to
massage the input into it's native format (unicode normalization form
C, or latin-1, or whatever) before further processing. The further processing
is then typically lookup in a database (for usernames) and "one-way
encryption" for passwords. In both cases, the operation will typically
fail if the input is not normalized.

Treating usernames and passwords differently makes no sense. Either,
we say that both usernames and passowrds are ascii-only (8-bit
characters could be allowed, with implementation defined meaning, so
that we get a royal mess where users will never know whether or not if
8-bit cahracters will work), or we say that both usernames and
passwords are utf8.

I've argued earlier that the sender of utf8 strings should be required
to normalize them (unicode normalization form C, or nameprep, not sure
what's most appropriate). But I didn't get much support for that, and
then the server MUST do the right thing when converting the strings to
its native format. And if the server does the right thing for
usernames, there's no extra cost in doing the same for passwords.

The goal of the utf8 use is to be able to support scenarios like this:

  * Unix server with usernames and passwords encoded in latin-1 in the
    /etc/passwd file, and running in a latin-1 locale.
  
  * Unix client, also in a latin-1 locale.
  
  * Windows Pocket PC client, which is a native unicode application
    and has never heard of latin-1.

  * The username "Åke Ärlig", which can be encoded in at least 6
    different equally correct ways in unicode as well as in proper
    utf8 without overlong sequences.

If this doesn't Just Work, then the protocol is broken. And it seems
we are asked to break it.

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 10 Nov 2003 18:10:01 -0500

[wg chair hat on]

I see a kernel of consensus building for:
 - leave recommended limit at 128 bits
 - explicitly grandfather 3DES

I have not seen opposition to:
 - add AES as an alternate REQUIRED algorithm.
 - adding RFC 3526's 2048-bit group 14 as diffie-hellman-group14-sha1

Anyone who disagrees with any of the above these proposals should
speak up soon.

[now that I re-read this section of transport-17, we have an editing
glitch]:

   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526]
   (2048-bit MODP Group).  It is included below in hexadecimal and decimal.

And it then specifies the group 1 modulus..

						- BIll

---

From: [email-masked] (Niels Möller)
Date: 11 Nov 2003 11:26:26 +0100

>  - explicitly grandfather 3DES

Exactly what does "grandfather" mean here? Change 3DES from REQUIRED
to RECOMMENDED? Or OPTIONAL? Or DEPRECATED? To me, it makes sense to
keep it as RECOMMENDED.

> And it then specifies the group 1 modulus..

I guess the name for dh with Oakley group 14 would be
"diffie-hellman-group14-sha1". Or should we go for
"diffie-hellman-group14-sha256" while we're at it? Unfortunately,
there's more than one reasonable choice here.

Regards,
/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 11 Nov 2003 10:31:10 -0500

> to RECOMMENDED? Or OPTIONAL? Or DEPRECATED? 

My apologies for using an Americanism here.

"Grandfathering" something means roughly "keep it is, despite not
(precisely) matching the letter of a newer spec/law/regulations/etc,
because we've always done it that way".

So, that would be "keep as REQUIRED".

					- Bill

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Nov 2003 09:27:46 -0800

What Niels said.

Passwords should be UTF-8 encoded.  No stringprep or profile or even
plain Unicode normalization form should be required to be applied by
clients when the server processes a password, but for md5-digest type
algorithms where the client processes the password, then a stringprep
profile MUST be specified.

In the case of "password" and "keyboard-interactive" userauth it's clear
that the server processes the password so no stringprep profile is
needed for the password in "password" userauth or for replies to
"keyboard-interactive" userauth prompts.

Cheers,

Nico

---

From: Jon Bright <[email-masked]>
Date: Tue, 11 Nov 2003 18:42:32 +0100

> "keyboard-interactive" userauth prompts.

Does what you're saying here imply that the client should really be 
required to send a character set string together with the password in 
those situations (such that the server can then make the appropriate 
translations), or have I misunderstood?

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Nov 2003 16:25:05 -0800

> translations), or have I misunderstood?

I'm saying that the client send UTF-8 encoded strings to the server for
these two cases ("password" and "keyboard-interactive" userauth
responses) without applying _any_ string preparation to whatever the UI
interfaces produced as responses typed in by the user.

E.g., if the UI produces decomposed character sequences for, say, Latin
vowels with accents, then that is what the client sends, and if
sometimes the UI produces decomposed sequences and sometimes composed
characters, then that is what the client sends, and if the UI produces
something other than Unicode, then the client will convert to Unicode
before sending and will send whatever its converter produces, and if the
_server_ needs a particular string preparation for passwords, or if it
needs to process only passwords in 8859-1, then the _server_ applies
whatever stringprep profiles/charset conversions/whatever that it needs,
and then processes the password (e.g., hash it then compare it to some
hash).  The client cannot know what preparation the server needs for
passwords sent to the server.

But if the client were doing MD5-Digest authentication (which SSHv2 does
not provide for), then the client would have to know what preparations
to apply to passwords prior to using them with MD5-Digest.

Cheers,

Nico
--

---

From: Markus Friedl <[email-masked]>
Date: Sat, 15 Nov 2003 17:17:45 +0100

>    algorithm in both directions when allowed by policy.

In IPsec the algorithms are unidirectional.  Why
should it be a SHOULD for SSH?