Hi Prashant.
I think in the challenge request, the first byte is the challenge length
(usually 16) followed by the challenge itself, and then followed by some server
name. I guess the reasoning is that this allows the client to choose the
correct password based on the server name.
Yoav
__
Chris' case is a little different, because he is willing to do some work to
establish trust between the two administrative domains, so it's not really
opportunistic (although doing it with OE might be a solution)
So there could be some "hub gateway" that could do the introducing, perhaps
over I
On 10/25/2011 3:35 PM, Yoav Nir wrote:
> Hi Prashant.
>
> I think in the challenge request, the first byte is the challenge length
> (usually 16) followed by the challenge itself, and then followed by some
> server name. I guess the reasoning is that this allows the client to
> choose the correc
Thanks Yaov and Glen,
I could successfully calculate the challenge response.
Now, after the challenge response is successful, the server will send
EAP-SUCCESS, then the client has to send a AUTH payload.
As eap-md5 doesn't result in any key like eap-aka/sim, the client will
use the same password(u
No, you don't use the same password for calculating the AUTH payload.
>From section 2.15:
There are two types of EAP authentication (described in
Section 2.16), and each type uses different values in the AUTH
computations shown above. If the EAP method is key-generating,
substitute m
Thanks Yoav,
I think I missed it somehow from the RFC.
Regarding the usage of EAP-MD5, it is just that the client should
support all types of authentication,
So even the weakest ones also and rfc-3748 says that md5-challenge is a
must.
Moreover, it is the server that has to decide what is the bes
