[Geopriv] Proposal for LIS discovery (Auth)

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Wed Nov 26 2008 - 01:25:50 EST

Hi All,

I'd like to put the proposed changes out of LIS discovery to the list before I start on document surgery. I've done a little investigation, and I think that the following approach is workable. Let me know if you think otherwise.

This email regards the LIS authentication solutions. I'm sending another email on removing reverse DNS.

A suggestion was made at the meeting that removes the need for a domain certificate at a LIS. If a certificate fingerprint were provided with the LIS URI, the client would be able to use this fingerprint for authentication, rather than relying upon a domain name cert.

This requires the addition of a certificate fingerprint to the DHCP option. This would have to be optional (to accommodate the non-TLS option), but would allow for simpler authentication of the server.

Advantages:
 - Self-signed certificates can be used by a LIS.
 - The assertion that is made is not related to ownership of a domain name. That is, the DHCP server is the one making the assertion about ability to provide location information, not the CA.
 - It is MUCH easier to validate the certificate (no need to validate a certificate chain up to a root CA, no revocation lists/OCSP/etc...).

Disadvantages:
 - Additional protocol complexity.
 - The overall security picture changes very little. Spoofing the DHCP response still circumvents any protection provided.

Now, there is nothing preventing the certificate from also being a domain cert, but we cannot require that the client validate it, because that would negate two of the advantages and it would not buy any additional guarantees (other than--perhaps--a linkage to some identity that might {not} be useful).

I propose to retain domain-name based authentication as a backup for the case where the fingerprint is not available (either it is not included in the DHCP option, or for when other unspecified methods of discovery are used). Basically, this means that the absence of a fingerprint indicates that the domain name trust chain be used.

In detail, my proposal is to include this fingerprint in the DHCP option as an optional component. This would be the format:

  {
    certificate fingerprint algorithm (8 bits)
      -- 0 = null
      -- 1 = use SHA-1 fingerprint;
      -- create IANA registry for other algorithms
    certificate fingerprint length in bytes (8 bits)
    certificate fingerprint (length as specified above, less 1 for the code)
  }
    ...certificate fingerprint can be repeated, last item uses 0 for algorithm
  LIS URI (the rest of the option)

(An alternative is to burn extra code points from the ever-diminishing space available and separate the fingerprint and URI. I don't like that idea, even if it would be slightly simpler.)

If an http: URI is used, the fingerprint fields must be omitted. For https:, if the no fingerprints are provided, the domain name method is used (with the existing RFC2818 text); if fingerprints are included, the fingerprint of the certificate is compared with the fingerprint provided. Only one fingerprint needs to be checked; check the first supported. Multiple fingerprints allow for backward compatibility with new hash functions.

Exception cases are simple: If a fingerprint is included and any one of the fingerprints doesn't match for ANY reason, including a length mismatch, authentication fails. If none of the provided fingerprint algorithms are supported, authentication fails. In either case, continue discovery. Do not permit downgrade/fallback.

For backward compatibility, if more than one fingerprint is specified and some are not supported, check the first one that is supported. However, if fingerprints are included and none of the algorithms are supported: fail.

No change on the concatenation front (RFC3396). Also, no mention of the work being done to make DHCP more resistant to spoofing.

I'm sending another email on removal of the reverse DNS components.

If you have comments, reservations or suggestions, please post to the list before the end of next week (Dec 5). I'd like to ensure that I'm not in crazy-person-land before I start ripping things up.

Regards,
Martin

------------------------------------------------------------------------------------------------
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, 26 Nov 2008 00:25:50 -0600

This archive was generated by hypermail 2.1.8 : Wed Nov 26 2008 - 01:26:08 EST