Natan Abolafya | 26 Mar 09:48 2010
Picon

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
Russ Allbery | 26 Mar 23:04 2010
Picon

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
Simon Wilkinson | 26 Mar 23:33 2010
Picon
Picon

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
(Continue reading)

Natan Abolafya | 27 Mar 10:15 2010
Picon

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 
(Continue reading)

Simon Wilkinson | 27 Mar 11:23 2010
Picon
Picon

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&#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.
(Continue reading)

Russ Allbery | 27 Mar 18:46 2010
Picon

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
(Continue reading)

Henry B. Hotz | 29 Mar 21:12 2010
Picon
Picon

"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,
(Continue reading)

Alec Kloss | 29 Mar 21:29 2010

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&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
(Continue reading)

Henry B. Hotz | 29 Mar 23:18 2010
Picon
Picon

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
Guillaume Ross | 30 Mar 15:13 2010
Picon

Build Mod_auth_kerb for Apache on Windows

Good day everyone,

I am attempting to setup some Windows Apache servers to provide SSO to Active Directory users. It seems the best way to achieve this would be to get mod_auth_kerb working on Apache for Windows.

As binaries are not available, I am attempting to build it, in Cygwin. I'm looking for a bit of help to tackle this, and once I manage to compile it and get it working I'd like to write a small howto as it seems a few people are looking to get this to work.


Here are the issues I stumbled accross but managed to fix:
I've downloaded the sources to krb5 and installed MIT's kerberos for windows. I've also got the kfw specific sources but the directory structure seemed to tell me I'd need the krb5 sources more than anything.

$ ./configure --with-krb5="C:krb5" --with-krb4=no

Everything goes well, until it starts to check for gssapi.

checking gssapi.h usability... no
checking gssapi.h presence... no
checking for gssapi.h... no
checking gssapi/gssapi.h usability... no
checking gssapi/gssapi.h presence... no
checking for gssapi/gssapi.h... no
checking for krb5_init_context in -lkrb5... no
checking for krb5_init_context in -lkrb5... (cached) no
checking for krb5_init_context in -lkrb5... (cached) no
configure: error: No Kerberos enviroment found


The config.log file contains this error:
configure:3862: gcc -c -g -O2  -IC:\krb5/include conftest.c >&5
conftest.c:57:20: gssapi.h: No such file or directory

So the first thing I did was find gssapi.h .. which is located in krb5-1.8\src\include , so I ran the configure command again, but adding \src to the path of KRB5.

$ ./configure --with-krb5="C:\krb5\src" --with-krb4=no

This time the error in the logs is a bit more telling:

configure:3773: result: time.h
configure:3845: checking gssapi.h usability
configure:3862: gcc -c -g -O2  -IC:\source\krb5-1.8\src/include conftest.c >&5
In file included from conftest.c:57:
C:/krb5/src/include/gssapi.h:6:27: gssapi/gssapi.h: No such file or directory
configure:3869: $? = 1

Sure enough, the gssapi.h file in my sources refers to "gssapi/gssapi.h" which was not to be found in this path. However I did find it in my installed KRB5's directory structures, so I copied the gssapi directory from there to my source/include directory so gssapi.h could be found in krb5/src/include/gssapi .

This fixed the first problem:

configure:3923: result: yes
configure:3956: checking for gssapi.h
configure:3965: result: yes

----------------------------------------
Now this is the error I get. Does this mean I should be building krb5 from source too instead of having the MIT's Kerberos for windows package installed in C:\krb5 ?


configure:4222: checking for krb5_init_context in -lkrb5
configure:4257: gcc -o conftest.exe -g -O2   conftest.c -lkrb5   C:\krb5\src/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv >&5
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lkrb5
collect2: ld returned 1 exit status

Thank you!

Guillaume Ross

------------------------------------------------------------------------------
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
_______________________________________________
modauthkerb-help mailing list
modauthkerb-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthkerb-help

Gmane