Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging
From: Luke Kenneth Casson Leighton (lkcl@SAMBA-TNG.ORG)Date: 03/21/02
- Previous message: Luke Kenneth Casson Leighton: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- In reply to: Brown, Keith: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- Next in thread: 3APA3A: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- Next in thread: Justin Moebus: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 21 Mar 2002 21:35:44 +0000 From: Luke Kenneth Casson Leighton <lkcl@SAMBA-TNG.ORG> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
On Thu, Mar 21, 2002 at 10:51:21AM -0800, Brown, Keith wrote:
> NTLM does in fact offer integrity and confidentiality protection of
> messages after the initial handshake.
NTLM doesn't. NTLMSSP does.
> The session key is a function of
> the OWF(password) and the challenge.
in NTLMSSP v1, the session key is just MD4(NT#) which
does not change, is utterly crazy, and what is worse
it is even used as an RC4 key on a regular basis.
total security nightmare.
in NTLMSSP v2, the session key is, as you say, based
on a function, which i describe in my previous post,
and it is also implemented in samba TNG source code.
> In the case of pass-through
> authentication, the session key is passed from the authority to the
> server over a secure channel.
... *thinks*...
no, that's... not _quite_ correct...
in NTLMv1 pass-through authentication, the first 8 bytes
of the LM# are passed back [encrypted using the session
key], from the server over the secure channel back to
the intermediate client, SUCH THAT, if the intermediate
[pass-thru] client wishes to perform NTLMSSP digital signing
or encryption, on behalf of the initial client, it may do so.
[this can be done without the intermediate pass-thru client
having the full user's LM# or NT#, which it can't get because
we're talking pass-through authentication, here.]
i know this sounds crazy, but it's less crazy than pre NT4
SP3 which used to send that first 8 bytes of the LM#
*in the clear*.
in NTLMv2 pass-through, i can't remember, it's been too
long since i was actively involved with, and getting paid
to investigate and implement, this stuff.
if someone wants to give me money, i can stop struggling
with finances working as a builder's assistant, and then
will be in a position to give people better advice here.
luke
-- ---------------------------------------------------------- this message is private, confidential, and is intented for the specified recipients only. if you received, altered, deleted, modified, destroyed or interfered with the contents of this message, in whole or in part, please inform the sender (that's me), immediately.if you, the recipient, reply to this message, and do not then receive a response, please consider your reply to have been lost or deliberately destroyed: i *always* acknowledge personal email received. please therefore take appropriate action to ensure effective communication.
thank you.
- Previous message: Luke Kenneth Casson Leighton: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- In reply to: Brown, Keith: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- Next in thread: 3APA3A: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- Next in thread: Justin Moebus: "Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]