Subject: [Geopriv] Security considerations for LIS discovery

From: Alissa Cooper <[email-masked]>
Date: Mon, 24 May 2010 18:24:33 +0100

[Sending on behalf of Richard whose email is down.]

Hi all,

In response to some feedback from the Security area during IESG  
review, the
authors of draft-ietf-geopriv-lis-discovery have proposed a  
modification to
the recommended authentication techniques. This email is soliciting
feedback from the working group on whether there are any objections to  
the
proposed change.

Recall that a client discovers a LIS by getting a domain name from  
DHCP and
finding a URI via a U-NAPTR lookup for that name. The question is: If  
that
URI is HTTPS, what name should be checked against the name in the
certificate, the name from DHCP or the domain name in the URI? Prior
versions had recommended checking the name in the certificate against  
the
name in the URI, i.e., the *output* of the U-NAPTR process. This
recommendation is counter to the advice in RFC 3958.

The authors' proposal is to change the document so that the  
recommendation
is to check the authenticated name against the DHCP name (in accordance
with RFC 3958), and to provide some guidance for clients and networks in
how to make this process implementable with current libraries (many of
which only check the name in the URI). Detailed text is below.
If you have any comments on this proposal, please send them to the  
list no
later than 09:00 US EST (GMT-4) on Thursday, 27 May 2010.

Thanks,
--Richard

OLD:
U-NAPTR is entirely dependent on its inputs. In falsifying a domain
name, an attacker avoids any later protections, bypassing them entirely.
To ensure that the access network domain name DHCP option can be relied
upon, preventing DHCP messages from being modified or spoofed by
attackers is necessary. Physical or link layer security are commonplace
methods that can reduce the possibility of such an attack within an
access network; alternatively, DHCP authentication [RFC3118] can provide
a degree of protection against modification or spoofing.

The domain name that is used to authenticated the LIS is the domain name
in the URI that is the result of the U-NAPTR resolution. Therefore, if
an attacker were able to modify or spoof any of the DNS records used in
the DDDS resolution, this URI could be replaced by an invalid URI. The
application of DNS security (DNSSEC) [RFC4033] provides a means to limit
attacks that rely on modification of the DNS records used in U-NAPTR
resolution. Security considerations specific to U-NAPTR are described
in more detail in [RFC4848].

An "https:" URI is authenticated using the method described in Section
3.1 of [RFC2818]. The domain name used for this authentication is the
domain name in the URI resulting from U-NAPTR resolution, not the input
domain name as in [RFC3958]. Using the domain name in the URI is more
compatible with existing HTTP client software, which authenticate
servers based on the domain name in the URI.

NEW:
The domain name that used to authenticate the LIS is the domain name
input to the U-NAPTR process, not the output of that process [RFC3958],
[RFC4848]. As a result, the results of DNS queries do not need
integrity protection.

An "https:" URI is authenticated using the method described in Section
3.1 of [RFC2818]. HTTP client implementations frequently do not provide
a means to authenticate a based on a domain name other than the one
indicated in the request URI, namely the U-NAPTR output. To avoid
having to authenticate the LIS with a domain name that is different to
the one used to identify it, a client MAY choose to reject URIs that
contain a domain name that is different to the U-NAPTR input. To
support endpoints that enforce the above restriction on URIs, network
administrators SHOULD ensure that the domain name in the DHCP option is
the same as the one contained in the resulting URI.

Authentication of a LIS relies on the integrity of the domain name
acquired from DHCP. An attacker that is able to falsify a domain name
circumvents the protections provided. To ensure that the access network
domain name DHCP option can be relied upon, preventing DHCP messages
from being modified or spoofed by attackers is necessary. Physical or
link layer security are commonplace methods that can reduce the
possibility of such an attack within an access network. DHCP
authentication [RFC3118] might also provide a degree of protection
against modification or spoofing.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 May 2010 10:35:02 -0700

