[Geopriv] Measurement security update

Last week I posted an update to draft-thomson-geopriv-held-measurements. This update contains a completely new privacy and security sections. The new security section contains text based on what we discussed at IETF-77 [1].

The updated draft can be found here:
<http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-06>

As Ted sagely observed, the security story is a little depressing. At this stage, I've concentrated on identifying the threat.

That said, there are some hints in the document on mechanisms that might provide some remediation. The proposed measurement request is intended to enable these sorts of solutions.

--Martin

[1] <http://tools.ietf.org/agenda/77/slides/geopriv-3/8%20Location%20Measurements_files/v3_document.htm>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Fwd: New Version Notification for draft-barnes-geopriv-policy-uri-01

Hey all,

James, Martin, and I have put together a new version of the policy-uri draft.  As a reminder, this draft defines a way for a location server to associate location URIs with "policy URIs" that allow the target to control the policy associated with the location URI, and a simple usage of HTTP to manipulate policy (which is forward-compatible with WebDAV / XCAP).

The major unresolved point of discussion among the author team that I would like to bring to the list is whether this draft should also allow the LS to provide a policy URI that is *not* associated with a location URI.  This policy URI would govern queries for the target's location that are not based on a location URI provided through HELD or DHCP, e.g., a third-party query.  

Comments welcome!

Thanks,

--Richard

Begin forwarded message:

From: IETF I-D Submission Tool <idsubmission@ietf.org>

Date: May 30, 2010 7:37:08 PM EDT

To: martin.thomson@andrew.com

Cc: rbarnes@bbn.com,james.winterbottom@andrew.com

Subject: New Version Notification for draft-barnes-geopriv-policy-uri-01 

A new version of I-D, draft-barnes-geopriv-policy-uri-01.txt has been successfully submitted by Martin Thomson and posted to the IETF repository.

Filename: draft-barnes-geopriv-policy-uri
Revision: 01
Title: Location Configuration Extensions for Policy Management
Creation_date: 2010-05-31
WG ID: Independent Submission
Number_of_pages: 16

Abstract:
Current location configuration protocols are capable of provisioning
an Internet host with a location URI that refers to the host's
location.  These protocols lack a mechanism for the target host to
inspect or set the privacy rules that are applied to the URIs they
distribute.  This document extends the current location configuration
protocols to provide hosts with a reference to the rules that are
applied to a URI, so that the host can view or set these rules.



The IETF Secretariat.

[Geopriv] geopriv-arch update

I note that this is update only aims to postpone expiration. What news of sending this (and other GEOPRIV drafts) to the IESG?

Nit: draft-ietf-geopriv-l7-lcp-ps-10 is now RFC 5687.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] ISO 6709 (was: a few tweaks to draft-ietf-geopriv-geo-uri-07)

Thanks!

Carl
>
>> Thanks for the response to my questions. I understand the
>> document stage
>> issue and apologize for getting OGC Member comments into the
>> process so
>> late.
>
> Carl,
>
> sorry if that came out wrong - i fully appreciate that the you took the
> effort of getting the document reviewed in the OGC community, and also
> comiled the comments - it was "just in time" to get the issues below
> into the final document.
>
>> Responses to your questions etc are below.
>
> I've commented on your responses below.
>
>> > For clarification, i could add the single word "depth" to
>> the sentence
>> > cited, so that it reads: "... altitudes below the WGS-84
>> reference geoid
>> > (depths) are signed negative..."
>> >
>> > Would that help?
>>
>> Yes, this would help.
>
> I have now instructed the RFC Editors to modify the sentence as follows:
>
> Coordinates in the Southern and Western hemispheres as well as
> altitudes below the WGS-84 reference geoid (depths) are signed
> negative with a leading dash.
>
>> > - ISO 6709:
>> Perhaps just a note that geo URI can be mapped to 6709 as a
>> recognition of
>> 6709 would remove majority of concerns. FYI - GML incorporates 6709.
>
> I haven't yet instructed the RFC Editors to do so, but given that you
> say it would remove major concerns, i will draft up an (informative)
> note to be included in the final RFC. I will also add an informative
> reference to the ISO standard document.
>
> Alex
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-arch-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : An Architecture for Location and Location Privacy in Internet Applications
Author(s) : R. Barnes, et al.
Filename : draft-ietf-geopriv-arch-02.txt
Pages : 39
Date : 2010-05-27

Location-based services (such as navigation applications, emergency
services, management of equipment in the field) need geographic
location information about Internet hosts, their users, and other
related entities. These applications need to securely gather and
transfer location information for location services, and at the same
time protect the privacy of the individuals involved. This document
describes an architecture for privacy-preserving location-based
services in the Internet, focusing on authorization, security, and
privacy requirements for the data formats and protocols used by these
services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-arch-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [Geopriv] ISO 6709 (was: a few tweaks to draft-ietf-geopriv-geo-uri-07)

