Josh Howlett wrote: ...
Sending Access-Challenge of id 3 to x.x.x.x port 1812
MS-CHAP2-Success =
...
EAP-Message =
...
That looks like a bug to me. It's a violation of RFC2548:
No. The bug is different: EAP-MSCHAPv2 is *not* MS-CHAPv2. The MS-CHAP2-Success attribute has no business being in *any* packet that also contains EAP. I've committed a fix for that to CVS head.
How and when do I get this fix Also does thi fix the reply as type Access-Accept instead of Access-challenge
Alan DeKok. - List info/subscribe/unsubscribe? See * http://www.freeradius.org/list/users.html*<http://www.freeradius.org/list/users.html>
Alan DeKok Wrote:
No. The bug is different: EAP-MSCHAPv2 is *not* MS-CHAPv2.
The MS-CHAP2-Success attribute has no business being in *any* packet that also contains EAP. I've committed a fix for that to CVS head.
Thank you verymuch for the response
How and when do I get this fix
Also does this fix the reply as type Access-Accept instead of Access-challenge or am I interpretting this also wrong
Indi
-
List info/subscribe/unsubscribe? See *http://www.freeradius.org/list/users.html*<http://www.freeradius.org/list/users.html>
indira kolli wrote:
>> Thank you verymuch for the response
How and when do I get this fix
The web site contains instructions for obtaining code via CVS.
>> Also does this fix the reply as type Access-Accept instead of Access-challenge or >> am I interpretting this also wrong
You are interpreting it wrong. I said that the MS-CHAP2-Success attribute does not belong. I did *not* say that the packet should be Access-Accept instead of Access-Challenge. Alan DeKok.
Hello Alan, What is the expected callflow for EAP-MSCAHPv2 Access-request Access-Challenge Access-request Access-Accept Why am I getting Access-challenge again ..Indi On Jan 16, 2008 10:30 AM, Alan DeKok <aland@deployingradius.com> wrote:
indira kolli wrote:
>> Thank you verymuch for the response
How and when do I get this fix
The web site contains instructions for obtaining code via CVS.
>> Also does this fix the reply as type Access-Accept instead of Access-challenge or >> am I interpretting this also wrong
You are interpreting it wrong. I said that the MS-CHAP2-Success attribute does not belong. I did *not* say that the packet should be Access-Accept instead of Access-Challenge.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
indira kolli wrote:
What is the expected callflow for EAP-MSCAHPv2
Read the specification, or the source code.
Access-request Access-Challenge Access-request Access-Accept
Why am I getting Access-challenge again
You're not saying which supplicant you're using. Let me guess: you're writing your own, and trying to debug it using FreeRADIUS. If that's true, I suggest that you go read the wpa_supplicant source code. It implements EAP-MSCHAPv2 correctly. If you're not writing your own supplicant, then the server is working correctly. You may be surprised that more than one Access-Challenge is being sent, but that is the Way It Works. If you care to know why, go read the source code in rlm_eap_mschapv2.c Alan DeKok.
Hello Alan, I finally got it working. I missed the reply to the second access-challenge. One thing I am still not sure is about MPPE keys. For us we are using only EAP-MSCHAPv2 without peap. The authenticator needs the MPPE keys to authenticate the peer. But in the EAP-MSCAHPv2 Access-Challenge or Access-accept don't see the keys. I see that the keys are generated for MSCHAPv2 but are deleted before the request is sent. Help is very much appreciated. Thank you Indi On Jan 16, 2008 12:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
indira kolli wrote:
What is the expected callflow for EAP-MSCAHPv2
Read the specification, or the source code.
Access-request Access-Challenge Access-request Access-Accept
Why am I getting Access-challenge again
You're not saying which supplicant you're using.
Let me guess: you're writing your own, and trying to debug it using FreeRADIUS. If that's true, I suggest that you go read the wpa_supplicant source code. It implements EAP-MSCHAPv2 correctly.
If you're not writing your own supplicant, then the server is working correctly. You may be surprised that more than one Access-Challenge is being sent, but that is the Way It Works. If you care to know why, go read the source code in rlm_eap_mschapv2.c
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
indira kolli wrote:
I finally got it working. I missed the reply to the second access-challenge.
How could you possibly miss that? If you're using a standard supplicant, that packet should be about 1/10 of a second after the first one.
One thing I am still not sure is about MPPE keys. For us we are using only EAP-MSCHAPv2 without peap. The authenticator needs the MPPE keys to authenticate the peer. But in the EAP-MSCAHPv2 Access-Challenge or Access-accept don't see the keys. I see that the keys are generated for MSCHAPv2 but are deleted before the request is sent.
Perhaps you could try reading my messages. You were already told that EAP-MSCHAPv2 does not generate the MPPE keys. Even if you changed the server source code, the AP's wouldn't look for the MPPE keys. Even if you fixed the AP's, the supplicants wouldn't use encryption for the wireless links. And you haven't said if you're using this for wireless or wired authentication. I think you're really not clear on what you want to do, how the equipment works, and how the protocols work. I suggest spending time reading more AP documentation before asking EAP-MSCHAPv2 questions on this list. The problem is NOT EAP-MSCHAPv2. The problem is that you don't know what's going on, and as a result, are expecting that EAP-MSCHAPv2 do things it's not supposed to do. Trying to "Fix" EAP-MSCHAPv2 is a waste of time. Find out why your expectations are wrong, and fix them. Alan DeKok.
I am doing IKEv2 EAP-MSCHAPv2 radius Passthrough. On Jan 18, 2008 1:43 AM, Alan DeKok <aland@deployingradius.com> wrote:
indira kolli wrote:
I finally got it working. I missed the reply to the second access-challenge.
How could you possibly miss that? If you're using a standard supplicant, that packet should be about 1/10 of a second after the first one.
One thing I am still not sure is about MPPE keys. For us we are using only EAP-MSCHAPv2 without peap. The authenticator needs the MPPE keys to authenticate the peer. But in the EAP-MSCAHPv2 Access-Challenge or Access-accept don't see the keys. I see that the keys are generated for MSCHAPv2 but are deleted before the request is sent.
Perhaps you could try reading my messages. You were already told that EAP-MSCHAPv2 does not generate the MPPE keys.
Even if you changed the server source code, the AP's wouldn't look for the MPPE keys. Even if you fixed the AP's, the supplicants wouldn't use encryption for the wireless links.
And you haven't said if you're using this for wireless or wired authentication.
I think you're really not clear on what you want to do, how the equipment works, and how the protocols work. I suggest spending time reading more AP documentation before asking EAP-MSCHAPv2 questions on this list. The problem is NOT EAP-MSCHAPv2. The problem is that you don't know what's going on, and as a result, are expecting that EAP-MSCHAPv2 do things it's not supposed to do. Trying to "Fix" EAP-MSCHAPv2 is a waste of time. Find out why your expectations are wrong, and fix them.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan, I understand that you know a lot more than i do. Can you point me to right RFC or draft which tells about the EAP-MSCHAPv2 radius call flow. We are trying to establish an IKEv2 tunnel using the EAP-MSCHAPv2 authentication. We are not using EAP-PEAP, so no certificates involved. We are following the "<draft-kamath-pppext-eap-mschapv2-01.txt<http://www3.tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2-01.txt>>", RFC 3748, RFC 2869, RFC 3079, RFC 3579. But none of these RFC's talk about the Radius message flow for the EAP-MSCHAPv2. Do you have a sample trace for the EAP-MSCHAPv2 radius call flow. I will really appericiate if you can point me to the right place with the call flow. The problem I am facing is that how will we have the Session Keys which are used to generate the Master Shared Key used for the IKEv2 tunnel establishment. The RFC says that we should get the SEND-KEY and the RECV-KEY from the AAA server. Any help will be greatly appericiated. Cheers, Indira. On Jan 18, 2008 9:35 AM, indira kolli <indkolli@gmail.com> wrote:
I am doing IKEv2 EAP-MSCHAPv2 radius Passthrough.
On Jan 18, 2008 1:43 AM, Alan DeKok <aland@deployingradius.com> wrote:
indira kolli wrote:
I finally got it working. I missed the reply to the second access-challenge.
How could you possibly miss that? If you're using a standard supplicant, that packet should be about 1/10 of a second after the first one.
One thing I am still not sure is about MPPE keys. For us we are using only EAP-MSCHAPv2 without peap. The authenticator needs the MPPE keys to authenticate the peer. But in the EAP-MSCAHPv2 Access-Challenge or Access-accept don't see the keys. I see that the keys are generated for MSCHAPv2 but are deleted before the request is sent.
Perhaps you could try reading my messages. You were already told that EAP-MSCHAPv2 does not generate the MPPE keys.
Even if you changed the server source code, the AP's wouldn't look for the MPPE keys. Even if you fixed the AP's, the supplicants wouldn't use encryption for the wireless links.
And you haven't said if you're using this for wireless or wired authentication.
I think you're really not clear on what you want to do, how the equipment works, and how the protocols work. I suggest spending time reading more AP documentation before asking EAP-MSCHAPv2 questions on this list. The problem is NOT EAP-MSCHAPv2. The problem is that you don't know what's going on, and as a result, are expecting that EAP-MSCHAPv2 do things it's not supposed to do. Trying to "Fix" EAP-MSCHAPv2 is a waste of time. Find out why your expectations are wrong, and fix them.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
indira kolli wrote:
I understand that you know a lot more than i do.
That isn't the problem. The problem is that you are not describing what you want to do, what you expect,and why you expect it. This makes it nearly impossible to help you.
Can you point me to right RFC or draft which tells about the EAP-MSCHAPv2 radius call flow.
No. EAP-MSCHAPv2 is just EAP. See the EAP/RADIUS RFC's for examples.
We are trying to establish an IKEv2 tunnel using the EAP-MSCHAPv2 authentication. We are not using EAP-PEAP, so no certificates involved.
Can you say which software you're using? Why are you trying to do this? What documentation said that this would work? Can you say *why* you are trying to do this? Which piece of documentation led you to believe that this would work? Be specific. Not that I expect answers to any of my questions... you've been very good about ignoring all of my questions, and asking more questions of your own. I'm not asking questions because I'm typing randomly. I'm asking questions because I need MORE INFORMATION to be able to help you. You've made it clear that you're not very interesting in providing more information, so.... I don't see how (or why) I can help you.
We are following the "<draft-kamath-pppext-eap-mschapv2-01.txt <http://www3.tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2-01.txt>>", RFC 3748, RFC 2869, RFC 3079, RFC 3579. But none of these RFC's talk about the Radius message flow for the EAP-MSCHAPv2. Do you have a sample trace for the EAP-MSCHAPv2 radius call flow.
Here's a simple question: Are you configuring existing software, or writing new software? If you're configuring existing software to do EAP-MSCHAPv2 authentication for Ikev2, then read the documentation that comes with the software. Ask the authors of the IKEv2 software questions about their software. If you're writing new software (i.e. IKEv2 implementation), then go ask questions on an IPSec mailing list. I have no idea why you're asking questions here. Yes, I understand you think it's the fault of RADIUS for not doing what you expect. But I suspect (very much) that your expectations are wrong.
I will really appericiate if you can point me to the right place with the call flow.
The problem I am facing is that how will we have the Session Keys which are used to generate the Master Shared Key used for the IKEv2 tunnel establishment. The RFC says that we should get the SEND-KEY and the RECV-KEY from the AAA server.
This is a good example of communication problems. You reference 5 documents above, and here you say "The RFC says ..." If you can't be bothered describing *which* RFC says this, and where, then I don't see why I should explain anything, either. Alan DeKok.
participants (2)
-
Alan DeKok -
indira kolli