Re: [Geopriv] Multiple URIs for LIS discovery

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Wed Apr 01 2009 - 01:43:25 EDT

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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Richard Barnes
> Sent: Wednesday, 1 April 2009 4:08 PM
> To: 'GEOPRIV'
> Subject: [Geopriv] Multiple URIs for LIS discovery
>
> 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
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Wed, 1 Apr 2009 00:43:25 -0500

This archive was generated by hypermail 2.1.8 : Wed Apr 01 2009 - 02:01:30 EDT