![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
I originally sent this to the I-D author but have not recieved a response in the interim. Reflecting further, I thought that perhaps the list would know the answer, thus this email. :) Thanks, --nwf; ----- Forwarded message from Nathaniel W Filardo <nwf at masters13.cs.jhu.edu> ----- Date: Sat, 26 Jul 2008 06:12:41 -0400 From: Nathaniel W Filardo <nwf at masters13.cs.jhu.edu> To: badra at isima.fr Subject: draft-badra-tls-password-ext and challenge/response schemes User-Agent: Mutt/1.5.17 (2007-11-01) Salutations. I was thinking about how to secure TLS with S/Key and wasn't able to find an immediate solution (though if you know of one, it could render my question moot). I happened across your Internet Draft and, after reading through it, I wondered if changing > Servers that receive an extended hello containing a "password" > extension MAY agree to authenticate the client using passwords by > including an extension of type "password", with empty > "extension_data", in the extended server hello. to allow servers to specify some kind of textual data in the "extension_data" field would be sufficient? The server could then provide, e.g., the S/Key challenge to the client this way. Is this a silly thought? Thanks much for your time. --nwf; ----- End forwarded message -----
Attachment:
pgpmA7dIVj3b3.pgp
Description: PGP signature
_______________________________________________ TLS mailing list TLS at ietf.org https://www.ietf.org/mailman/listinfo/tls