Subject: [dix] DIX in the extranet

From: Robert Yates <[email-masked]>
Date: Fri, 03 Mar 2006 09:28:54 -0500

Acme corp utilizes monster.com for its hiring process.  Acme has a site 
license for access to monster.com, however the agreement limits acme to 
10 concurrent users.  To keep within this contraint Acme limits the 
employees that can access monster.com.  It utilizes dmd0 and achieves 
this by having a user property called dix:/monster.com/user-key.  
Employees that are allowed to use monster.com have this property set.

An acme employee with the right to access monster.com goes to that 
site's login page.  Here, they type in their homesite 
"intranet.acme.com", a homesite on acme's intranet.  Monster.com 
requests the attribute "dix:/monster.com/user-key" via DIX.  The user is 
bounced to their homesite, they authenticate and then they get bounced 
back to the membersite monster.com with the property set and the message 
signed.

The interesting aspect of the above scenario is that monster.com cannot 
communicate with the server "intranet.acme.com" it is behind the 
companies firewall.  It is also worth mentioning that acme, like all 
large multinationals, has "intranet.acme.com" locked away deep inside a 
data center.  It can talk to its ldap server and a database server, but 
nothing else and certainly not "monster.com"

It is in scenarios such as these that "push" excels.  However in the 
current draft the verification step is a "pull" step and so dmd0 cannot 
support acme.  Has there been any thoughts as to how DIX can allow 
parties to sign the message without requiring the "pull" verification step?

I could imagine specifying in core or in an extension attributes such as 
dix:/signature-X509, dix:/signature-X509-subjectname and 
dix:/signature-X509-certificate.  Then monster and acme can relay 
messages without any "pull" operation.

What is preventing these extensions at the moment is the current 
canonicalization algorithm and so I guess all of this was a very long 
winded way of asking whether the canonicalization algorithm described in 
section 5.10.2.7 can be changed to something like.

"For each name-value pair within the message, with the exception of any 
parameters starting with "dix:/signature", treat as a ......... "

Rob

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: John Merrells <[email-masked]>
Date: Fri, 3 Mar 2006 11:08:31 -0800

On 3-Mar-06, at 6:28 AM, Robert Yates wrote:

> Acme corp utilizes monster.com for its hiring process.  Acme has a  
> site license for access to monster.com, however the agreement  
> limits acme to 10 concurrent users.  To keep within this contraint  
> Acme limits the employees that can access monster.com.  It utilizes  
> dmd0 and achieves this by having a user property called dix:/ 
> monster.com/user-key.  Employees that are allowed to use  
> monster.com have this property set.
>
> requests the attribute "dix:/monster.com/user-key" via DIX.  The  
> user is bounced to their homesite, they authenticate and then they  
> get bounced back to the membersite monster.com with the property  
> set and the message signed.
>
> The interesting aspect of the above scenario is that monster.com  
> cannot communicate with the server "intranet.acme.com" it is behind  
> the companies firewall.  It is also worth mentioning that acme,  
> like all large multinationals, has "intranet.acme.com" locked away  
> deep inside a data center.  It can talk to its ldap server and a  
> database server, but nothing else and certainly not "monster.com"

Correct. With dmd0 the enterprise would have to put its Homesite (HS)  
endpoint out in the DMZ and punch a hole through the firewall so that  
the HS code can talk to the enterprise IdM stack. It was a deliberate  
compromise to simplify the implementation of a Membersite (MS).

> It is in scenarios such as these that "push" excels.  However in  
> the current draft the verification step is a "pull" step and so  
> dmd0 cannot support acme.  Has there been any thoughts as to how  
> DIX can allow parties to sign the message without requiring the  
> "pull" verification step?

Yes... we've thought about this...

> I could imagine specifying in core or in an extension attributes  
> such as dix:/signature-X509, dix:/signature-X509-subjectname and  

For sure digital signatures and certificates are a solution, but I'm  
not sure I'd go about it in exactly that way.

John

> canonicalization algorithm and so I guess all of this was a very  
> long winded way of asking whether the canonicalization algorithm  
> described in section 5.10.2.7 can be changed to something like.
>
> "For each name-value pair within the message, with the exception of  
> any parameters starting with "dix:/signature", treat as a ......... "

---

From: David Boreham <[email-masked]>
Date: Fri, 03 Mar 2006 12:50:58 -0700

Robert Yates wrote:

> current draft the verification step is a "pull" step and so dmd0 
> cannot support acme.  Has there been any thoughts as to how DIX can 
> allow parties to sign the message without requiring the "pull" 
> verification step?

