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

[Jeff Layton]

On Fri, 22 Aug 2008 00:07:14 +0400
"Q (Igor Mammedov)" <niallain at gmail.com> wrote:

> 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.
> 

One step at a time. If you want to suggest a more comprehensive
approach, then I'm all ears.

> 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.
> 

I'm not opposed to sending the whole blob to userspace, but I don't
think we can reasonably do it in the key description. One mechanism
might be to use the auxdata with request_key, but that means we'll need
to roll our own equivalent of call_sbin_request_key(). I wonder if we
can directly map the pages holding the spengo blob into the spawned
program's pagetables?

-- 
Jeff Layton <jlayton at redhat.com>