> Thanks for the response to my questions. I understand the
> document stage
> issue and apologize for getting OGC Member comments into the
> process so
> late.

Carl,

sorry if that came out wrong - i fully appreciate that the you took the
effort of getting the document reviewed in the OGC community, and also
comiled the comments - it was "just in time" to get the issues below
into the final document.

> Responses to your questions etc are below.

I've commented on your responses below.

> > For clarification, i could add the single word "depth" to
> the sentence
> > cited, so that it reads: "... altitudes below the WGS-84
> reference geoid
> > (depths) are signed negative..."
> >
> > Would that help?
>
> Yes, this would help.

I have now instructed the RFC Editors to modify the sentence as follows:

Coordinates in the Southern and Western hemispheres as well as
altitudes below the WGS-84 reference geoid (depths) are signed
negative with a leading dash.

> > - ISO 6709:
> Perhaps just a note that geo URI can be mapped to 6709 as a
> recognition of
> 6709 would remove majority of concerns. FYI - GML incorporates 6709.

I haven't yet instructed the RFC Editors to do so, but given that you
say it would remove major concerns, i will draft up an (informative)
note to be included in the final RFC. I will also add an informative
reference to the ISO standard document.

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

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 L).

 

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:rbarnes@bbn.com]
Sent: Thursday, 27 May 2010 8:55 AM
To: Thomson, Martin
Cc: Brian Rosen; Bernard Aboba; acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery

 

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").

 

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

<snip>

 

Re: [Geopriv] Security considerations for LIS discovery

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").

 

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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, 25 May 2010 11:22 PM
To: Thomson, Martin; Bernard Aboba; acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery

 

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" <Martin.Thomson@andrew.com> 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 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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, 25 May 2010 3:35 AM
To: acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery

"
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: acooper@cdt.org
> To: geopriv@ietf.org
> Date: Mon, 24 May 2010 18:24:33 +0100
> Subject: [Geopriv] Security considerations for LIS discovery
> 
> [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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

---

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, 25 May 2010 11:22 PM
To: Thomson, Martin; Bernard Aboba; acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery

 

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" <Martin.Thomson@andrew.com> 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 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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, 25 May 2010 3:35 AM
To: acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery

"
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: acooper@cdt.org
> To: geopriv@ietf.org
> Date: Mon, 24 May 2010 18:24:33 +0100
> Subject: [Geopriv] Security considerations for LIS discovery
>
> [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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

---

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] ISO 6709 (was: a few tweaks to draft-ietf-geopriv-geo-uri-07)

Alexander -

Thanks for the response to my questions. I understand the document stage
issue and apologize for getting OGC Member comments into the process so
late.

Responses to your questions etc are below.

Regards

Carl

>
> Carl,
>
> I've been thinking about the comments that you forwarded to the list.
> The draft is now in AUTH48, so we're more or less in a state of the
> document where we're only correcting spelling errors etc., but not
> change the content significantly.
>
> More about the specific topics:
>
> - Altitude clarification:
>
> Section 2 includes that "... altitudes below the WGS-84 reference geoid
> are signed negative...".
>
> For clarification, i could add the single word "depth" to the sentence
> cited, so that it reads: "... altitudes below the WGS-84 reference geoid
> (depths) are signed negative..."
>
> Would that help?

Yes, this would help.

>
> - Lines and Polygons:
>
> It was agreed very early in the process (and confirmed by WG chairs)
> that Lines and Polygons would be out of scope for the document. PIDF-LO
> already covers such elements.

Understand. Thanks.
>
> - ISO 6709:
>
> (Disclaimer: I have only access to the German DIN EN 6709:2009 here, so
> my knowledge might be limited to that version of the standard)
>
> Like Martin, i admit i heard of that format for the first time in your
> posting - blind spot for me as well (and i haven't found any discussion
> about it in the GEOPRIV working group archives either). I think that the
> mapping from a "geo" URI to an ISO6709 representation is trivial, and
> can be performed without additional instructions in the draft.

Perhaps just a note that geo URI can be mapped to 6709 as a recognition of
6709 would remove majority of concerns. FYI - GML incorporates 6709.

>
> (Side note: I'm a little bit concerned about the option in the string
> representation to leave out the CRS definition - particularly with the
> option to have positive depths as well as positive elevation - how would
> i know whether 40.44+70.2+221.5/ is 222.5 meters above or below whatever
> reference plane? I fully agree with Martin that DMS representations are
> dangerous, particularly to "non-GIS" users)

Yes, I also agree that DMS representation is not useful. And totally agree
with your CRS note.

>
> For the XML mapping of ISO6709, we have already specified a mapping to
> another, more recent ISO standard (GML) in the document - so it should
> be easy to map the ISO GML to ISO 6709 XML (particularly because GPL
> seems to be based on GML types anyway).
>
> For those reason, i think that we shouldn't include another mapping in
> the document. If there's demand for the specification of such a mapping,
> we could still do it in a seperate Information document.

Agreed.

>
> Alex
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] ISO 6709 (was: a few tweaks to draft-ietf-geopriv-geo-uri-07)

