Re: [stellation-res] why doesn't stellationd require a "password" argume

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Monday 22 July 2002 10:54 am, Florin Iucha wrote:
> On Mon, Jul 22, 2002 at 10:24:25AM -0400, Mark C. Chu-Carroll wrote:
> > > For a small setup, sending passwords around is OK. If they want more
> > > security than that, they can set up kerberos and use its
> > > ticket-granting capabilities.
> >
> > Ideally, I'd like to be able to do a challenge auth without having
> > to install kerberos. I'm just downloading and printing JAAS docs now:
> > how hard would it be to add a challenge auth module to JAAS?
>
> If by "challenge auth" mechanism you mean "disposable passwords" then it
> would not be hard at all.
>
> Do you have the "challenge auth" documented somewhere? I assume it is
> something like this:
>    - user accesses resource
>    - system prompts for password or disposable password
>    - user enters password
>    - system validates password
>    - if password bad, make loud buzz. stop
>    - system generates disposable password and hands back to the user
>    - user accesses resource
>    - system asks for password or disposable password
>    - user provides disposable password
>    - system grants access to resource
>
> Am I close?

Not really, if I'm understanding what you mean by one-time passwords.
Challenge auth is a fairly standard authorization mechanism 
for verifying that two entities have a common secret, without
ever revealing that secret. We're using a version loosely
based on HTTP challenge authentication. (The HTTP authentication
spec is the best overview of the general idea; the code in the Engine
class has documentation of the Stellation version.)

The basic way that it works is:
- The client announces that it would like to access a resource
  requiring authentication.
- The server responds by sending a random challenge string (called
  the nonce) to the client.
- The client responds to the challenge by generating its own random
  string (the cnonce), and sending a hashcode to the server, which was
  generated from some concatenation/transformation of the nonce,
  the cnonce, the users password, and some other stuff.

In stellation, it's an MD5 checksum for nonce:password:cnonce. For
HTTP authentication, it's a bit messier; if I recall correctly, they
do a double MD5, where they first get an MD5 checksum for
the username and password, and then create a string of the
nonces, that first MD5, and the URI of the resource being authed
against, and get an MD5 sum for that, and *that*' is the challenge
result.

	-Mark


-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx