rlm_krb5 hardware preauth

[Benjamin Bennett]

On Wed, 2005-11-23 at 21:33 -0800, Frank Cusack wrote:
> Yes, very bothersome.  Steady progress has been made on making krb5 libs
> thread-safe (and on Solaris they will be thread-safe when they are exposed).
> Use the data arg to the prompter, that's what it's there for, and it's
> trivial to use.

doh! forgot about that little bugger, will do.


> Fix the style -- line length (there's a radlog() call in the prompter
> that needs to have the last arg on a new line; if (foo) not if(foo); etc).
> There's other stuff, but the existing code doesn't have the greatest
> style to begin with so I won't belabor it.

heh, I think there's half the problem, I was trying to follow the style
of rlm_krb5. I'll add some spaces and newlines.


> The part where you copy the password into prompts[0].reply looks broken.
> Maybe I'm wrong; it's been a long time since I've written krb5 code.
> Does the library allocate reply->data for you?  Looks that way.  In
> which case your copy of the password is incorrect, you are copying
> as much space as is allocated in the reply, which could be greater
> (or less) than the length of the password.  If reply->length is greater
> than strlen(password->strvalue), you'll run off of the password buffer
> and possibly segfault.  If lesser, you'll truncate the password.

reply->data is a buffer on pa_sam_2's stack (at least that's where it is
in krb5-1.4.2). reply->length is set to the sizeof that buffer before
calling the prompter function.

I'm copying until the null at the end of user-password, up to a max of
reply->length, to prevent running off the buffer.


> Null termination of reply->data seems incorrect as well.

That null termination ensures that we return with a null terminated
string in reply->data. Usually it would already be null terminated,
except if we hit reply->length (100 bytes in krb5-1.4.2) before the end
of user-password.


> In the new request case, you should set reply->code just before you
> set r, for readability (move the 2 free() statements up).

will do.


> You should have a lot more comments, eg, why 'pass' and password get
> switched up.  More important, why you save the password in the State AVP.

will do.


> Which brings me to my last point, the state isn't adequately protected.
> If I can sit between the NAS and the RADIUS server, and insert packets,
> I can authenticate as another user by waiting for him to authenticate
> and then stealing the State AVP.  Now, I login to the NAS as that user,
> get a challenge from krb5 via RADIUS and when the NAS sends the response
> back, I remove the state and insert the one I stole (from long ago).
> You simply decode the state and accept it as valid.  This allows me to
> login as a user and only have to guess the SAD, without having to know
> the long term password.  Since the SAD data can be trivial to guess,
> (e.g. it is commonly a 6 digit decimal number without any PIN), if
> the krb5 server (or at least this specific user) operates in the modes
> where the password is used along with the SAD (say, because the SAD is
> exceptionally weak), then you've significantly broken things.  If the
> use-sad-as-key mode is used, well then you're fine, but since rlm_krb5
> should be usable for any configuration, it should be fixed.

suggestions?
I'm working with a 4-bytes of SAD w/8 digit pin so I'll admit that I
didn't think about this too much. Are people still using those little
SecurID thingies? ;-)


> Oh, also you'll want to note that the failing of the krb5 auth in order
> to escape the prompter function alters the kdc logs.  There will always
> be at least 2 auth requests for a single TGT return.

There are 2 kdc requests under normal circumstances, such as kinit with
posix prompter.
On the first request the kdc returns hw preauth required, which causes
the prompter function to be called. If the prompter function returns
success, a second request will use hw preauth.

Since the prompter function returns error on initial radius request, we
end up with a total of 3 kdc requests.

The only ways I can think to work around this would require adding state
of these requests to radiusd, which seems like a generally bad idea, or
explicitly telling radiusd which principals require hw auth, which seems
like an admin nightmare. Other ideas?


thanks for your suggestions!

--ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20051124/6972f5c9/attachment.pgp>