Subject: RE: [dix] DIX in the extranet

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 8 Mar 2006 10:57:43 -0800

I think that DoS attacks are going to be a major issue that any protocol in
this space is going to have to cope with.

In particular attacks against the auth provider are going to require serious
attention. I am less worried about auth providers attacking relying parties.
The relying parties should soon learn not to connect to abusive auth
providers.

PKI is one of the tools we can use to help here.

* The large auth providers are the ones most likely to be attacked, the
small fry are probably not worth bothering with.

* PKI should only be used to establish a framework of trust, after an
initial bilateral key exchange using PKI the credentials can be cached for
future use.

Just so folk are straight here, VeriSign is not an exclusive provider of PKI
based authentication, we have a large and growing symmetric key based
product line. I am just as happy with the idea of managing a kerberos style
key distribution based system as PKI, there are cases where that is the
right approach.

> -----Original Message-----
> From: Robert Yates [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 10:25 AM
> To: Digital Identity Exchange
> Subject: Re: [dix] DIX in the extranet
> 
> Hallam-Baker, Phillip wrote:
> 
> >I don't think that the design is far enough advanced to know what 
> >authentication techniques are required, let alone to throw out an 
> >entire class of solutions.
> >  
> >
> I didn't mean to imply that we throw anything out, am just 
> asking if others think that there is a DoS vulnerability in 
> the current draft.
> 
> Rob
> 
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 
_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Robert Yates <[email-masked]>
Date: Thu, 09 Mar 2006 15:44:21 -0500

>this space is going to have to cope with.
Agreed, I apologize for bringing this up again, but I think it very 
important that we get this right and am interested in the thoughts of 
others as to whether dmd0 should be tightened to help protect against 
DoS attacks.

As far as I can make out, it is going to be fairly hard to protect 
against DoS if we develop a protocol that requires a membersite's thread 
to block wait (either directly or indirectly) on the retrieval of two 
urls from potentially unknown and untrusted sources.  I know that 
Phillip mentioned that membersites could "learn" not to trust certain 
sources, but should we instead look at ways of avoiding these calls?

I guess what I am asking is whether it should be a design consideration 
of DIX to minimize the synchronous calls that must be made to untrusted 
sites when verifying messages, particularly those messages asserting a 
persona-url?

If this is a consideration worth persuing then I wanted to jot down a 
few approaches to reducing the need for these calls and see what others 
think..

1) PKI, this would obviously remove the need to make the verify call, 
but I agree that PKI should not be a MUST requirement.
2) Only call the remote site once to generate a shared secret and then 
use the secret to verify signatures coming from that site.  This would 
be akin to openid's associate mode.
3) Use Phillip's suggestion of SRV records as a discovery mechanism, 
instead of looking up the persona-url.

Just some thoughts,

Rob

---

From: [email-masked]
Date: Thu, 09 Mar 2006 20:07:51 -0500

The thread on DoS in dmd0 got me thinking about the meaning of the verification step in dmd0.  As stated in that thread, the verification step might be a concern, since a membersite may be blocking on a response from an unknown homesite.  I started to think about eliminating the verification (and the signature that goes with it).  What requirement is the verification step meeting?
 
At the most basic level, a DIX protocol is simply providing a convenient way to transfer a set of self-asserted attributes from the user to the membersite - by way of the homesite.  In this model the homesite is simply storing the attributes on the user behalf and, consistantly with Identity Law #1, revealing them only with the user's consent.  It does not do any checking that they correctly represent the user in any way.
 
At this level the only thing the signature means is "I sent this exact set of attributes because the user asked me to."  This just doesn't seem very useful to the membersite.  The entire set of attributes could be replaced by a MITM that runs its own homesite, or that has an account at the specified homesite.
 
Can we agree that for this level of requirement, the signature and verification are not required?
 
Things get more interesting when properties (attributes) like Persona URL come into play.  I'll try to write up some thoughts on that tomorrow.
 
Terry Hayes
AOL Corp.

---

From: Robert Yates <[email-masked]>
Date: Thu, 09 Mar 2006 22:26:41 -0500

[email-masked] wrote:

