DJ Browne wrote:
>
> Hi Tom,
>
> very clever to bridge from the TLS negotiation to the SRP negotiation.
> this isn't part of any spec/draft that I remember reading so far, have I
> missed that somewhere?
http://www.ietf.org/internet-drafts/draft-altman-rfc2944bis-00.txt
> My real concern is that there may be some problem using User authentication
> material (name/passwd) for generating shared secret material for the secured
> TLS session. This is really just a hunch or gut feeling that security is
> somehow lessened by basing it on such a small amount of secret data
> (name/passwd). I know that SRP uses random data and both sides generate
> some data for the session that will be cleanly destroyed. I just help
> thinking that this becomes less secure (though really nice and easy for use
> and development and admin!) than using a client key pair. Am I way off
> base?
Your gut feeling is correct for older C/R-style protocols that aren't
designed to protect low-entropy passwords. SRP, along with other strong
password protocols like SPEKE and PAK, is specifically designed to
generate a large session key from a small password, and do so in a way
that is cryptographically secure (e.g. passwords are infeasible to
brute-force even if the attacker has both passive/active access to the
network, forward secrecy prevents a password compromise from
compromising session keys, and vice versa.)
> Later,
> dj
>
> ps...so when SRP appears in a ciphersuite the telnet can the assume that the
> user has been authenticated properly just by virtue of there being a secured
> channel (a la TLS) - at that point the user can just be logged right in - is
> that correct? very cool.... Kerberos allows auth as one name and login as
> another account...that seems like it might be possible here too...I really
> liked that feature. :)
Since SRP is implemented simply as an improved password-file format on
the server end, there is no reason to have the SRP username be anything
but the user's actual username on the target host. There is no central
authority with an independent user namespace that would need mapping to
"local" usernames. But if there's a demonstrated need for this kind of
functionality I'll consider adding it.
> --
> Derek J. Browne
> [EMAIL PROTECTED]
>
--
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg? Sounds Swedish..."
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
