patch adding none cipher/mac for ssh v2

[Jefferson Ogata]

Douglas E. Engert wrote:
> Jefferson Ogata wrote:
>> J Raynor wrote:
>>> As a final note, I'd like to point out that kerberos allows the user 
>>> to choose whether their session is encrypted or not.  So aside from 
>>> the few people who may have argued the point on the openssh mailing 
>>> lists, there are groups of people out there who want this choice.
>>
>> SSL2 and SSL3 also support a null cipher.
>>
>> Does anyone else see the irony of what's going on here?
> 
> Not really. The Kerberos case and ssl2 or ssl3 with NULL are more
> historical then a current requirment. It comes from when sending
> encrypted data could have been against the law in some places,
> or the need to authenticate but not encrypt was common.
> 
> But today, not only do you have to authenticate, but you need to
> protect the integrity of the session to help avoid hijacking
> as well as protecting the data.

The irony I was referring to has to do with the contrast between the 
vehement support for inclusion of a weak 40-bit cipher in one thread, 
contrasted with the strong disdain for a null cipher, even though a 
number of other products provide a null cipher while none that I know of 
includes the weak 40-bit cipher.

> So why do you need ssh without encryption? Won't telnet or rsh
> do just as well? Most Kerberos shops I know of are turning off
> the Kerberized BSD applications and using ssh with gssapi instead.
> 
> So although I don't see the need for a null encryption, you claim
> there are groups of people out there that want the choice. But Why?

I didn't say I do need it. But I do understand J Raynor's explanation. J 
wants to use ssh authentication without incurring crypto overhead on the 
session; this saves CPU when doing large transfers. This is handy for 
scp or rsync over ssh (I usually use blowfish for this since it seems to 
be the fastest cipher in the suite). J specifically stated that this 
could be used on channels that are already secure, e.g. IPsec or ssh 
tunnels.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>