Re: Authenticated cipher modes

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <002d01c5443b$fd4df0f0$5c8be5a9%ohr.berkeley.edu@localhost> you write:
>As a more general solution to this problem, how about an ability to
>renegotiate methods?

We already have that to a large extent.  Either end can send a KEXINIT at
any time apart from during key exchange, and negotiate a different set of
settings from last time, and this could actually be used to accomplish what
you want:

client enc: helix%bjh21.me.uk@localhost,3des-cbc
       mac: hmac-sha1
server enc: helix%bjh21.me.uk@localhost,3des-cbc
       mac: hmac-sha1
< both notice that this is silly >
client enc: helix%bjh21.me.uk@localhost,3des-cbc
       mac: none,hmac-sha1
server enc: helix%bjh21.me.uk@localhost,3des-cbc
       mac: none,hmac-sha1

My worry here is that this kind of renogotiation opens up the possibility of
the two ends getting into a loop, with one end thinking it can do better
after each negotiation.

>If the client notices that there's a common cipher
>available that allows for data integrity, it can send a new KEXINIT
>requesting just that cipher and a mac of 'none'.  The server could then
>respond with it's own KEXINIT which agrees with that request, or perhaps
>another response rejecting the renegotiation (a KEXINIT with empty methods
>would probably suffice for an explicit rejection).

Is this actually necessary?  In the example above, the server could reject
the overture by just sending the same KEXINIT it sent the first time.

>If the server never
>sends a KEXINIT in response then it can just be assumed by the client that
>renegotiation is not supported.

All servers are already required to support it.

>This way, not only is the specific case being discussed covered, but so are
>other edge cases (perhaps a session wants compression off initially--for an
>interactive terminal-- Then on later for a large file transfer).

2005-04-18 20:05:55	Server version: SSH-1.99-OpenSSH_3.8.1p1 Debian-8.sarge.4
2005-04-18 20:05:55	We claim version: SSH-2.0-PuTTY_Local:_Apr_18_2005_20:04:17
...
2005-04-18 20:06:13	Initiating key re-exchange (compression setting changed)
2005-04-18 20:06:13	Doing Diffie-Hellman group exchange
2005-04-18 20:06:13	Doing Diffie-Hellman key exchange
2005-04-18 20:06:14	Initialised AES-256 SDCTR client->server encryption
2005-04-18 20:06:14	Initialised HMAC-SHA1 client->server MAC algorithm
2005-04-18 20:06:14	Initialised zlib (RFC1950) compression
2005-04-18 20:06:14	Initialised AES-256 SDCTR server->client encryption
2005-04-18 20:06:14	Initialised HMAC-SHA1 server->client MAC algorithm
2005-04-18 20:06:14	Initialised zlib (RFC1950) decompression

-- 
Ben Harris