Re: beep+sasl+srp draft issues

Howdy,

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

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

> > > 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).

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

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

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