> The thread on DoS in dmd0 got me thinking about the meaning of the 
> verification step in dmd0.  As stated in that thread, the verification 
> step might be a concern, since a membersite may be blocking on a 
> response from an unknown homesite.  I started to think about 
> eliminating the verification (and the signature that goes with it).  
> What requirement is the verification step meeting?
>  
> At the most basic level, a DIX protocol is simply providing a 
> convenient way to transfer a set of self-asserted attributes from the 
> user to the membersite - by way of the homesite.  In this model the 
> homesite is simply storing the attributes on the user behalf and, 
> consistantly with Identity Law #1, revealing them only with the user's 
> consent.  It does not do any checking that they correctly represent 
> the user in any way.
>  
> At this level the only thing the signature means is "I sent this exact 
> set of attributes because the user asked me to."  This just doesn't 
> seem very useful to the membersite.  The entire set of attributes 
> could be replaced by a MITM that runs its own homesite, or that has an 
> account at the specified homesite.
>  

Am not sure that I agree with this.  There are instances where it is 
important whom the homesite is i.e. who is making the assertion about 
the attributes.  I also don't believe that the attributes are always 
self-asserted and have been assuming that a user probably has many sites 
that assert attributes about the user and act as homesites, e.g. my 
bank, my state, etc.

A classic example is the driving license analogy.  The membersite wants 
to know how old the user is.  They are not going to accept an assertion 
about the users age from any homesite.  It has to be from some 
"homesite" that they trust, in my case, as I live in mass, probably 
"http://www.mass.gov".  For these cases they need the verification step.

I agree that there are many instances where the verification step is not 
required, but I think it is important step for many more attributes than 
just the persona-url.

Rob

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Mar 2006 15:46:42 -0800

On 9-Mar-06, at 12:44 PM, Robert Yates wrote:

> important that we get this right and am interested in the thoughts  
> of others as to whether dmd0 should be tightened to help protect  
> against DoS attacks.
>
> against DoS if we develop a protocol that requires a membersite's  
> thread to block wait (either directly or indirectly) on the  
> retrieval of two urls from potentially unknown and untrusted  
> sources.  I know that Phillip mentioned that membersites could  
> "learn" not to trust certain sources, but should we instead look at  
> ways of avoiding these calls?
>
> I guess what I am asking is whether it should be a design  
> consideration of DIX to minimize the synchronous calls that must be  
> made to untrusted sites when verifying messages, particularly those  
> messages asserting a persona-url?
>
> If this is a consideration worth persuing then I wanted to jot down  
> a few approaches to reducing the need for these calls and see what  
> others think..
>
> 1) PKI, this would obviously remove the need to make the verify  
> call, but I agree that PKI should not be a MUST requirement.

PKI resolves the requirement for the MS to call other servers.

It would be possible for a MS to only work with Homesites that used  
PKI for verification. This would allow a Membersite to choose the  
methodology used for verification, without requiring ALL membersites  
to support PKI.

> 2) Only call the remote site once to generate a shared secret and  
> then use the secret to verify signatures coming from that site.   
> This would be akin to openid's associate mode.

I think having a shared secret mode is a good option for improving  
performance. Just as in OpenID, having it as an option rather then a  
requirement is best as it requires state management and additional  
overhead if little interaction between that Homesite and Membersite.  
Note that it does not solve DoS since bad server can repeatedly fail  
to provide shared secret.

> 3) Use Phillip's suggestion of SRV records as a discovery  
> mechanism, instead of looking up the persona-url.

Does not solve DoS as bad server can withhold returning SRV records.

Completely agree that we need to consider these types of attacks.

Given that we have not got a WG started yet, I'm wondering if we are  
getting ahead of ourselves though?

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Mar 2006 22:04:06 -0800

On 9-Mar-06, at 7:26 PM, Robert Yates wrote:

>> verification step in dmd0.  As stated in that thread, the  
>> verification step might be a concern, since a membersite may be  
>> blocking on a response from an unknown homesite.  I started to  
>> think about eliminating the verification (and the signature that  
>> goes with it).  What requirement is the verification step meeting?
>> convenient way to transfer a set of self-asserted attributes from  
>> the user to the membersite - by way of the homesite.  In this  
>> model the homesite is simply storing the attributes on the user  
>> behalf and, consistantly with Identity Law #1, revealing them only  
>> with the user's consent.  It does not do any checking that they  
>> correctly represent the user in any way.
>>  At this level the only thing the signature means is "I sent this  
>> exact set of attributes because the user asked me to."  This just  
>> doesn't seem very useful to the membersite.  The entire set of  
>> attributes could be replaced by a MITM that runs its own homesite,  
>> or that has an account at the specified homesite.

