Subject: Re: beep+sasl+srp draft issues

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Oct 2001 17:45:26 +0100

Hi Mike,

> As a sysadmin, I'm not all that well versed in hash algorithms.  But if
> the usernames are hashed, doesn't that present the possibility of unique
> usernames generating the same hash key?  Granted, it's probably a remote
> possilibity, but Users will always find a way.

No - hash functions are either collision resistant or broken. Those
that we'd pick aren't broken (hopefully:-), so basically this is one
of those "number of electrons in the universe" things.

> > It didn't require that. The idea was that the client generated the
> > key pair on the fly - the private being stored as an encrypted
> > part of the credential & the public being a clear part of the credential.
> > A client can then sign a credential upload & the server can verify
> > off-of the previous instance of that credential.
> 
> Will PDAs and cell phones, for example, be allowed to upload credentials?

Should be.

> (This would make sense to me--verifying, for instance, what your cell #
> is)  If so, wouldn't this be a bit computationally harsh for them?

You've lost me a bit there - I can see rsa key gen & signing being 
too hard for current pdas, but what was it made sense? Good point
about PDAs though (the PDM scheme wasn't really suited for
constrained devices, as was stated in that draft).

> > Probably can - if you know its name/address and there's no f/w in
> > the way. For someone roaming around inside an intranet both are
> > issues (e.g. when I'm in our Boston office).
> 
> I don't see why this would be a problem.  If the credential server is
> (partially) exposed to the internet, and given a unique name
> (credential-west.radioactivedata.org and
> credential-east.radioactivedata.org, for example, if there are two
> credential servers in a company), how does the firewall get in the way?

Maybe I've just always worked for paranoid organisations, but
I've seen such f/w issues in larger enterprises. On the name thing,
sure, the user can enter the fqdn of the server, but only if
the client s/w allows that and the user knows what it is and
how to enter it etc.

Stephen.

-- 
____________________________________________________________
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

---

From: Mike DeGraw-Bertsch <[email-masked]>
Date: Tue, 23 Oct 2001 15:04:37 -0400 (EDT)

Howdy,

> of those "number of electrons in the universe" things.

Gotcha--thanks.  I really need to read up on all this.

> constrained devices, as was stated in that draft).

I just meant that it would make sense to me that a cell phone or PDA be
able to upload credentials.

> the client s/w allows that and the user knows what it is and

I consider myself excessively paranoid, but if a system is designed to
securely receive and provide credentials, and is designed well, imho it
should be exposed to the world.  Wouldn't that be necessary for someone to
verify credentials in the first place?  Or would verification be open to
the world, but uploads would be restricted?

As for the fqdn and UI, if one can't enter the fqdn, how does one tell
their device what server to connect to?

WRT accessing the credential server, my initial reaction was 'direct
connects, even with firewalls, are easy--use an SSH tunnel.' But that
obviously presents a problem for PDAs, etc...

  Thanks,
 -Mike