Carl,

I've been thinking about the comments that you forwarded to the list.
The draft is now in AUTH48, so we're more or less in a state of the
document where we're only correcting spelling errors etc., but not
change the content significantly.

More about the specific topics:

- Altitude clarification:

Section 2 includes that "... altitudes below the WGS-84 reference geoid
are signed negative...".

For clarification, i could add the single word "depth" to the sentence
cited, so that it reads: "... altitudes below the WGS-84 reference geoid
(depths) are signed negative..."

Would that help?

- Lines and Polygons:

It was agreed very early in the process (and confirmed by WG chairs)
that Lines and Polygons would be out of scope for the document. PIDF-LO
already covers such elements.

- ISO 6709:

(Disclaimer: I have only access to the German DIN EN 6709:2009 here, so
my knowledge might be limited to that version of the standard)

Like Martin, i admit i heard of that format for the first time in your
posting - blind spot for me as well (and i haven't found any discussion
about it in the GEOPRIV working group archives either). I think that the
mapping from a "geo" URI to an ISO6709 representation is trivial, and
can be performed without additional instructions in the draft.

(Side note: I'm a little bit concerned about the option in the string
representation to leave out the CRS definition - particularly with the
option to have positive depths as well as positive elevation - how would
i know whether 40.44+70.2+221.5/ is 222.5 meters above or below whatever
reference plane? I fully agree with Martin that DMS representations are
dangerous, particularly to "non-GIS" users)

For the XML mapping of ISO6709, we have already specified a mapping to
another, more recent ISO standard (GML) in the document - so it should
be easy to map the ISO GML to ISO 6709 XML (particularly because GPL
seems to be based on GML types anyway).

For those reason, i think that we shouldn't include another mapping in
the document. If there's demand for the specification of such a mapping,
we could still do it in a seperate Information document.

Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

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

> using TLS
> server name indication ?

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.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

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:

> [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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

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

On 5/25/10 10:57 AM, "Ray Bellis" <Ray.Bellis@nominet.org.uk> wrote:

>> "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.
>
> 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
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

> "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.

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

"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

On 5/25/10 10:33 AM, "Ray Bellis" <Ray.Bellis@nominet.org.uk> wrote:

> On 25/05/2010 15:16, "Brian Rosen" <br@brianrosen.net> wrote:
>
>> 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.
>
> 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
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] FW: I-D Action:draft-thomson-geopriv-relative-location-01.txt

Content-Type: text/plain Content-ID: <2010-05-25072450.I-D@ietf.org> This version contains the agreed compromise of having the reference be a
refinement of the base location. It also includes a schema, with the
examples updated to conform to the schema, definitions for 2D and 3D CRS
names, an expanded IANA considerations section and some small text clean up.

I believe this document is sufficiently good enough that it should be
acceptable as a work group item.

Brian

------ Forwarded Message
From: <Internet-Drafts@ietf.org>
Reply-To: <internet-drafts@ietf.org>
Date: Tue, 25 May 2010 07:30:02 -0700 (PDT)
To: <i-d-announce@ietf.org>
Subject: I-D Action:draft-thomson-geopriv-relative-location-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Title : Relative Location Representation
Author(s) : M. Thomson, et al.
Filename : draft-thomson-geopriv-relative-location-01.txt
Pages : 34
Date : 2010-05-25

This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a
reference point. The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several
shapes. Optionally, a reference to a secondary document (such as a
map image) can be included, along with the relationship of the map
coordinate system to the reference/offset coordinate system to allow
display of the map with the reference point and the relative offset.
Also included in this document is a Type/Length/Value (TLV)
representation of the relative location for use in other protocols
that use TLVs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-thomson-geopriv-relative-location-
01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------ End of Forwarded Message

Re: [Geopriv] Security considerations for LIS discovery

On 25/05/2010 15:16, "Brian Rosen" <br@brianrosen.net> wrote:

> 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.

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

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

On 5/25/10 9:57 AM, "Ray Bellis" <Ray.Bellis@nominet.org.uk> wrote:

> On 25/05/2010 14:22, "Brian Rosen" <br@brianrosen.net> wrote:
>
>> 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?
>
> 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
>
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

On 25/05/2010 14:22, "Brian Rosen" <br@brianrosen.net> wrote:

> 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?

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Security considerations for LIS discovery

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" <Martin.Thomson@andrew.com> 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 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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, 25 May 2010 3:35 AM
To: acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery

"
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: acooper@cdt.org
> To: geopriv@ietf.org
> Date: Mon, 24 May 2010 18:24:33 +0100
> Subject: [Geopriv] Security considerations for LIS discovery
>
> [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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

---

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv