[linux-cifs-client] Re: SPNEGO OIDs and MIC

[Q (Igor Mammedov)]

On Thu, Aug 21, 2008 at 9:48 PM, Jeff Layton <jlayton at redhat.com> wrote:
> On Thu, 21 Aug 2008 10:55:58 -0500
> "Steve French" <smfrench at gmail.com> wrote:
>
>> https://lists.anl.gov/pipermail/ietf-krb-wg/2002-December/002168.html
>>
>> --
>> Thanks,
>>
>> Steve
>
> (cc'ing linux-cifs-client and Igor as well...)
>
> Thanks for that info, Steve. That makes a bit more sense. The first bug
> mentioned explains why we need to support 2 different OID's. The second
> one talks about the mechListMIC and why it has the server's principal
> rather than a real MIC.
>
> Appendix C of the current SPNEGO RFC has some info on working around
> MS bugs:
>
> http://tools.ietf.org/html/rfc4178
>
> ...and they make a bit more sense after reading the comments in this
> other post.
>
> It seems to me that parsing this info out and sending it to userspace
> is still reasonable. We could even have userspace do a sanity check of
> this info. See if it looks like a principal name rather than a real MIC.
>
> Maybe something like:
>
> if (strstr(mechlistmic, "$@")) then try to use the mechlistmic field as
> principal name.

It is a good idea, we can just skip it if it doesn't look like principal.
Where do you propose to do it, in kernel or upcall?

> That said, given that this is a MS-specific quirk, it may make sense
> to only use this info for MSKRB5 after all.

Attempting to use it for krb5 will not hurt either, we can try it first
and if KDC will reject it we can use a normal principal.

We actually have a very limited implementation, no mech negotiation
and other stuff gss can do, but it provides necessary minimum for auth.

For supporting gss negotiation,  mutual auth and encryption, whole spnego blob
should be passed to upcall unless we implement gss in kernel.

PS:

Checking  signature of every packet we may be sure that server
is not a fake one, however if I remember correctly, cifs only complains
about wrong signature and allows communication. It would be better if
we do not establish session when server sends an incorrect signature
(at least by default)

Using sec=krb5 without signing is not safe now because of we can't
verify that server is not fake one. For this we need to request mutual auth
and pass spnego blob to ucall for a verification.

>
> Thoughts?
> --
> Jeff Layton <jlayton at redhat.com>
>