Acme.com could push its data to a third party that does have the means 
to make it
available to monster.com.

There's probably a nice business to be made acting as such a third party.

---

From: Robert Yates <[email-masked]>
Date: Fri, 03 Mar 2006 15:00:38 -0500

John Merrells wrote:

>> site license for access to monster.com, however the agreement  limits 
>> acme to 10 concurrent users.  To keep within this contraint  Acme 
>> limits the employees that can access monster.com.  It utilizes  dmd0 
>> and achieves this by having a user property called dix:/ 
>> monster.com/user-key.  Employees that are allowed to use  monster.com 
>> have this property set.
>>
>> get bounced back to the membersite monster.com with the property  set 
>> and the message signed.
>>
>> the companies firewall.  It is also worth mentioning that acme,  like 
>> all large multinationals, has "intranet.acme.com" locked away  deep 
>> inside a data center.  It can talk to its ldap server and a  database 
>> server, but nothing else and certainly not "monster.com"
>
>

I understand the compromise and yes, so monster can verify messages from 
acme, but how does acme verify messages from monster?  Is it acceptable 
for enterprises to allow their servers to access the internet?

> not sure I'd go about it in exactly that way.

I guess what I'm asking here is a scope question. Is it within the scope 
of DIX to allow the message signature to be a signature that can be 
verified without a remote call? and if it isn't within the scope of 
core, is it expected that an extension to the core could do it?

Rob

---

From: John Merrells <[email-masked]>
Date: Fri, 3 Mar 2006 13:13:40 -0800

On 3-Mar-06, at 12:00 PM, Robert Yates wrote:

>> For sure digital signatures and certificates are a solution, but  
>> I'm  not sure I'd go about it in exactly that way.
>
> I guess what I'm asking here is a scope question. Is it within the  
> scope of DIX to allow the message signature to be a signature that  
> can be verified without a remote call? and if it isn't within the  
> scope of core, is it expected that an extension to the core could  
> do it?

I think it's out of scope for DIX, but that whatever comes of out of  
DIX should provide extension points for layering alternative  
verification mechanisms on top. So, for example, in dmd0 we have the  
capabilities definition, discovery, and publishing mechanism, so that  
the HS can advertise alternative mechanisms. A great alternative  
mechanisms would perhaps be a shared secret... or certificates.

John

---

From: Dick Hardt <[email-masked]>
Date: Fri, 3 Mar 2006 14:15:55 -0800

On 3-Mar-06, at 12:00 PM, Robert Yates wrote:

>>
>> Correct. With dmd0 the enterprise would have to put its Homesite  
>> (HS)  endpoint out in the DMZ and punch a hole through the  
>> firewall so that  the HS code can talk to the enterprise IdM  
>> stack. It was a deliberate  compromise to simplify the  
>> implementation of a Membersite (MS).
>
> I understand the compromise and yes, so monster can verify messages  
> from acme, but how does acme verify messages from monster?  Is it  
> acceptable for enterprises to allow their servers to access the  
> internet?

Good question. My experience is that it is often the case, but I  
don't know for sure.

> scope of core, is it expected that an extension to the core could  

I think making PKI a requirement would be a mistake for DIX. I think  
PKI is a logical extension.

Your example can be solved without PKI in this way though:

Internally at acme.com, intranet.acme.com resolves to the Homesite.  
Externally, intranet.acme.com resolves to a host that provides only  
capability discovery and message verification services. The internal  
and external hosts share a secret used to respectively sign and  
verify messages.

We have a demo of a Firefox plug-in where the data is on the user  
machine, and there is a server that shares a secret with the user's  
machine, that is able to verify messages. ie. this works. :)

-- Dick

---

From: Pete Rowley <[email-masked]>
Date: Fri, 03 Mar 2006 13:44:59 -0800

> compromise to simplify the implementation of a Membersite (MS).

Having just implemented a dmd0 homesite that is intended to be behind 
the firewall I have thought a little on this. It seems to me that there 
is nothing preventing the verification code alone from being in the DMZ, 
with the business end of the homesite behind the firewall. This could be 
achieved I suspect by a little script redirection trickery which perhaps 
redirects internal requests to an intranet server acting as the 
homesite. Though I confess I have not attempted this I don't see any 
problem with it in theory.

-- 
Pete

---

From: Robert Yates <[email-masked]>
Date: Tue, 07 Mar 2006 23:25:06 -0500

