Subject: [Ecrit] [Fwd: RE: draft-ietf-ecrit-lost-09.txt has been submitted.]

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Mar 2008 21:51:23 +0300

FYI

-------- Original Message --------
Subject: 	RE: draft-ietf-ecrit-lost-09.txt has been submitted.
Date: 	Mon, 31 Mar 2008 20:34:10 +0300
From: 	<[email-masked]>
To: 	<[email-masked]>, <[email-masked]>
CC: 	<[email-masked]>, <[email-masked]>, <[email-masked]>
References: 	<p06240602c412fe540c77@[129.46.226.27]>

Ted,

I'm not fully satisfied with -09 yet.

The existing DDDS specs (in particular, the security considerations
text in RFC 3958) are quite clear that server identity check is
usually needed, but the identity that has to be checked is the
input to NAPTR processing, not the output.

Simply saying "The use of server identity checks is also
RECOMMENDED, as described in [4]" does not quite capture this
important distinction, and could even lead to interop problems if
the implementor assumes that this intended to follow RFC 3958.
(Also, "RECOMMENDED" would benefit from couple of sentences
describing when they're not needed.)

It seems that in the particular emergency deployment you're most
concerned with, solving this particular problem isn't actually
feasible (unless you have DNSSEC).

However, hardcoding LoST to use the NAPTR processing output in the
identity check also means that other deployments of LoST -- where
implementing the checks as outlined in RFC 3958 (with e.g. certs
containing the NAPTR input) would be totally feasible -- won't be
secure without DNSSEC.

Suggested rewriting on this section that would be more acceptable
to me (not very polished text yet, feel free to suggest
improvements):

   To avoid an attacker modifying the query or its result, TLS MUST
   be implemented and SHOULD be used.  Use is RECOMMENDED both for
   clients' queries to servers and for queries among servers; this
   latter recommendation is to help avoid LoST cache poisoning
   attacks by replacing answers given to caching LoST servers.

   The use of server identity checks with TLS, as described in
   Section 3.1 of [4] is also RECOMMENDED.  Omitting the server
   identity check allows an attacker to masquerade as a LoST
   server, so this approach should be used only when getting any
   answer, even from a potentially malicious LoST server, is
   preferred over closing the connection (and thus not getting any
   answer at all). The host name compared against the server
   certificate is the host name in the URI, not the DNS name used
   as input to NAPTR resolution.

   Note that the security considerations in [RFC3958] recommend
   comparing the input of NAPTR resolution to the certificate, not
   the output (host name in the URI). This approach was not chosen,
   because in emergency service use cases, it is likely that
   deployments will see a large number of inputs (such as company
   and other organization names) to the NAPTR processing resolving
   to a single server, typically run by a local emergency services
   authority. In this case, checking the input to the NAPTR
   resolution against the certificates provided by the LoST server
   would be impractical, as the list of organizations using it
   would be large, subject to rapid change, and unknown to the LoST
   server operator.

   This use of server identity check does leave open the
   possibility of DNS based attacks, as the NAPTR records may be
   altered by an attacker.  The attacks include, for example,
   interception of DNS packets between the client and the recursive
   name server, DNS cache poisoning, and intentional modifications
   by the recursive name server; see [RFC3833] for more
   comprehensive discussion.

   DNSSEC [20] can be used to protect against these threats.  While
   DNSSEC is incompletely deployed, users should be aware of the
   risk, particularly when they are requesting NAPTR records in
   environments where the local recursive name server, or the
   network between the client and the local recursive name server,
   is not considered trustworthy.

   LoST deployments which are unable to use DNSSEC and unwilling to
   trust DNS resolution without DNSSEC, cannot use the NATPR based
   discovery of LoST servers as-is. When suitable configuration
   mechanisms are available, one possibility is to configure the
   LoST server URIs (instead of the domain name to be used for
   NAPTR resolution) directly. Future specifications for applying
   LoST in non-emergency services may also specify additional
   discovery mechanisms and name matching semantics.

One alternative which I suggested in a private email earlier would
be to provide a "LoST discovery security mode" configuration
option. This could have e.g. three different values: "loose" would
be the name matching described above; "strict" would compare the
NAPTR input with the certificate (this is what RFC3958 recommends,
as it doesn't rely on DNSSEC), and "dnssec" would be the current
mechanism + a check that DNSSEC was actually used. This would
allow the emergency service scenario to work as-is, but would give
flexibility for future, non-emergency deployments. I haven't received
any comments about that proposal yet.

Best regards,
Pasi 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Ted Hardie
> Sent: 28 March, 2008 22:12
> To: [email-masked]
> Cc: Andrew Newton; [email-masked]; Henning Schulzrinne
> Subject: draft-ietf-ecrit-lost-09.txt has been submitted.
> 
> The new version of this draft is now available at:
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt
> 
> You may have seen an announcement for 08 earlier in the day.
> After it was submitted, Hannes realized that the URI pointer for
> reference 22 was still incorrect, and the later update corrects this
> as well.  The authors believe that this draft resolves all of 
> the outstanding
> DISCUSSes. 
> 
> The resolution of one issue raised by Cullen may be non-obvious.  In
> his revised DISCUSS, Cullen notes:
> 
> >The document contains text such as
> >      The < Polygon > element is described in Section 5.2.2 
> of [13].  The
> >      restriction to 16 points for a polygon contained in 
> Section 7.2.2
> >      of [12] is not applicable to this document.
> >and text like
> >  When clients place a < Polygon >, < Circle >, < Ellipse > 
> or < ArcBand >
> >  element within the < location > element then it indicates that the
> >  query is about any point contained in the given area; it is left to
> >  the server to select an appropriate matching algorithm, 
> such as using
> >  computing the centroid.
> >I can not see how this draft can be implemented without 
> reading Ref 13 which defined the shapes such as Polygon.
> 
> These shapes are defined with reference to the base OGC GML specs and
> are called out specifically in "GML 3.1.1 PIDF-LO Shape Application
> Schema for use by the Internet Engineering Task Force (IETF)" 
> which is normatively
> referenced (as reference 12) in this paragraph.  The authors 
> believe that
> the additional information found in [13] is valuable context 
> but can be treated as informative
> given the information in [12] and the note in-line that the 
> 16 point restriction
> does not apply.
> 
> The authors suggest that they work with the RFC editor on 
> final submission to work
> out how to handle a dual reference (to both [12] and [13]) 
> when one is normative
> and one informative or alternatively, if the progress of [13] 
> is sufficient, to both of
> them as normative.  The authors do not believe a reference 
> hold for [13] would
> be appropriate in this case, given the relationship to [12].
> 
> 			regards,
> 				Ted Hardie
> 
> 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit