PP7: Server Identity Check

Lisa Dusseault <lisa@osafoundation.org> Fri, 18 January 2008 18:59 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwRb-0001R3-AA; Fri, 18 Jan 2008 13:59:59 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFwRa-0001Qx-37 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 13:59:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwRZ-0001Qp-PF for discuss@apps.ietf.org; Fri, 18 Jan 2008 13:59:57 -0500
Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFwRY-0001fS-Gb for discuss@apps.ietf.org; Fri, 18 Jan 2008 13:59:57 -0500
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A464614227E for <discuss@apps.ietf.org>; Fri, 18 Jan 2008 10:59:58 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ5NrBUY7aHp for <discuss@apps.ietf.org>; Fri, 18 Jan 2008 10:59:51 -0800 (PST)
Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C20B8142201 for <discuss@apps.ietf.org>; Fri, 18 Jan 2008 10:59:51 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
To: Apps Discuss <discuss@apps.ietf.org>
Message-Id: <FF1DFC89-12CA-4FAB-8231-F70F9B521C89@osafoundation.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-3--962710845
References: <476AD1C2.6010600@neustar.biz>
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: PP7: Server Identity Check
Date: Fri, 18 Jan 2008 10:59:48 -0800
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org


Begin forwarded message:

> From: =JeffH <Jeff.Hodges@neustar.biz>
>
> 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
>
>
>
>
>