Subject: augmented/basic

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Apr 2001 13:09:49 +0100

Radia,

Thanks for the nice description of the augmented/basic difference, just to 
check I've got your argument:

- augmented means that even with the server DB, you have to mount
  an offline dictionary attack to get a password
- for sacred, augmented is unimportant since the only thing we're 
  protecting is already in the server's DB (i.e. the credential)
- only the Ford/Kaliski scheme does better (using separate 
  servers), but you think that should be out of scope for comms
  & possibly IPR reasons

I'm not sure I buy it entirely. I can well imagine implementations which
have fairly strong separation between the long-term storage of Y and the 
password equivalent or verifier (and where the long-term stored data is 
separately encrypted). I'd buy the argument if you're assuming that the 
attacker can compromise the run-time credential server, but that seems
like more work than just getting the server's DB.

OTOH, if no-one is actually claiming that we benefit from an augmented 
scheme...

Stephen.

> ************************************************************************
> * Why the augmented property is not important for credentials download *
> ************************************************************************
> 
> All of the schemes (basic and augmented) store a credential Y, such as
> the user's private key encrypted with a password. They also store
> something with which to parameterize a Diffie-Hellman exchange and
> come up with a strong secret, which will be used to encrypt Y and
> send it to the client.
> 
> In mutual authentication, if you stole the server database with a "basic"
> scheme, you'd be able to impersonate the user. But for credentials
> download, the PURPOSE of the exchange is to establish a strong secret
> with the server so it can send you Y. If you've stolen the server
> database, you already have Y! So there's no reason to
> bother impersonating the client with a sacred-style protocol in order
> to have it securely send you Y, when you already have Y!
> 
> Hope this is intelligible.
> 
> Radia

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com