The Homesite is authoritative that the user is the persona-url. If  
the persona-url is in the message, then the Membersite needs to  
verify that the Homesite did make the claim that the user is that  
persona-url.

I agree with you that that Membersite does not need to verify the  
message if only self asserted claims are coming from the user.

>
> Am not sure that I agree with this.  There are instances where it  
> is important whom the homesite is i.e. who is making the assertion  
> about the attributes.  I also don't believe that the attributes are  
> always self-asserted and have been assuming that a user probably  
> has many sites that assert attributes about the user and act as  
> homesites, e.g. my bank, my state, etc.
>
> A classic example is the driving license analogy.  The membersite  
> wants to know how old the user is.  They are not going to accept an  
> assertion about the users age from any homesite.  It has to be from  
> some "homesite" that they trust, in my case, as I live in mass,  
> probably "http://www.mass.gov".  For these cases they need the  
> verification step.

I would call this an Authoritative Site. In these cases I think using  
PKI is appropriate.

>
> I agree that there are many instances where the verification step  
> is not required, but I think it is important step for many more  
> attributes than just the persona-url.

As I mention above, the verification is required if the persona-url  
is in the message.

-- Dick

---

From: Robert Yates <[email-masked]>
Date: Fri, 10 Mar 2006 09:27:42 -0500

> Does not solve DoS as bad server can withhold returning SRV records. 

I agree that the above two suggestions do not eliminate the possibility 
of DoS.  The intent behind the suggestions was that they should make it 
easier to detect/protect against a DoS.  The thinking being that fewer 
calls need to be made during normal operation to remote sites.  The 
membersite only needs to establish a shared secret or lookup a homesites 
SRV record once.  If it finds that many requests are waiting for shared 
secrets or SRV record responses it can abort further requests for these 
items until the backlog has cleared. It can, however, still continue 
normal operations to homesites with which it already shares a secret and 
whose SRV record has been cached.

> getting ahead of ourselves though?

Point taken, apologies,

Rob

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Mar 2006 09:27:53 -0800

On 10-Mar-06, at 6:27 AM, Robert Yates wrote:

> Dick Hardt wrote:
>
>>> 2) Only call the remote site once to generate a shared secret  
>>> and  then use the secret to verify signatures coming from that  
>>> site.   This would be akin to openid's associate mode.
>>
>> I think having a shared secret mode is a good option for  
>> improving  performance. Just as in OpenID, having it as an option  
>> rather then a  requirement is best as it requires state management  
>> and additional  overhead if little interaction between that  
>> Homesite and Membersite.  Note that it does not solve DoS since  
>> bad server can repeatedly fail  to provide shared secret.
>>
> I agree that the above two suggestions do not eliminate the  
> possibility of DoS.  The intent behind the suggestions was that  
> they should make it easier to detect/protect against a DoS.  The  
> thinking being that fewer calls need to be made during normal  
> operation to remote sites.  The membersite only needs to establish  
> a shared secret or lookup a homesites SRV record once.  If it finds  
> that many requests are waiting for shared secrets or SRV record  
> responses it can abort further requests for these items until the  
> backlog has cleared. It can, however, still continue normal  
> operations to homesites with which it already shares a secret and  

Similiarly, a Homesite that takes a long time to respond or does not  
respond can be logged and the Membersite could prompt the user when  
that Homesite is used and ask them if they really want to use that  
Homesite, or ask the user for another Homesite.

Just as the SRV record is cached, the the Homesite and persona-url  
document could be cached using standard HTTP caching or some caching  
meta data in the document.

There is lots more to discuss here. Please don't interpret my  
comments that I think dmd0 is *the* way to solve the problem.  
Hopefully we will get a WG so that more people are looking at the  
solution space.

>
>> Given that we have not got a WG started yet, I'm wondering if we  
>> are  getting ahead of ourselves though?
>
> Point taken, apologies,

None needed. Good discussion. I think it is a good indication that a  
WG would make sense! :-)

-- Dick

---

