How effective is open source crypto? (aads addenda)

[Anne & Lynn Wheeler]

we did something similar for AADS PPP Radius
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 majordomo at wasabisystems.com