Integrity forced upon mechanism in spnego

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Integrity forced upon mechanism in spnego

Simo Sorce-3
I am dealing with an interesting issue in spnego involving MIC tokens
and reading the code I found out that init_ctx_call_init in
spnego_mech.c forces req_flags to always request GSS_C_INTEG_FLAG from
the mechanism.

Git blame brought me to a branch called mechglue, but that branch is
quite different from the actual code that has been supposedly merged
from there and does not force the flag.

Does anyone know why this is being done ?

I ask because later on the code checks the spnego context flags to see
if integrity was requested and does not find it there. This prevents a
mechlistMIC token from being be generated.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Integrity forced upon mechanism in spnego

Greg Hudson
On 04/13/2014 12:34 AM, Simo Sorce wrote:
> I am dealing with an interesting issue in spnego involving MIC tokens
> and reading the code I found out that init_ctx_call_init in
> spnego_mech.c forces req_flags to always request GSS_C_INTEG_FLAG from
> the mechanism.
>
> Git blame brought me to a branch called mechglue, but that branch is
> quite different from the actual code that has been supposedly merged
> from there and does not force the flag.

I'm not sure what git-svn did with that branch.  In the frozen
Subversion repository, the branch matches what was merged (I think), and
the relevant commit appears to be r18024, which doesn't seem to have
made it into the git repository.  "svn diff -c 18024
svn://anonsvn.mit.edu/svn/krb5" and "svn log -r 18024 ..." should give
you the commit.

> Does anyone know why this is being done ?

Presumably so that we can create a MIC to secure the negotiation if the
underlying mechanism allows it.

> I ask because later on the code checks the spnego context flags to see
> if integrity was requested and does not find it there. This prevents a
> mechlistMIC token from being be generated.

I believe sc->ctx_flags determines whether integrity is provided by the
mechanism, not whether it was requested.  See how &sc->ctx_flags is
given as the ret_flags argument to gss_init_sec_context in
init_ctx_call_init.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Integrity forced upon mechanism in spnego

Simo Sorce-3
On Sun, 2014-04-13 at 00:55 -0400, Greg Hudson wrote:

> On 04/13/2014 12:34 AM, Simo Sorce wrote:
> > I am dealing with an interesting issue in spnego involving MIC tokens
> > and reading the code I found out that init_ctx_call_init in
> > spnego_mech.c forces req_flags to always request GSS_C_INTEG_FLAG from
> > the mechanism.
> >
> > Git blame brought me to a branch called mechglue, but that branch is
> > quite different from the actual code that has been supposedly merged
> > from there and does not force the flag.
>
> I'm not sure what git-svn did with that branch.  In the frozen
> Subversion repository, the branch matches what was merged (I think), and
> the relevant commit appears to be r18024, which doesn't seem to have
> made it into the git repository.  "svn diff -c 18024
> svn://anonsvn.mit.edu/svn/krb5" and "svn log -r 18024 ..." should give
> you the commit.
>
> > Does anyone know why this is being done ?
>
> Presumably so that we can create a MIC to secure the negotiation if the
> underlying mechanism allows it.
>
> > I ask because later on the code checks the spnego context flags to see
> > if integrity was requested and does not find it there. This prevents a
> > mechlistMIC token from being be generated.
>
> I believe sc->ctx_flags determines whether integrity is provided by the
> mechanism, not whether it was requested.  See how &sc->ctx_flags is
> given as the ret_flags argument to gss_init_sec_context in
> init_ctx_call_init.

Ah thank you Greg, just to close loose ties, after a chat on IRC we
determined my mechanism was probably not setting properly the ret_flags
in the init_set_context call ...

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev