Subject: [Geopriv] Multiple URIs for LIS discovery

From: Richard Barnes <[email-masked]>
Date: Wed, 01 Apr 2009 01:08:19 -0400

PROPOSAL: Modify the DHCP option formats in lis-discovery so that more 
than one URI can be provided.

RATIONALE:

The sense in the room on draft-ietf-geopriv-lis-discovery (since 
reflected in the draft) was to remove the certificate fingerprint 
portion.  This means that the client has to be pre-provisioned with 
information about the server's credentials, e.g., a pre-shared key or a 
list of default trust anchors.

On the other hand, the DHCP options in the draft don't allow for the 
DHCP server to provide both an HTTP URI and an HTTPS URI.

The combination of these facts means that security in LIS-discovery is 
all-or-(worse-than-)nothing:
(All) DHCP offers HTTPS and client can authenticate LIS
(Nothing) DHCP offers HTTP
(Worse) DHCP offers HTTPS and client can't authenticate LIS

"Worse" is worse because in that case, it's not just that there's no 
security, there's no HELD at all.  So things like emergency calling do 
not work.

The "Worse" case concerns me, mainly because it seems like clients are 
likely to end up there frequently -- unless the whole Internet agrees on 
a single, small set of CAs, it's unlikely that the LIS will present a 
cert that is valid from the client's perspective.  This happens with 
some regularity even in the web context, where things are reasonably 
well consolidated.  Obviously this is not the level of reliability you 
want for some things, most notably emergency calling.

(You might think that this is not such a huge issue, since the HELD 
client can just decide not to care about authentication.  However, HELD 
clients are likely to be embedded down in operating systems, a few 
layers away from applications, so they may not even know that 
circumstances require them to ignore authentication.)

This all gets better if the discovery option can carry multiple URIs. 
In that case, the document can say that "Server: if you provide an HTTPS 
URI, you SHOULD also provide an HTTP URI."  That way, a client can fall 
back to HTTP if HTTPS fails.  ISTM that the minor additional complexity 
of multiple URIs is worth it, given that it prevents HELD from failing 
badly.

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 1 Apr 2009 00:43:25 -0500

Hi Richard,

I don't like revisiting old issues like this; it spoils the illusion of progress.

As I said privately, I don't think that this is necessarily as bad as you make out.  It's true that some software can't fail soft on authentication.  But even on wget - the most extreme case I could think of - has an option ``--no-check-certificate''.

In this your "worse" case maybe isn't as bad as your "nothing" case.  Narrow APIs that don't provide any authentication controls are probably not appropriate if you intend to implement a policy that allows for no authentication.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Wednesday, 1 April 2009 4:08 PM
> To: 'GEOPRIV'
> Subject: [Geopriv] Multiple URIs for LIS discovery
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]