Subject: Re: [Geopriv] Proposal for LIS discovery (Auth)

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 9 Dec 2008 21:09:11 -0600

I've just done some digging on the fingerprint side of this approach.

This seems a reasonable approach:

<http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14#section-4.2.2>

I also has the advantage of having useful text that can be plagiarized. The bit-miser in me would like to find a more compact representation, but reusing the RFC 4572 hash names registry is a sound idea.

sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Thomson, Martin
> Sent: Wednesday, 26 November 2008 5:26 PM
> To: [email-masked]
> Subject: [Geopriv] Proposal for LIS discovery (Auth)
> 
> 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
> [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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2008 16:47:33 -0500

Martin,

Good find!  That should work well.

If you're feeling a bit more bit-miserly, you might consider one of the 
ASN.1 structures for this sort of thing in RFC 4210 (OOBCertHash seems 
appropriate).

--Richard