Multiple Password Prompts

[ragan_davis at colstate.edu]

Thanks for the response.  See below:

----- Original Message -----
From: Alan DeKok <aland at ox.org>
Date: Friday, August 5, 2005 11:03 am
Subject: Re: Multiple Password Prompts

> ragan_davis at colstate.edu wrote:
> > As I'm troubleshooting this, I generated another question in my 
> head.  
> > This time I'll give some freeradius debug (see blocks 
> > between "*********"):
> > 
> > Here's an exerpt from first try (failure):
> ...
> > Sending Access-Challenge of id 186 to 192.168.3.2:1024
> 
>  That doesn't look like a failure to me.  The supplicant may stop
> talking to the server, and start a new session, but the server thinks
> everything's OK.
> 

Sorry...maybe I used the wrong word.  By "failure", I meant that from
the end user's perspective, the first attempt was a failure.

If the server get's an incomplete reply to it's challenge, or no reply,
will it resend it's challenge?  Or, will the client sense that the
server didn't respond to it's challenge response and start a new
session.  I ask because, in talking to the vendors, there is a question
of which side is giving up, or which side isn't sending complete
requests/responses.  Of course, because each vendor has their own radius
server and 802.1x client solution, they want to blame freeradius so that
I'll buy their product.  I'm trying my hardest to fight this, because
I'm a big freeradius fan.

The debug on the Odyssey Client shows that it believes it sent the
response to the challenge.  The debug on the WLAN switch shows that it
forwards both the challenge from freeradius and the challenge response
from the client.  Freeradius debug appears to get the response from the
client, sees the outer credentials (anonymous, etc.), but doesn't
process the tunneled information for some reason. 

> > I looked back through some of the output, and it seems that each 
> time 
> > it fails I get "eaptls_process returned 13", but when it is 
> succeeds I 
> > get "eaptls_process returned 7".  Anyone know what 7 and 13 
> represent 
> > (please don't say 'sucess' or 'failure'...i'm hoping it more 
> > meaningful than that).
> 
>  From src/modules/rlm_eap/types/rlm_eap_tls.h:
> 
> typedef enum {
>        EAPTLS_INVALID = 0,          	/* invalid, don't reply */
>        EAPTLS_REQUEST,               	/* request, ok to send, 
> invalid to receive */
>        EAPTLS_RESPONSE,               	/* response, ok to receive, 
> invalid to send */
>        EAPTLS_SUCCESS,               	/* success, send success */
>        EAPTLS_FAIL,               	/* fail, send fail */
>        EAPTLS_NOOP,               	/* noop, continue */
>        EAPTLS_START,               	/* start, ok to send, invalid 
> to receive */
>        EAPTLS_OK,                  	/* ok, continue */
>        EAPTLS_ACK,               	/* acknowledge, continue */
>        EAPTLS_FIRST_FRAGMENT,    	/* first fragment */
>        EAPTLS_MORE_FRAGMENTS,    	/* more fragments, to 
> send/receive */
>        EAPTLS_LENGTH_INCLUDED,          	/* length included */
>        EAPTLS_MORE_FRAGMENTS_WITH_LENGTH,   /* more fragments with 
> length */
>        EAPTLS_HANDLED                  	/* tls code has handled it */
> } eaptls_status_t;
> 
>  So I don't see any particular reason why one session would succeed
> and the other would fail.
> 

So, does this mean that I should interpret the above enum to have
elements 0-13, or 1-14, and match the numbers 7 and 13 with it's
position in the enum?

> > Also, anyone know what the rlm_eap_tls messages mean that accompany
> > the 'returned 13' block?
> 
>  Information about internal TLS stuff.  There are a *lot* of TLS
> packets that go back and forth.
> 

I'm curious why we can see the TLS stuff during the first try (13), but
not the second try (7).  What is the difference?  I agree...it seems
like there should nothing different between what the client sends in the
first try and the second.

>  At this point, the only thing I can suggest is to put a packet
> capture on the net somewhere.  That might give more information.
> 

I performed a packet capture using ethereal, listening on the interface
that freeradius is running on.  Did this on the box, not inline.  I
would rather not post it to the list, but I'd be glad to send it to you
if you'd be willing to look at it.  Let me know.

>  Alan DeKok.
> 
> - 
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html