Adding a high-security channel for passwords

For password authentication what we really are trying to create
is a more secure encryption method for moving the hashed password
across the wire.

Instead of adding a set of extra fields to the protocol for 
passwords, it seems to make more sense to buind in capabilities 
to send securely-encrypted data of any type.  This could be 
useful for other applications as well, such as credit card 
numbers, non-user-accessible control information, biometric
identification information, etc.  In general, applications 
would probably be free to decide what to use this for.

To do this, another record layer type for application-specific 
control messages would be added.  These messages would be encrypted
with another encryption type defined by the ciphersuite (probably 
128-bit RC4 for exportable ciphersuites and triple DES for secure 
ciphersuites since NSA is afraid of triple DES).  The keys for this
secure channel would be derived independently from the master secret.

These messages would probably consist of some kind of data type
identifier (indicting hashed password, plaintext password, credit 
card number, ATM PIN, etc.), possibly a criticality flag, and the 
message content.  (This still needs to be hashed out, pardon the 
pun.)

I talked with the export office of the NSA today and asked about
this.  In general, they don't seem likely to mind, provided that
applications don't use the secure channel for user data.

Any feedback (to the list) is, of course, appreciated.

-- Paul

_____________________________________________________________________
Paul Kocher            Voicemail: (415) 354-8004, FAX: (415) 321-1483
Cryptography consultant                   http://www.cryptography.com

Received on Tuesday, 6 August 1996 20:17:36 UTC