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.
>
> The enctype-less OID (what you see) is used internally but it should not be exposed to the mechglue.
>
> -- Luke
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;
}
It's taking the "else" path, that is, assigning GSS_EAP_MECHANISM ({ 9,
"\x2B\x06\x01\x04\x01\xA9\x4A\x16\x01" }, to mech variable, which is
directly dumped at the beginning of the exported name.
I guess that name->mechanismUsed should point to: { 10,
"\x2B\x06\x01\x04\x01\xA9\x4A\x16\x01\x11" }, or { 10,
"\x2B\x06\x01\x04\x01\xA9\x4A\x16\x01\x12" }, instead of just GSS_C_NO_OID.
However, I don't know so much of moonshot's code to be able to localize
the source of the problem. Should be related though with the value
exported by gss_accept_sec_context.
Regards,
Alejandro
|