SSL Recommendation for Negotiation

Hello,

May I ask why do you recommend this? In the main page of the project, 
the reason for basic auth is explained well. However, recommendation for 
Negotiation is not explained at all.

I have two guesses :

1 - Replay attacks. Isn't timestamp placed into the protocol for this?
2 - Network Sniffing. Well, I understand that, but why is it 
recommended? That I believe is off-topic, something Kerberos is not for. 
(Well, I actually expected that Negotiation method would provide 
encryption of HTTP packets as well since the visual model here ( 
http://www.ncat.edu/~xhyuan/security_visual_tools/kerberos/kerberos_demo.html 
) suggests that. But, it doesn't. This another question)

Regards.
Natan Abolafya

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: SSL Recommendation for Negotiation

Natan Abolafya <natanabolafya <at> std.iyte.edu.tr> writes:

> May I ask why do you recommend this? In the main page of the project, 
> the reason for basic auth is explained well. However, recommendation for 
> Negotiation is not explained at all.

> I have two guesses :

> 1 - Replay attacks. Isn't timestamp placed into the protocol for this?

It's very common to disable the replay cache, and some Kerberos
implementations don't support it at all.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: SSL Recommendation for Negotiation

On 26 Mar 2010, at 22:04, Russ Allbery wrote:

> Natan Abolafya <natanabolafya <at> std.iyte.edu.tr> writes:
> 
>> May I ask why do you recommend this? In the main page of the project, 
>> the reason for basic auth is explained well. However, recommendation for 
>> Negotiation is not explained at all.
> 
>> I have two guesses :
> 
>> 1 - Replay attacks. Isn't timestamp placed into the protocol for this?
> 
> It's very common to disable the replay cache, and some Kerberos
> implementations don't support it at all.

Also, there's no binding between the authentication handshake and the data that follows it. An active
attacker can proxy the handshake and then replace the payload with whatever they like.

Cheers,

Simon.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: SSL Recommendation for Negotiation

27.03.2010 00:33, Simon Wilkinson yazmış:
> On 26 Mar 2010, at 22:04, Russ Allbery wrote:
>
>    
>> Natan Abolafya<natanabolafya <at> std.iyte.edu.tr>  writes:
>>
>>      
>>> May I ask why do you recommend this? In the main page of the project,
>>> the reason for basic auth is explained well. However, recommendation for
>>> Negotiation is not explained at all.
>>>        
>>      
>>> I have two guesses :
>>>        
>>      
>>> 1 - Replay attacks. Isn't timestamp placed into the protocol for this?
>>>        
>> It's very common to disable the replay cache, and some Kerberos
>> implementations don't support it at all.
>>      
> Also, there's no binding between the authentication handshake and the data that follows it. An active
attacker can proxy the handshake and then replace the payload with whatever they like.
>
> Cheers,
>
> Simon.
>    
Am I missing something or isn't the "proxy the handshake, replace the 
payload" method known as Replay Attack already?
If yes, and if I have a Kerberos implementation with replay cache then I 

Re: SSL Recommendation for Negotiation

On 27 Mar 2010, at 09:15, Natan Abolafya wrote:
> Am I missing something or isn't the "proxy the handshake, replace the
> payload" method known as Replay Attack already?
> If yes, and if I have a Kerberos implementation with replay cache  
> then I
> shouldn't worry right?

No,

A replay attack is where a passive attacker records the authentication  
handshake of a particular session, and then resends those messages to  
the server at some later point in time (probably along with their own  
payload). The server will see the same handshake twice - and will  
realise this if the server has a replay cache.

In the attack I outlined an active attacker intercepts the  
authentication handshake whilst it is being performed and replaces the  
payload. In this attack, the server only sees the handshake once (with  
the modified payload), and so a replay cache won't help.

Cheers,

Simon.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.

Re: SSL Recommendation for Negotiation

Simon Wilkinson <sxw <at> inf.ed.ac.uk> writes:
> On 26 Mar 2010, at 22:04, Russ Allbery wrote:

>> It's very common to disable the replay cache, and some Kerberos
>> implementations don't support it at all.

> Also, there's no binding between the authentication handshake and the
> data that follows it. An active attacker can proxy the handshake and
> then replace the payload with whatever they like.

Yeah, this is much more serious than what I was thinking of.  It's trivial
to do this sort of thing by intercepting someone's wireless traffic, for
instance.

Related, Negotiate-Auth generally does not do mutual authentication, so
without SSL and checking the server's certificate, you could be talking to
an attacker's server who accepts your Negotiate-Auth negotiation and uses
it to authenticate to the real server behind your back to perform some
entirely different operation.  Which is basically the same attack, just
done a slightly different way.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

"Extended Protection for Authentication", a Manifesto

Been meaning to post this, and the recent questions about replays, etc. from Natan Abolafya reminded me of it.

Late last year Microsoft deployed some updates to their HTTP-Negotiate protocol that implement
"Extended Protection for Authentication".  Basically, they implemented channel binding, which
guarantees that the TLS tunnel at the client is the same tunnel at the one at the server end of the
connection.  This eliminates the replay and MITM attacks by explicitly tying the Negotiate exchange to
the TLS tunnel so it can provide that protection.

Speaking as a purist, I wish Microsoft had made direct use of the session key from the Kerberos exchange to do
that.  However, what they did still solves the problems, and it undoubtedly took a lot less effort to
implement.  I applaud them for stepping up and solving the problems.

The downsides are that what they did is still backwards incompatible, so everyone is disabling the
capability for now.  Also none of the open-source software out there (like mod_auth_kerb) has
implemented it yet.

We need to fix that!

The public info that Microsoft has pointed me at follows.  (Thanks to Michiko Short!)  There is probably more
info coming, or here by now, since she sent me these links last year.

http://support.microsoft.com/kb/973917
http://www.microsoft.com/technet/security/bulletin/ms09-054.mspx

I believe the following RFC is also relevant for anyone who wants to implement these improvements:

http://tools.ietf.org/html/rfc5056

------------------------------------------------------
The opinions expressed in this message are mine,

Re: "Extended Protection for Authentication", a Manifesto

On 2010-03-29 12:12, Henry B. Hotz wrote:
> Been meaning to post this, and the recent questions about replays, etc. from Natan Abolafya reminded me of it.
> 
> Late last year Microsoft deployed some updates to their HTTP-Negotiate protocol that implement
"Extended Protection for Authentication".  Basically, they implemented channel binding, which
guarantees that the TLS tunnel at the client is the same tunnel at the one at the server end of the
connection.  This eliminates the replay and MITM attacks by explicitly tying the Negotiate exchange to
the TLS tunnel so it can provide that protection.
> 

Thanks for the info Henry...

but oh how I wish http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 had gone somewhere.

Is there any chance of someone reviving GSSAPI in TLS to simplify
everyone's enterprise web deployments by not needing both PKI and 
Kerberos everywhere?

Or am I missing something?

--

-- 
Alec Kloss                               Email/IM:  alec <at> SetFilePointer.com
PGP key:       http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEBD1FF14
"No Bunny!" - Simon, http://wiki.adultswim.com/xwiki/bin/Frisky+Dingo/Simon

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.

Re: "Extended Protection for Authentication", a Manifesto

Comments made last week are that it's not completely dead.  It just needs a hard push with a clear
applicability statement.

It sounded like my own push to get KX509 standardized might interfere because it would reduce the need.  *sigh*

On Mar 29, 2010, at 12:29 PM, Alec Kloss wrote:

> Thanks for the info Henry...
> 
> but oh how I wish http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 had gone somewhere.
> 
> Is there any chance of someone reviving GSSAPI in TLS to simplify
> everyone's enterprise web deployments by not needing both PKI and 
> Kerberos everywhere?
> 
> Or am I missing something?

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Build Mod_auth_kerb for Apache on Windows

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
modauthkerb-help mailing list
modauthkerb-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthkerb-help