Re: SecretAgent.GetSecrets() return value

[Dan Williams <dcbw redhat com>]

On Tue, 2011-09-06 at 23:27 +0100, Daniel Drake wrote:
> On Tue, Sep 6, 2011 at 11:20 PM, Dan Williams <dcbw redhat com> wrote:
> > Like you say if a secret is wrong or needs to be changed, there's no
> > facility to ask for that secret.  We can (and should) make sure NM would
> > fail the connection with a NM_DEVICE_REASON_NO_SECRETS or something like
> > that if NM can find out the secrets are wrong, which could trigger the
> > applet to toss up the "your connection failed, please re-enter your PSK"
> > dialog or whatever.
> >
> > Or, if you use a secret agent, NM will ask for the secrets when it
> > thinks it needs them.
> 
> I think I'll go with the secret agent option for now, as it doesn't
> require immediate NM work, and as you say, it is quite easy to morph
> the NM-0.8 implementation into a SecretAgent, and it really doesn't
> need much code (only GetSecrets). I think this may even be the more
> simplistic option, as it offloads all the tricky "do I need secrets
> right now?" logic to NM.
> 
> > Return value should be a hash table of hash tables (basically an
> > NMConnection of only the secrets), so for example if you're returning a
> > WPA-PSK connection's secrets, it would be simply:
> >
> > wsec = { 'psk': 'some-really-secure-psk' }
> > hash = { '802-11-wireless-security': wsec }
> > return hash
> 
> Thanks for the clarification.
> 
> What would happen if a WEP connection was originally added with
> auth-alg='open', but then in my GetSecrets response, I give:
> 
> wsec = { 'wep-key0': 'some-unsecure-key', 'auth-alg': 'shared' }
> hash = { '802-11-wireless-security': wsec }
> 
> Would NM then use shared or open authentication?
> ('shared' is what would be desired, for the context of this see
> http://mail.gnome.org/archives/networkmanager-list/2009-December/msg00018.html
> )

At this time you have to know the authentication mode when creating the
connection the first time as connection details cannot be changed inside
a GetSecrets request.  What I'd rather do here is to make NM retry with
open if shared fails the first time or something like that (some drivers
already did that in the kernel) and try to paper over the shared/open
problem instead of making users select it.  These days I don't think
it's really useful to have a specified WEP auth algorithm.

Long ago I had a conversation with a guy that wrote the original Apple
Airport wifi bits and he said they just tried Shared first and if that
failed fell back to Open System, and that's how they were able to figure
out that the WEP passphrase/key was wrong (if the AP supported shared)
so quickly in some cases, because with Shared Key the auth step will
actually fail.  Using Shared Key is trivially crackable (like less than
a minute on a low-end machine these days) so I think we've come to the
point where we might just try shared first all the time, and those
people still using WEP can just deal with the insecurity since WEP is so
broken in the first place.

The tasks here would be to (a) deprecate the auth mode property and
remove code touches it, (b) make sure the supplicant can give us
accurate error information when things fail (I was working on this
recently, it's fairly easy to do), and (c) factor those failure
notifications into the association process so we try a different auth
mode.  Or, even better perhaps, modify the supplicant to do the retry
stuff if the first attempt fails and then NM doesn't have to deal with
it at all; the magic just happens.

Dan