Re: core draft issue resolution

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

On Tue, 9 Nov 2004, Bill Sommerfeld wrote:

> ticket 454: explicitly grandfather 3DES
> 	Editor to insert text equivalent to:
>
> 	NOTE: There is a known attack on 3-key 3DES involving
> 	2^112 space and 2^56 time; however, for the purposes of this
> 	requirement 3DES is considered to be strong enough.

Is there a name and reference for that attack?  Also, I had thought that
the reason for keeping 3DES was that it is the "interoperable" algorithm.
As such I was going to use the following text:

   The "3des-cbc" cipher is three-key triple-DES
   (encrypt-decrypt-encrypt), where the first 8 bytes of the key are
   used for the first encryption, the next 8 bytes for the decryption,
   and the following 8 bytes for the final encryption.  This requires 24
   bytes of key data (of which 168 bits are actually used).  To
   implement CBC mode, outer chaining MUST be used (i.e., there is only
   one initialization vector).  This is a block cipher with 8 byte
   blocks.  This algorithm is defined in [FIPS-46-3].  Note that this
   algorithm does not meet the specifications that SSH encryption
   algorithms must use keys of 196 bits or more.  However, this
   algorithm is still REQUIRED for historical reasons; essentially, all
   known implementations at the time of this writing support this
   algorithm, and it is commonly used because it is the fundamental
   interoperable algorithm.  At some future time it is expected that
   another algorithm, one with better strength, will become so prevalent
   and ubiquitous that the use of "3des-cbc" will be depricated by
   another STANDARDS ACTION.

Does this work?

>
> ticket 464: utf8:
> 	utf8 requires input canonicalization; stringprep of usernames
> 	and passwords was previously solved by SASL in
> 	draft-ietf-sasl-saslprep-10.txt (in RFC Editor Queue, EDIT state)
>
> 	Rather than reinvent the wheel, just cite it.


How about this:

   Note that the 'plaintext password' value is encoded in ISO-10646
   UTF-8.  This encoding MUST be performed canonically as described in
   [RFC9999].  It is up to the server how it interprets the password and
   validates it against the password database.  However, if the client
   reads the password in some other encoding (e.g., ISO 8859-1 - ISO
   Latin1), it MUST convert the password to ISO-10646 UTF-8 before
   transmitting, and the server MUST convert the password to the
   encoding used on that system for passwords.

[RFC9999] is a placeholder for "SASLprep: Stringprep profile for user
names and passwords".


Thanks,
Chris