"To avoid having to authenticate the LIS with a domain name that is different to
the one used to identify it, a client MAY choose to reject URIs that
contain a domain name that is different to the U-NAPTR input. To
support endpoints that enforce the above restriction on URIs, network
administrators SHOULD ensure that the domain name in the DHCP option is
the same as the one contained in the resulting URI."

Isn't this overly restrictive?  If this constraint were always to be enforced, why would we need U-NAPTR in the first place? 

> From: [email-masked]
> To: [email-masked]
> Date: Mon, 24 May 2010 18:24:33 +0100
> Subject: [Geopriv] Security considerations for LIS discovery
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 25 May 2010 07:04:18 +0800

In short, it’s really hard to implement otherwise.

The IESG were not comfortable with the idea that we were relying on the integrity of the DNS.  The exception granted to LoST was only acceptable because of the deployment model.  Implementation challenges were insufficient justification for another such exception.

--
DHCP returns “example.net”; UNAPTR leads to “lis.example.com”.  RFC 3958 says that you authenticate the server at “lis.example.com” and ensure that its certificate says “example.net”.  Sounds easy.  In practice it isn’t.

This leads to an implementation/deployment deadlock.  Ideally, a deployment can use different domains, and a client is able to authenticate those domains.  In practice, that’s not feasible.

HTTP implementations (and even TLS implementations) struggle to correctly authenticate a domain based on the hostname used to reach it.  A number of implementations that support TLS ignore the authentication part entirely.  Some HTTP/TLS implementations are flexible enough to allow a user access to the parts that would let them roll their own authentication, but others do not.  Even if there is the possibility, implementing authentication as described in RFC 3958 is a non-trivial exercise.

Furthermore, there are complications that make this even more uncertain.  For a LIS that serves multiple domains, the easiest way to address this is to add multiple domain names into subjectAltName.  However, that doesn’t scale well, and it certainly isn’t a cheap option, particularly when you need to add domains.

A more flexible approach would be to rely on the TLS server name indication, but it’s unclear what the implications are.  Furthermore, the implementation problems above extend to server name indication support.  Few enough implementations support server name indication, and even fewer could resolve one DNS name and authenticate on a different name.

--
We chose to allow implementations to ignore all this complexity and in doing so, constrain how networks are deployed.

The alternative is to give up on U-NAPTR.  And that’s why Richard is bringing this back here.  I’d personally prefer not to.

There’s also a hope that we can resolve this problem in another way.  The problem is an old one, and one that we should be able to solve without all this complexity and mess.  I hear that there’s a BoF being prepared on a very similar subject.

--Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, 25 May 2010 3:35 AM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Security considerations for LIS discovery

"

To avoid having to authenticate the LIS with a domain name that is different to

"

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 May 2010 16:22:36 -0700

Giving up on U-NAPTR doesn't necessarily make the problem any easier, since it would still be faced with securing an alternative delegation mechanism (e.g. SRV RRs).   It's also important to understand that the DHCP option can't really be trusted since RFC 3118 has never been deployed (or even implemented, as I understand it). 

This leaves only the following mechanisms to secure LIS discovery:

a. Out-of-band configuration of the discovery domain (which probably shouldn't be over-ridden by the insecure DHCP option)
b. DNSSEC (to securely provide a hostname to connect to)
c. SSL/TLS (to securely connect to the hostname)
d. User input (if the certificate name obtained via c) differs from the discovery domain sufficiently). 

Note that this problem has been encountered by other WGs (e.g. TLS, SIP & XMPP) so it might make sense to reuse some of the existing text. 

From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
Date: Tue, 25 May 2010 07:04:18 +0800
Subject: RE: [Geopriv] Security considerations for LIS discovery

The IESG were not comfortable with the idea that we were relying
on the integrity of the DNS.  The exception granted to LoST was only acceptable
because of the deployment model.  Implementation challenges were insufficient
justification for another such exception.

--

DHCP returns “example.net”; UNAPTR leads to “lis.example.com”. 
RFC 3958 says that you authenticate the server at “lis.example.com” and ensure
that its certificate says “example.net”.  Sounds easy.  In practice it isn’t.