> Good question. My experience is that it is often the case, but I  

I have asked this question to some folks who setup data centers and am 
waiting on a response, I'll post the response to the mailing list when I 
get it.   However, one colleague that I have discussed this with 
mentioned that enterprises may be reluctant to allow their servers 
access to the internet as they can become susceptible to DoS attacks.

He looked at the current draft and came up with the following potential 
DoS attack that could be mounted against any membersite (intranet or 
internet based).

An attacker sets up rogue homesites that respond very slowly, if at all, 
to verify requests and requests for persona-urls.  The attacker then 
peppers a membersite with messages that need verification from the rogue 
homesites and that also potentially need to resolve rogue persona-urls.  
Given that the homesites are responding slowly to these requests, the 
requests coming out of the membersite start to build up and eventually 
exhaust the servers resources, most notably the threads.

Is this a valid DoS attack? and if so, what approaches are available to 
the membersite to mitigate its effect?

>> scope of core, is it expected that an extension to the core could  do 
>> it?
>

I agree that making PKI a MUST requirement would probably be a mistake, 
but if it turns out that enterprises do not allow their intranet servers 
to access the internet and if making a verify request or retrieving a 
persona-url renders the homesite vulnerable to a DoS attack then it may 
be worth considering PKI as an optional part of the specification.

Rob

---

From: Pete Rowley <[email-masked]>
Date: Wed, 08 Mar 2006 10:35:27 -0800

Robert Yates wrote:

> An attacker sets up rogue homesites that respond very slowly, if at 
> all, to verify requests and requests for persona-urls.  The attacker 
> then peppers a membersite with messages that need verification from 
> the rogue homesites and that also potentially need to resolve rogue 
> persona-urls.  Given that the homesites are responding slowly to these 
> requests, the requests coming out of the membersite start to build up 
> and eventually exhaust the servers resources, most notably the threads.
>
> Is this a valid DoS attack? and if so, what approaches are available 
> to the membersite to mitigate its effect?

I don't think it is, other than the resources expended processing the 
request message - which is akin to a DSA on a web site by requesting 
lots of pages.  The important point to note is that the DMD0 protocol is 
stateless and that for the most part the participants have no need to 
keep any kind of state during a transaction, or indeed to care if the 
transaction is completed, simply dealing with responses as they arrive 
is sufficient.  So there is no point at which any thread will be blocked 
waiting for a response - that would be a broken implementation anyway.

-- 
Pete

---

From: Robert Yates <[email-masked]>
Date: Wed, 08 Mar 2006 14:00:49 -0500

Pete Rowley wrote:

> lots of pages.  The important point to note is that the DMD0 protocol 
> is stateless and that for the most part the participants have no need 
> to keep any kind of state during a transaction, or indeed to care if 
> the transaction is completed, simply dealing with responses as they 
> arrive is sufficient.  So there is no point at which any thread will 
> be blocked waiting for a response - that would be a broken 
> implementation anyway.  

Let's say I am trying to log into amazon.com as gmail.com/robyates.  I 
go to amazon and type in my homesite gmail.com.  I am bounced to gmail, 
I authenticate and then I am bounced back to amazon.  Amazon must now 
validate that I am in fact gmail.com/robyates.  To do this it must make 
two requests, one to retrieve my persona document to check that the 
homesite can make this assertion and then again to verify the message 
signature and it must do all this before letting me in as 
gmail.com/amazon.  Isn't amazon's thread (the thread servicing my login 
attempt) blocked on those two requests? and if an attacker controls the 
homesite then can't he block those threads for quite a while?

Rob

---

From: Pete Rowley <[email-masked]>
Date: Wed, 08 Mar 2006 17:34:56 -0800

Robert Yates wrote:

> Isn't amazon's thread (the thread servicing my login attempt) blocked 
> on those two requests? 

One thread can be made to handle all such requests, so yes, the thread 
would be blocked, but it wouldn't scale to a denial of service through 
thread exhaustion - file handles are another matter, but again this is 
an implementation detail which can be coded for, rather than an inherent 
weakness in the protocol.  It might be useful to identify such forms of 
attack in order that such implementation traps are avoided for any 
officially designated DIX protocol.

-- 
Pete

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 09 Mar 2006 14:14:57 +0100

> officially designated DIX protocol.

Furthermore, if you use a RESTish model, you don't need to have any
thread awaiting at amazon if you pass forth and back a cryptographically
protected session id...

-- 
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

e-mail: [email-masked]
jid:    [email-masked]
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------