[105] in Best-of-Security
BoS: auth-draft feedback
daemon@ATHENA.MIT.EDU (*Hobbit*)
Sat Apr 5 07:35:30 1997
Date: Fri, 4 Apr 1997 13:46:52 -0500
Reply-To: Windows NT BugTraq Mailing List <NTBUGTRAQ@RC.ON.CA>,
*Hobbit* <hobbit@AVIAN.ORG>
From: *Hobbit* <hobbit@AVIAN.ORG>
Errors-To: best-of-security-request@suburbia.net
To: best-of-security@suburbia.net
Resent-From: best-of-security@suburbia.net
This is pretty much specifically aimed at Paul Leach, but is being posted here
for general comment and review. Please CC me directly on any replies, because
I'm not on the CIFS list at the moment and the archive server for it is a pain
in the ass. For all I know "paulle" could be a fabricated name that goes on
internet-drafts and mail authored by a group inside MS, but regardless, this
is in a sort of second-person style where "you" is the appropriate entity.
So, hiya. You probably don't know me, but you've likely read my little [!]
rant about CIFS and SMB by now. Perhaps we'll actually meet someday. I ran
across a reference to the new CIFS-auth stuff, pulled down draft 4, and tried
to go through it reasonably carefully. My head hurts now, but I came up with
some comments that I hope you'll find constructive.
First, some syntactical administrivia. You may have to search all the
documents for these, since by now I'm not sure which is where. Someone
else may have already caught all these, but whatever..
substr(S, A, B)
denote a byte string of length N obtained by taking N bytes of S ...
You probably meant substr(S, A, N) ?
Message authentication may only be requested when the "NTML 0.12"
NTLM, not NTML?
Is authentication supposed to work under all transport types? It looks like
you're jamming the MAC into the "reserved" 12 bytes of the SMB header. From
familiarity with the protocol I can make the following assumptions, but they
should be made clearer in the document.
* The MAC covers just the SMB payload, excluding the length integer sent
by the TCP transport layer
* The MAC covers the entire SMB including parameters and data buffers,
not just the SMB header [I assume this is what "message" means]
So, what does all this imply for UDP protocol, where some of those 12 bytes
aren't just padding? If I'm reading this right, the
UCHAR SecuritySignature[8];
overwrites
ULONG Unused; // Not used
USHORT Sid; // Session ID
USHORT SequenceNumber; // Sequence number
in the header, which would probably completely screw up UDP transport. The
whole new union as you have it is also NOT 12 bytes long, unless I'm missing
something. I am therefore confused, since I'm the kind of guy who likes
staring at packet dumps.
The definition of the swab() operation has me completely befuddled, especially
where it is used in generating LANMAN hashes:
S16X = Ex(swab(P14),N8)
If this really refers to the generation of 8 key bytes from 7 password bytes,
the current implementation's method of shifting and ORing strikes me as more
of a "sprinkling" operation than a "swab" operation. [str_to_key() in the
Samba code, for reference...] There is clearly no bit *reversing* going on
anywhere in the process, so I don't see how swab() enters the real-life
picture at all. The spec should probably be updated to reflect this.
Second in the broader topics, I understand the desire to change the base
protocol as little as possible, but it strikes me [and several other readers]
that several things are still just plain wrong and if you're going to fix it,
please fix it right. On the positive side, it is absolutely great that both
server and client will finally be able to *enforce* use of the more secure
protocols. It is also nice that some of the designs are going up for public
review, and I would dearly hope that this trend continues and broadens to
cover other MS subsystems. You are well aware that many of us are curious
about PPTP, domain logons, RPC, etc...
You have already heard the negative side from many people and covering many
different points, but here's another take on it anyway. In a nutshell, the
industry at large DISAGREES with your assertion that
Ks = MD4(P(U))
and has done so for decades. This, in fact, is the long-term shared secret,
and should be treated as such. A SESSION key *by definition* is a different
animal, and I think we all understand that. When you were enscribing
Since the key is formed from both the session key (which is per-user and
long-lived) and the response (which is per-session), large quantities of
data are not hashed using a long-lived key, which might subject it to
attack.
didn't it look just a wee bit funny to you? Your Km includes the 24-byte
response that passed in the CLEAR at setup time, therefore reducing the MAC
secret to the user's fixed OWF hash again and invalidating the above
statement. If I'm reading it right [it was getting late at that point...]
the generation of Km from the LANMAN OWF reduces to just *eight* bytes of
[fixed] secret. Has the resulting backlash via various mailing lists given
any pause for thought?
Also, as others have mentioned, the client should introduce its own random
component. Draft 3 appears to have *almost* allowed for this, but is then
changed:
In step 6 of section 1.4,
C: MS' = [MD5(Km, SN, Msessr, CC, CS)]<8>
should be
C: MS' = [MD5(Km, SN, Msessr,)]<8>
Aha! CC is "client challenge", isn't it?? But your draft 4 REMOVES it,
as well as the bits where
... a "response" is created from the challenge by encrypting it (and
possibly a nonce of the client's choice) with a 168 bit [key] ...
... Where S16 and RN are as above. K is either 40 or 44 bytes long,
depending on the length of RN.
and now provides NO allowance for that idea -- thus you've dangled the hope
of involving random material from the client in front of our eyes, and then
snatched it away again. PLEASE strongly consider re-introducing this.
While reliance on "eventual IPSEC" once again enters the specification under
privacy considerations, let me emphasize that since client and server already
share a secret key, there is NO reason to not derive a true session key from
the exchange and encrypt the entire SMB stream. Especially in the largely
continued absence of deployed IPSEC! Client random material helps here, too.
Hell, you have *24 bytes* of response to play with, giving you plenty of room
for both user authentication and key exchange -- how many bytes does one
really need to authenticate a single session, anyway? Just eight, if your MAC
spec is taken as a model, leaving another 16 where the client could insert any
other [encrypted??] information. The server can still pass all this gook
verbatim to the KS and still get back the user's OWF as in the current
protocol, and then use it to decrypt elements of the client's response.
Speaking of the key server, which I assume is the PDC,
4. The server send the user's name, the challenge, and the response to a
key server (KS) over a secure (private, authenticated) channel.
Do tell. I'll bet *that* isn't "available from Microsoft upon request" --
see above about publishing protocols.
A tiny, but obligatory, bash: Microsoft could certainly afford to contract
ANY of the really hot crypto people out there to review their protocols. Why
don't they? Why must we all keep limping along with these tiny, incremental
security "fixes" that reduce real industry progress to a crawl? I'm sure that
Kaiser Wilhelm and his golfing buddies don't give a rat's ass, but the rest of
us do since all this affects OUR careers as well.
But the goal here isn't to be abrasive, it's to help out. Hope it does...
_H*
