On 10/08/12 12:26, Luke Howard wrote:
> Ah, that sounds plausible! I'll take a look tomorrow if you don't figure it out before.
Oh, thank you. I don't think I can figure it out. Too "deep" into the
code to me, I presume :)
Regards,
Alejandro
>
> Sent from my iPhone
>
> On 10/08/2012, at 21:24, Alejandro Perez Mendez <[log in to unmask]> wrote:
>
>> On 10/08/12 12:04, Luke Howard wrote:
>>> OK, when the initiator name is set in acceptReadyEap, find out why the mech isn't being set?
>> Well, in acceptReadyEap is set. That's weird.
>>
>> In gssEapAcceptSecContext:
>> ctx->mechanismUsed != NULL
>> ctx->initiatorName->mechanismUsed == NULL
>>
>> But in acceptReadyEap:
>> ctx->mechanismUsed != NULL
>> ctx->initiatorName->mechanismUsed == ctx->mechanismUsed
>>
>> I also realized that between acceptReadyEap call and gssEapAcceptSecContext call, there is a roundtrip, that is, they are not called in the same moment. Could it be a problem of export_sec_context? Maybe ctx->initiatorName->mechanismUsed is not exported (or imported) correctly.
>>
>> Regards,
>> Alejandro
>>
>>
>>> Sent from my iPhone
>>>
>>> On 10/08/2012, at 20:50, Alejandro Perez Mendez <[log in to unmask]> wrote:
>>>
>>>> On 10/08/12 11:35, Luke Howard wrote:
>>>>> OK, when gssEapDuplicateName is called at the end of accept sec context, is the mechanism OID set properly?
>>>> Well, it seems not.
>>>>
>>>> Even though ctx->mechanismUsed is set, ctx->initiatorName->mechanismUsed is not. That might be the problem.
>>>>
>>>> Regards
>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 10/08/2012, at 20:30, Alejandro Perez Mendez <[log in to unmask]> wrote:
>>>>>
>>>>>> On 10/08/12 11:16, Luke Howard wrote:
>>>>>>> On 10/08/2012, at 8:09 PM, Alejandro Perez Mendez <[log in to unmask]> wrote:
>>>>>>>
>>>>>>>> On 10/08/12 10:07, Luke Howard wrote:
>>>>>>>>> On 10/08/2012, at 7:03 PM, Alejandro Perez Mendez <[log in to unmask]> wrote:
>>>>>>>>>
>>>>>>>>>> The received OID at that point is { 1 3 6 1 4 1 5322 22 1 }
>>>>>>>>> Hmm. It should be 1.3.6.1.4.1.5322.22.1.17 or 1.3.6.1.4.1.5322.22.1.18. You might want to step through gss_export_sec_context() and see what's happening.
>>>>>>> (Sorry for confusing exporting the context and name here.)
>>>>>> I didn't even realize :). I knew what you meant.
>>>>>>
>>>>>>>> Well, I figured out why it is failing. Apparently, in gssEapExportNameInternal, you have the following code:
>>>>>>>>
>>>>>>>> if (name->mechanismUsed != GSS_C_NO_OID){
>>>>>>>> mech = name->mechanismUsed;
>>>>>>>> }
>>>>>>>> else{
>>>>>>>> mech = GSS_EAP_MECHANISM;
>>>>>>>> }
>>>>>>> (I'm not sure whether that code should not be replaced with an assertion that name->mechanismUsed isn't GSS_C_NO_OID. But anyway.)
>>>>>>>
>>>>>>> You are passing the initiator name to gss_export_name_composite(), right?
>>>>>> Right. That's the idea.
>>>>>>
>>>>>>> If you break on acceptReadyEap(), which sets the initiator name in the context, can you check ctx->mechanismUsed is not NULL?
>>>>>> Indeed is NOT NULL.
>>>>>>
>>>>>>> How are you getting the initiator name, from gss_accept_sec_context() or gss_inquire_context()
>>>>>> gss_accept_sec_context.
>>>>>>
>>>>>>> -- Luke
|