Re: More TLS-PSK issues

Stephen Hurd <[email protected]> writes:

>So, it appears that the documentation is wrong where it states that "Once a
>client has authenticated themselves using a shared key, you can determine
>their identity by reading back the CRYPT_SESSINFO_USERNAME attribute".
>
>After a session is established, reading CRYPT_SESSINFO_USERNAME appears to
>always return the first added valid username, even if a private key was added
>and TLS-PSK wasn't even used.  Looking at the code, I'm not sure exactly where
>the old CRYPT_SESSINFO_USERNAME attribute should be deleted and when the one
>that was used should be added... the issue would likely be simplified by
>using a different attribute for valid usernames vs the authenticated username.

Thanks, I'll look into this a bit further.  This bit of the manual was copied
from what the SSH code does, but the TLS-PSK code was changed later to not
quite do the same thing.  What should happen is that the attribute cursor gets
moved to the username that was authenticated, the SSH code does this but not
the current version of the SSL code.

Peter.

_______________________________________________
Cryptlib mailing list
[email protected] via Mail: [email protected]
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.