This leads to an implementation/deployment deadlock.  Ideally, a
deployment can use different domains, and a client is able to authenticate
those domains.  In practice, that’s not feasible.

HTTP implementations (and even TLS implementations) struggle to
correctly authenticate a domain based on the hostname used to reach it.  A
number of implementations that support TLS ignore the authentication part
entirely.  Some HTTP/TLS implementations are flexible enough to allow a user
access to the parts that would let them roll their own authentication, but
others do not.  Even if there is the possibility, implementing authentication
as described in RFC 3958 is a non-trivial exercise.

Furthermore, there are complications that make this even more
uncertain.  For a LIS that serves multiple domains, the easiest way to address
this is to add multiple domain names into subjectAltName.  However, that doesn’t
scale well, and it certainly isn’t a cheap option, particularly when you need
to add domains.  

A more flexible approach would be to rely on the TLS server name
indication, but it’s unclear what the implications are.  Furthermore, the
implementation problems above extend to server name indication support.  Few enough
implementations support server name indication, and even fewer could resolve one
DNS name and authenticate on a different name.

--

We chose to allow implementations to ignore all this complexity
and in doing so, constrain how networks are deployed.

The alternative is to give up on U-NAPTR.  And that’s why
Richard is bringing this back here.  I’d personally prefer not to.

There’s also a hope that we can resolve this problem in another
way.  The problem is an old one, and one that we should be able to solve
without all this complexity and mess.  I hear that there’s a BoF being prepared
on a very similar subject.

--Martin

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba

 

"

"

Isn't this overly restrictive?  If this constraint were always to be
enforced, why would we need U-NAPTR in the first place?

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 25 May 2010 07:34:42 +0800

I think that the integrity risks inherent to DHCP are acceptable, even with 3118 (which is, as you note, effectively non-existent).  The current and former security area directors were concerned with the integrity of the DNS.  With or without DNSSEC.

--Martin

From: Bernard Aboba [mailto:[email-masked]]
Sent: Tuesday, 25 May 2010 9:23 AM
To: Thomson, Martin; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Security considerations for LIS discovery

________________________________

--Martin

"

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 25 May 2010 09:21:29 -0400

Hey Bernard,

Your last point is the important one, about this being a large-scale  
problem.  Namely, how can one domain securely delegate a service to  
another, without requiring DNSSEC?  XMPP is working on a solution for  
their domain using authorization certs [draft-ietf-xmpp-dna], but  
there's no general solution right now.  There will likely be a bar BoF  
on the subject in Maastricht (if stpeter and I get our act together).

So what came out of our discussions with the ADs was to try to avoid  
dependency on solving the big problem: For the time being, we'll  
follow the traditional pattern of recommending that implementations do  
the right thing (with the typical "if the user says..." escape  
clause), then adapt to whatever the better solution for secure  
delegation is as it's developed.

The suggestion that networks use the same name in both DHCP and the U- 
NAPTR output URI is really just the intersection of "doing the right  
thing" (i.e., RFC 3958) with what HTTPS libraries do now (i.e., check  
the name in the URI).  It certainly isn't mandatory, and the normal  
escape clause applies.

--Richard

On May 24, 2010, at 7:22 PM, Bernard Aboba wrote:

