I've been trying to track down some information for my authentication book, 
and I'm currently wrestling with the lack of easy to find Microsoft 
internal specs. So I thought I'd ask the community.

I've been writing about what I call "indirect authentication" which refers 
to the use of an authentication server like RADIUS, or when a server defers 
to a domain controller on a Windows LAN. I'm trying to nail down the 
details of what Microsoft is really up to.

According to one of their docs, a workstation can access a server and the 
server can authenticate the workstation's user by passing the logon API 
call across a "secure channel" to the domain controller. This "secure 
channel" is very poorly described. According to Stephen Sutton's "NT 
Security Guide" the secure channel sounds like it uses our old friend, 
Microsoft Point to Point Encryption (MPPE). At least, he describes a 
similar key exchange algorithm (the old, weak one) and notes that it uses 
RC4. Now, for my questions:

1) Are appearances true? Is it reasonable to say that the secure channel 
uses MPPE?

2) Does anyone have copies of the old Internet-Drafts that published the 
MPPE v1 and v2 protocols? They've all expired and my searches failed to 
find any online.

3) There is a bug fix in Service Pack 4 that adds "integrity protection" to 
the secure channel (still not referring to it as MPPE). Does anyone know 
what this integrity protection consists of?

4) PPTP uses MPPE, and several PPTP weaknesses described by Schneier and 
Mudge back in '97-99 probably apply to this "secure channel." I searched 
the NT service pack descriptions and didn't find any bug fixes for the 
secure channel protocol, except the one that added "integrity protection." 
Does anyone know if Microsoft has indeed tried to fix the secure channel 
protocol with an NT service pack?

5) Does anyone know if the secure channel protocol got fixed in Windows 2K? 
Or are they expecting the whole thing to die, and be replaced by 
Microsoft's version of Kerberos?

Inquiring minds, etc.

Rick.
[EMAIL PROTECTED]


Reply via email to