Crazy ideas about Kerberos, NTLM and PACs... (was NTLMSSP...)

[Andrew Bartlett]

Luke Howard wrote:
> 
> > ...which is why ms created draft-brezak-krb5-rc4-hmac-01.txt
> > which uses nt hashes for authentication and encryption.
> 
> Not _why_, I don't think. This draft defines a mechanism for
> migrating NT hashes to Kerberos, but it doesn't encapsulate
> the NTLM authentication exchange in Kerberos, which I think is
> what Andrew is proposing. I can't see how the latter is possible.

My insane idea is as follows:

Samba (acting as an NT4 server, to NT4 clients) gets an attempted NTLM
login.  Samba then contacts (via a new protocol) the extended KDC to
obtain a challenge, and hands back the clients response.  This is done
over a secure channel, based on the Samba server's own keytab.  This
response includes the unencrypted TGT, session key and the first 8 bytes
of the LM hash, which Samba then uses to access other network resources.

Reasoning:  Yes, this is insecure as all heck - TCP session hijacking is
the problem as far as I can see - or at least as insecure as current non
sign-and-seal communications.  However, it helps solve a particular
problem:   Passing the security context in a standard manner to an
arbitrary backend over the network.

For example, if we have an LDAP SAM, and we have an administrator
updating passwords in it.  Currently in HEAD (I've not looked at TNG
yet) we do this all by local access controls and a 'ldap root'
password.  I think this stinks, and I would much prefer to have a LDAP
server enforce the access controls.  This allows me to (securely) pass
that security context over to the LDAP server, or that VFS backend, or
that AFS filesystem etc...

I have *no* idea if I'll actually get this far - I'll probably only get
as far as checking the password - but I wouldn't mind scouting out the
surrounding area while I'm at it. :-)

In any case, by doing much of this work I'll hopefully prepare the way
for (or sail on the coattails of) *real* kerberos ticket passing and the
like in Samba, based on the real kerberos over-the-wire deal.

It also separates the list of users/groups from the password storage,
which I something I like the idea of.  

In the event we get to creating the PAC, I think this should be done via
a simple call-back, the kerberos server should use a similar protocol to
obtain a PAC from *any* PAC providing service, not just Samba.  The idea
of a PAC is quite (IMHO) a nice one, its just a pity MS decided not to
document it.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net