[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-cryptoapi
Subject:    Re: client authentication
From:       John Boyer <jboyer () UWI ! COM>
Date:       1999-03-29 18:11:52
[Download RAW message or body]


Hi Denis,

Keeping rS around certainly won't hurt, and you can play up your FIPS
compliance, but in the original context:

>the context is such: we have a server and a client, where an SSL session
>between the server and the client is already established via CryptoAPI and
>all we have to do is to authenticate the client. Because there's an SSL
>session going on, we already have a secured channel and we trust the
>server's identity; we only have to find out if the client really is who he
>claims to be.

rS is not necessary.  If the server only has rC, the signature on rC and the
client certificate, then the certificate validity establishes who did the
signing, and the verification of the signature on rC that the corresponding
private key was actually used.  This is more information than just
validating that the certificate is real.  This is exactly what you need and
is unassailable to the extent that digital signatures and SSL are secure.

As for a possible weakness in SSL, if the eavesdropper can decode enough to
perform a replay attack, then the eavesdropper can decode anything in the
session.  So, if you are performing client authentication for the purpose of
verifying a person's identity before exchanging confidential information,
then your system will not survive a weakness in SSL because your system is
for authentication not confidentiality of information transmitted after
authentication.  Further, the eavesdropper doesn't even need to do a replay
to receive the confidential information, so whether or not you use rS is
immaterial.

Preventing a replay prevents the eavesdropper from replaying a transaction
request, like a purchase order.  So, if you don't care about the
confidentiality, but you do care about preventing replay, then your method
is helpful.  However, since replays can be prevented without SSL, I assumed
that it's actually the confidentiality you wanted.  As such, if SSL breaks,
you're hooped regardless of your authentication method.

In conclusion, then, your system in the given context is as secure as SSL
and the digital signature algorithms, which is what you really wanted to
know.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

-----Original Message-----
From: denis bider <denisb@INAME.COM>
To: CryptoAPI@DISCUSS.MICROSOFT.COM <CryptoAPI@DISCUSS.MICROSOFT.COM>
Date: Sunday, March 28, 1999 10:01 AM
Subject: Re: client authentication


>> It doesn't seem to be necessary for the server to send rS?
>>
>> We are saying, in notation, that we want the client to generate a message
>> and sign it.  The authentication actually comes from the the certifying
>> authority's signature on A(C).
>
>Hm. An interesting note.
>
>The reason why rS is there in the first place is that, if only the client
>participated in generating the data to be signed, an eavesdropper could
>obtain the data flow of one such transaction and later use it to masquerade
>as the client (the replay attack). It is true that, in this case, an SSL
>link has already been established to prevent an eavesdropper to gather the
>necessary information at all.
>
>But still, maybe in 5 years a vulnerability of SSL will surface, and then
>someone will be able to decrypt a session that happened years ago. Or maybe
>someone is able to monitor the data flow unencrypted somewhere between the
>SSL and the application layer.
>
>So, since the server generating an rS doesn't do any harm, I think it's ok
>to keep it. What do you think?
>
>denis
>
>----------------------------------------------------------------
>Users Guide http://www.microsoft.com/workshop/essentials/mail.asp
>contains important info including how to unsubscribe.  Save time, search
>the archives at http://discuss.microsoft.com/archives/index.html
>

----------------------------------------------------------------
Users Guide http://www.microsoft.com/workshop/essentials/mail.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

[prev in list] [next in list] [prev in thread] [next in thread]