OK, when the initiator name is set in acceptReadyEap, find out why the mech isn't being set?
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
>
|