W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

Adding a high-security channel for passwords -Reply

From: Baber Amin <Baber_Amin@novell.com>
Date: Wed, 07 Aug 1996 02:22:22 -0600
Message-Id: <s20806e3.034@novell.com>
To: pck@netcom.com, ietf-tls@w3.org
The idea sounds good, but if you offer good encryption for authnetication,
can we absolutely gaurentee that it would not be used for user data
other than pin or hashed password.  
Do we even need to hash the password if it is being sent in a secure
fashion.  
How about a password based challenge responce mechanism to thwart
replay attacks.
i would aslo have questions regarding the shared secret that is
generated to send the password.  How securely is the shared secret
master seed transmitted?

Just some thoughts
:)

Baber Amin
SoftWare Eng.
Novell Inc.
Email: Baber_Amin@Novell.com
x.400: C=US;A=TELEMAIL;P=WPCORP;O=CORP
IMX  : USWPCBAM@IBMMAIL
801-861-5285
801-376-3921

--------------------------------------------------------------------
I tried to find Him on the Christian cross, but He was not there;
I went to the Temple of the Hindus and to the old pagodas,
but I could not find a trace of Him anywhere.
I searched on the mountains and in the valleys, but neither in the
heights nor in the depths was I able to find Him.
I went to the Kaaba in Mecca, but He was not there either.
I questioned the scholars and philosophers but He was beyond
their understanding.
I then looked into my heart and it was there where He dwelled
That I saw Him;

Jelaluddin Rumi
--------------------------------------------------------------------




>>> Paul C. Kocher <pck@netcom.com> 08/06/96 06:18pm >>>


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 Wednesday, 7 August 1996 17:03:04 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:51 EDT