http://www.garlic.com/~lynn/index.html#aads
AADS radius example
http://www.asuretee.com/
... with FIPS186-2, x9.62, ecdsa digital signature authentication on sourceforce ....
http://ecdsainterface.sourceforge.net/
radius digital signature protocol has replay challenge.
so adding radius option to webserver client authentication stub (infrastructure can share common administration client authentication across all of its environments). then client clicks on https client authentication, generates secret random key, encrypts request for client authentication with random key, encrypts random key with server public key, sends off single transmission. Server responds with radius connect request .... which includes replay challenge value as part of message (encrypted with random key). Client responds with digital signature on the server radius message (and some of its own data, encrypted with random key).
Basically use the same packet sequence as in transaction w/o replay challenge ... since higher level protocol contains replay challenge. Then can use same packet sequence for webserver TLS and encrypted PPP (and works as VPN; possibly can define also as encrypted TCP) .... along with the same client authentication infrastructure
Infrastructure can use the same administration (RADIUS) infrastructure for all client authentication .... say enterprise with both extranet connections as well as webserver .... or ISP that also supplies webhosting. The same administrative operation can be used to support client authentication at the PPP level as well as at the webserver level.
The same packet exchange sequence is used for both PPP level encryption with client authentication as well as TLS for webserver level encryption with client authentication.
The higher level application can decide whether it already has sufficient replay/repeat resistance or request replay/repeat resistance from lower level protocol.
So regardless of TLS, PPP, or TCP, client authentication (using same packet sequence as transaction, w/o lower level replay challenge):
1) client picks up server public key and encryption options (from cache or DNS)
2) client sends of radius client authentication, encrypted with random secret key, encrypted with server public key ...
3) server lower level protocol handles the decryption of the random secret key and the decryption of the client request (which happens to be radius client authentication .... but could be any other kind of transaction request) and passes up the decrypted client request
4) server higher level protocol (radius client authentication) responds with radius replay challenge
5) client gets the replay challenge, adds some stuff, digitally signs it and responds
6) server higher level radius client authentication protocol appropriately processes
Same server public key initial connect code works at TLS, PPP, and possibly TCP protocol levels. The same server public key initial connect code supports both lower-level replay challenge and no replay challenge.
Same radius client authentication works at TLS, PPP, and possibly TCP protocol levels. Same client administrative processes works across the whole environment.
aka .... the radius client authentication protocol is just another example (like the purchasse order example) of the higher level protocol having its own replay/repeat handling infrastructure (whether it is something like log checking or its own replay challenge).
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
