Subject: PP7: Server Identity Check

From: Lisa Dusseault <[email-masked]>
Date: Fri, 18 Jan 2008 10:59:48 -0800

Begin forwarded message:

> From: =JeffH <[email-masked]>
>
> The overall topic is "Server Identity Check", as discussed/ 
> specified in http://ietf.org/rfc/rfc2830.txt...
>
> <RFC-snippet>
>
> 3.6.  Server Identity Check
>
>    The client MUST check its understanding of the server's hostname
>    against the server's identity as presented in the server's
>    Certificate message, in order to prevent man-in-the-middle attacks.
>
>    Matching is performed according to these rules:
>
>    - The client MUST use the server hostname it used to open the LDAP
>      connection as the value to compare against the server name as
>      expressed in the server's certificate.  The client MUST NOT  
> use the
>      server's canonical DNS name or any other derived form of name.
>
>    - If a subjectAltName extension of type dNSName is present in the
>      certificate, it SHOULD be used as the source of the server's
>      identity.
>
>    - Matching is case-insensitive.
>
>    - The "*" wildcard character is allowed.  If present, it applies  
> only
>      to the left-most name component.
>
>    E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
>    bar.com.  If more than one identity of a given type is present  
> in the
>    certificate (e.g. more than one dNSName name), a match in any  
> one of
>    the set is considered acceptable.
>
>    If the hostname does not match the dNSName-based identity in the
>    certificate per the above check, user-oriented clients SHOULD  
> either
>    notify the user (clients MAY give the user the opportunity to
>    continue with the connection in any case) or terminate the  
> connection
>    and indicate that the server's identity is suspect. Automated  
> clients
>    SHOULD close the connection, returning and/or logging an error
>    indicating that the server's identity is suspect.
>
>    Beyond the server identity checks described in this section,  
> clients
>    SHOULD be prepared to do further checking to ensure that the server
>    is authorized to provide the service it is observed to provide. The
>    client MAY need to make use of local policy information.
>
> </RFC-snippet>
>
> Which apparently is either being referenced in various RFCs/I-Ds,  
> or is being ignored in other various I-Ds/RFCs, who then re-invent  
> their own version, or don't at all.
>
> Thus it has been suggested (by ChrisN to me, at Vancouver last  
> month) to extract the above and make it into a BCP applicable to at  
> least the apps area.
>
> So also from RFC2830, are sections..
>
> <RFC-snippet>
>
> 3.5.  Assertion of Client's Authorization Identity
>
> 3.7.  Refresh of Server Capabilities Information
>
> 5.  Effects of TLS on a Client's Authorization Identity
>
> 5.1.  TLS Connection Establishment Effects
>
> </RFC-snippet>
>
> ..or any of the other RFC2830 (sub)sections relevant for inclusion  
> in this postulated BCP?
>
> As part of my submission, I'll bring an initial -00 rev I-D of said  
> BCP to the workshop and/or distribute it appropriately beforhand.
>
> thanks,
>
> =JeffH
>
>
>
>
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 18 Jan 2008 18:41:54 -0800

>> their own version, or don't at all.

RFC 2830 was obsoleted by RFC 4513.  While RFC 4313 (in Section 3.1.3)  
retains the basic server identity checks described in RFC 2830, it  
does expand on server identity checks a bit.  For instance, RFC 4513  
discussions not only checks based upon DNS names, but also discussions  
checks based upon IP addresses and other subjectName types.  The DNS  
name check specification also has been updated to discuss IDNA issues.

>> ..or any of the other RFC2830 (sub)sections relevant for inclusion  

I think Section 3.1.3 of RFC 4513 might serve as a better basis for  
postulating a generic "server identity check" BCP in this than Section  
3.6 of RFC 2830.

-- Kurt