From: [email-masked]
Date: Fri, 10 Mar 2006 14:59:41 -0500

What I meant by "most basic level" was storage and transfer of attributes asserted by the user.  You could design a DIX protocol where that is the only service provided.  In that case, there is no need for verification.  From their responses, I think both Dick and Rob agree with this.
 
To summarize:  a DIX protocol could be defined that allowed the signature to be optional in the Exchange Process.  This protocol would support transfer of self-asserted attributes.  The Verification Process would not be required.  This eliminates the need for the membersite to communicate with an arbitrary (untrusted?) homesite, and eliminates a potential DoS problem.
 
I know that there are many times that attributes cannot be self-asserted.  Carl Ellison made the case for that many years ago in his SPKI proposals - and I'm sure he wasn't first or last to do so.  In those cases, it's clearly important to determine who made the assertion, whether they can be trusted, and whether the assertion is valid.  Verification will be necessary in this case.  However, as Phillip pointed out, a DoS problem is not likely to last very long in this case.  The membersite will just stop trusting the homesite to make assertions.
 
Terry Hayes
AOL Corp.
 
-----Original Message-----
From: Robert Yates <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Thu, 09 Mar 2006 22:26:41 -0500
Subject: Re: What does verification mean? (was Re: [dix] DoS in dmd0)

[email-masked] wrote: 
 
> The thread on DoS in dmd0 got me thinking about the meaning of the > verification step in dmd0. As stated in that thread, the verification > step might be a concern, since a membersite may be blocking on a > response from an unknown homesite. I started to think about > eliminating the verification (and the signature that goes with it). > What requirement is the verification step meeting? 
> > At the most basic level, a DIX protocol is simply providing a > convenient way to transfer a set of self-asserted attributes from the > user to the membersite - by way of the homesite. In this model the > homesite is simply storing the attributes on the user behalf and, > consistantly with Identity Law #1, revealing them only with the user's > consent. It does not do any checking that they correctly represent > the user in any way. 
> > At this level the only thing the signature means is "I sent this exact > set of attributes because the user asked me to." This just doesn't > seem very useful to the membersite. The entire set of attributes > could be replaced by a MITM that runs its own homesite, or that has an > account at the specified homesite. 
> > Can we agree that for this level of requirement, the signature and > verification are not required? 
 
Am not sure that I agree with this. There are instances where it is important whom the homesite is i.e. who is making the assertion about the attributes. I also don't believe that the attributes are always self-asserted and have been assuming that a user probably has many sites that assert attributes about the user and act as homesites, e.g. my bank, my state, etc. 
 
A classic example is the driving license analogy. The membersite wants to know how old the user is. They are not going to accept an assertion about the users age from any homesite. It has to be from some "homesite" that they trust, in my case, as I live in mass, probably "http://www.mass.gov". For these cases they need the verification step. 
 
I agree that there are many instances where the verification step is not required, but I think it is important step for many more attributes than just the persona-url. 
 
Rob

---

From: John Merrells <[email-masked]>
Date: Fri, 10 Mar 2006 12:32:26 -0800

On 10-Mar-06, at 11:59 AM, [email-masked] wrote:

> What I meant by "most basic level" was storage and transfer of  
> attributes asserted by the user.  You could design a DIX protocol  
> where that is the only service provided.  In that case, there is no  
> need for verification.  From their responses, I think both Dick and  
> Rob agree with this.

I think you've teased out a simple but important point there Terry.

>  To summarize:  a DIX protocol could be defined that allowed the  
> signature to be optional in the Exchange Process.  This protocol  
> would support transfer of self-asserted attributes.  The  
> Verification Process would not be required.  This eliminates the  
> need for the membersite to communicate with an arbitrary  
> (untrusted?) homesite, and eliminates a potential DoS problem.

I'm interested in the idea that a useful protocol could be defined  
just for
moving identity data items around. And then those could be either
self-asserted attribute values or signed claims, and there could be
multiple ways of encoding a claim and multiple ways of verifying that
claim.

In these terms, in dmd0, we have the HS generating an authentication
claim, which is encoded in some message parameters, and then
verified via a call-back mechanism. It might have been interesting for
us  to have taken a more generic approach and to have defined that
as a simple-claim-verified-by-callback mechanism layered on top of
the protocol that could have been used for other things.

John