> Giving up on U-NAPTR doesn't necessarily make the problem any  
> easier, since it would still be faced with securing an alternative  
> delegation mechanism (e.g. SRV RRs).   It's also important to  
> understand that the DHCP option can't really be trusted since RFC  
> 3118 has never been deployed (or even implemented, as I understand  
> it).
>
> a. Out-of-band configuration of the discovery domain (which probably  
> shouldn't be over-ridden by the insecure DHCP option)
> Note that this problem has been encountered by other WGs (e.g. TLS,  
> SIP & XMPP) so it might make sense to reuse some of the existing text.
>
> The IESG were not comfortable with the idea that we were relying on  
> the integrity of the DNS.  The exception granted to LoST was only  
> acceptable because of the deployment model.  Implementation  
> challenges were insufficient justification for another such exception.
>
> --
> DHCP returns “example.net”; UNAPTR leads to “lis.example.com”.  RFC  
> 3958 says that you authenticate the server at “lis.example.com” and  
> ensure that its certificate says “example.net”.  Sounds easy.  In  
> practice it isn’t.
>
> deployment can use different domains, and a client is able to  
> authenticate those domains.  In practice, that’s not feasible.
>
> correctly authenticate a domain based on the hostname used to reach  
> it.  A number of implementations that support TLS ignore the  
> authentication part entirely.  Some HTTP/TLS implementations are  
> flexible enough to allow a user access to the parts that would let  
> them roll their own authentication, but others do not.  Even if  
> there is the possibility, implementing authentication as described  
> in RFC 3958 is a non-trivial exercise.
>
> uncertain.  For a LIS that serves multiple domains, the easiest way  
> to address this is to add multiple domain names into  
> subjectAltName.  However, that doesn’t scale well, and it certainly  
> isn’t a cheap option, particularly when you need to add domains.
>
> indication, but it’s unclear what the implications are.   
> Furthermore, the implementation problems above extend to server name  
> indication support.  Few enough implementations support server name  
> indication, and even fewer could resolve one DNS name and  
> authenticate on a different name.
>
> --
> We chose to allow implementations to ignore all this complexity and  
> in doing so, constrain how networks are deployed.
>
> The alternative is to give up on U-NAPTR.  And that’s why Richard is  
> bringing this back here.  I’d personally prefer not to.
>
> way.  The problem is an old one, and one that we should be able to  
> solve without all this complexity and mess.  I hear that there’s a  
> BoF being prepared on a very similar subject.
>
> --Martin
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 May 2010 09:22:13 -0400

I am struggling a bit in understanding the problem.

Let¹s start with why DHCP returns example.net and UNAPTR leads to
lis.example.com.  Why is that not fixable?  What is hard about getting
consistency in the domain names?

Having said that, SRV works for SIP.  Certainly, the server at the site
mentioned in the SRV entry could have a cert in exactly that name.

Brian

On 5/24/10 7:04 PM, "Thomson, Martin" <[email-masked]> wrote:

> In short, it¹s really hard to implement otherwise.
>  
> The IESG were not comfortable with the idea that we were relying on the
> integrity of the DNS.  The exception granted to LoST was only acceptable
> DHCP returns ³example.net²; UNAPTR leads to ³lis.example.com².  RFC 3958 says
> that you authenticate the server at ³lis.example.com² and ensure that its
> certificate says ³example.net².  Sounds easy.  In practice it isn¹t.
>  
> This leads to an implementation/deployment deadlock.  Ideally, a deployment
> can use different domains, and a client is able to authenticate those
> domains.  In practice, that¹s not feasible.
>  
> HTTP implementations (and even TLS implementations) struggle to correctly
> authenticate a domain based on the hostname used to reach it.  A number of
> implementations that support TLS ignore the authentication part entirely. 
> Some HTTP/TLS implementations are flexible enough to allow a user access to
> the parts that would let them roll their own authentication, but others do
> not.  Even if there is the possibility, implementing authentication as
> described in RFC 3958 is a non-trivial exercise.
>  
> Furthermore, there are complications that make this even more uncertain.  For
> a LIS that serves multiple domains, the easiest way to address this is to add
> multiple domain names into subjectAltName.  However, that doesn¹t scale well,
> and it certainly isn¹t a cheap option, particularly when you need to add
> domains.  
>  
> A more flexible approach would be to rely on the TLS server name indication,
> but it¹s unclear what the implications are.  Furthermore, the implementation
> problems above extend to server name indication support.  Few enough
> implementations support server name indication, and even fewer could resolve
> one DNS name and authenticate on a different name.
>  
> --
> The alternative is to give up on U-NAPTR.  And that¹s why Richard is bringing
> this back here.  I¹d personally prefer not to.
>  
> There¹s also a hope that we can resolve this problem in another way.  The
> problem is an old one, and one that we should be able to solve without all
> this complexity and mess.  I hear that there¹s a BoF being prepared on a very
> similar subject.
>  
> --Martin
>  
> 
> Isn't this overly restrictive?  If this constraint were always to be enforced,
> why would we need U-NAPTR in the first place?
> 
>> > From: [email-masked]
>> > To: [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Tue, 25 May 2010 13:57:23 +0000

> consistency in the domain names?

An ISP might have N customers for whom they run a LIS, but each of those
customers has their own domain name.

For provisioning purposes the customers would rather have the DHCP server
configured with a name that's under their control, with a NAPTR in their
(internal?) DNS pointing at their upstream LIS.  The redirection might be
done directly, or they might use a non-terminal NAPTR pointing at
"lis.example.net". Then when they change ISP they only need change a single
DNS entry.

Also, please note that for the reverse-DNS mechanism proposed in
draft-thomson-geopriv-res-gw-lis-discovery there's no choice but to use the
domain name returned in the LIS URI - we certainly couldn't use
"z.y.x.w.in-addr.arpa".

Ray

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 May 2010 10:16:47 -0400

Sorry, I don't get this.

I certainly understand the customer-of-the-isp issue.

However, at least in my experience, such customers don't want any reference
to their upstream providers in any service.  That means if the customer's
domain is customer.net, they want the lis to be lis.customer.net, and
isp.net has to answer to that name.  If they didn't care, then the DHCP
entry would be allowed to point directly to the ISP (and only one DHCP entry
would need to be changed if the ISP changed)

That is usually pretty straightforward, and ISPs do that.  The LIS would
have multiple credentials and use the appropriate one.

SRVs would have the same issue.  The customer would want the entry in
customer.net's lis SRV to be lis.customer.net, and the DNS resolution of
that would be an address the ISP responds to.

Brian

---

From: Ray Bellis <[email-masked]>
Date: Tue, 25 May 2010 14:33:04 +0000

> have multiple credentials and use the appropriate one.

If the protocol is https (which AIUI is expected) then having the ISP LIS
answer as "lis.customer.net" is impractical - it just doesn't scale (see
Martin's message).

Ray

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 May 2010 10:53:20 -0400

"Doesn't scale"?

The solution of "multiple subjectAltNames" doesn't work, but equipping the
ISP LIS with a separate credential for each of its customers does.  Even
someone like Godaddy does that now for its customers.  You get a cert, you
upload it, the HTTP server uses it.  They probably host tens of thousands of
certs for different domains.

Brian

---

From: Ray Bellis <[email-masked]>
Date: Tue, 25 May 2010 14:57:44 +0000

> certs for different domains.

And would they be doing that with one IP address per cert, or using TLS
server name indication ?

If the latter, how widely is it supported (at the client side) ?

[serious question - I've not been involved in SSL site hosting for several
years]

Ray

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 May 2010 11:20:52 -0400

The IP address is usually common (to many customers).  I guess I can't say
for certainty how it works, but it's something that Apache does with
configuration.

Brian

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 25 May 2010 10:59:58 -0600

I think the new text is much better than the old. The fact that DHCP is more or less unsecured does not bother as much because it is typically secured by the physical network topology. IE, only the DHCP server in my house hands out DHCP address in my house. Trying to rely on DNS sec is not really practical at this point. 

On May 24, 2010, at 11:24 AM, Alissa Cooper wrote:

> In response to some feedback from the Security area during IESG review, the
> authors of draft-ietf-geopriv-lis-discovery have proposed a modification to
> feedback from the working group on whether there are any objections to the
> proposed change.
> 
> Recall that a client discovers a LIS by getting a domain name from DHCP and
> finding a URI via a U-NAPTR lookup for that name. The question is: If that
> versions had recommended checking the name in the certificate against the
> The authors' proposal is to change the document so that the recommendation
> If you have any comments on this proposal, please send them to the list no

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 25 May 2010 11:02:56 -0600

On May 25, 2010, at 8:57 AM, Ray Bellis wrote:

> using TLS

We could certainly mandate that the client (not the severs) support this. It's very common these days. It's really trivial to implement on the client  -basically you just stuff the domain name in an optional header. That way if the servers want to do one IP per certificate, they can just ignore it and not implement it but if they want to use one IP for many domains, they can implement it and it will interoperate with the all clients. 

I forget which one but I seem to recall some other RAI spec took this approach.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 27 May 2010 06:54:03 +0800

It is fixable.

All a client has to do is resolve an IP address and connect with one domain name (“lis.example.com”), then send a server name indication and authenticate using the other (“example.net”).

But that’s just in theory, reducing this to practice is less straightforward.

Both alternative-domain SNI and alternative-domain authentication are hard to implement.  Support for those features in existing HTTP and TLS implementations is…patchy.

I’ll share my solution:

1.       Resolve “lis.example.com” to an IP address.

2.       Add an entry to the hosts file for “example.net” and the IP address that you just got.  (Or intentionally poison your local name resolution cache.)

3.       Modify the LIS URI to include “example.net” instead of “lis.example.com”.

4.       Use the URI (make sure the client supports SNI)

5.       Make sure to remove the hosts file entry when you are done.

YMMV: This interferes with any other uses you might have for “example.net”.  Since that’s likely your local domain, that could be a problem (“xyz.example.net” would be unaffected).

--Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Tuesday, 25 May 2010 11:22 PM
To: Thomson, Martin; Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Security considerations for LIS discovery

Let’s start with why DHCP returns example.net and UNAPTR leads to lis.example.com.  Why is that not fixable?  What is hard about getting consistency in the domain names?

Having said that, SRV works for SIP.  Certainly, the server at the site mentioned in the SRV entry could have a cert in exactly that name.

Brian

--Martin

"

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 26 May 2010 18:54:34 -0400

Doesn't this end up sending the wrong Host header for the URI?

On May 26, 2010, at 6:54 PM, Thomson, Martin wrote:

> It is fixable.
>
> All a client has to do is resolve an IP address and connect with one  
> domain name (“lis.example.com”), then send a server name indication  
> and authenticate using the other (“example.net”).
>
> Both alternative-domain SNI and alternative-domain authentication  
> are hard to implement.  Support for those features in existing HTTP  
> and TLS implementations is…patchy.
>
> I’ll share my solution:
>
> 2.       Add an entry to the hosts file for “example.net” and the IP  
> address that you just got.  (Or intentionally poison your local name  
> resolution cache.)
> YMMV: This interferes with any other uses you might have for  
> “example.net”.  Since that’s likely your local domain, that could be  
> a problem (“xyz.example.net” would be unaffected).
>
> --Martin
>
> Let’s start with why DHCP returns example.net and UNAPTR leads to  
> lis.example.com.  Why is that not fixable?  What is hard about  
> getting consistency in the domain names?
>
> Having said that, SRV works for SIP.  Certainly, the server at the  
> site mentioned in the SRV entry could have a cert in exactly that  
> name.
>
> Brian
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 27 May 2010 07:27:45 +0800

Yep, probably.  But most HTTP client implementations let you override headers.  Some might even let you override the Host header value.  (Firefox XmlHTTPRequest doesn’t ☹).

That might not be a problem.  It’s bad to the same extent that having a “wrong” server name indication is also bad.

--Martin

From: Richard L. Barnes [mailto:[email-masked]]
Sent: Thursday, 27 May 2010 8:55 AM
To: Thomson, Martin
Cc: Brian Rosen; Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Security considerations for LIS discovery

It is fixable.

I’ll share my solution:

--Martin
<snip>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 26 May 2010 18:54:34 -0400