[kitten] Authentication indicator - Do we need client indicator ?
Simo Sorce <simo@redhat.com> Wed, 18 February 2015 15:56 UTC
Return-Path: <simo@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF731A89B0 for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 07:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRpHW6pNGNDG for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 07:56:56 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853751A89AF for <kitten@ietf.org>; Wed, 18 Feb 2015 07:56:56 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IFuuHC030980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <kitten@ietf.org>; Wed, 18 Feb 2015 10:56:56 -0500
Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IFutgG031026 for <kitten@ietf.org>; Wed, 18 Feb 2015 10:56:55 -0500
Message-ID: <1424275015.6980.23.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: kitten@ietf.org
Date: Wed, 18 Feb 2015 10:56:55 -0500
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/JiBUW-49kFO_cQZfSBzmCMvSCZs>
Subject: [kitten] Authentication indicator - Do we need client indicator ?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2015 15:56:58 -0000
Reading the draft I am wondering if we also need a "Client Indicator" Auth Data definition (in this draft or a separate draft). In AD-CAMMAC we mention that if the KDC want to make sure to bind the CAMMAC to a specific client principal, then this need to be done with data embedded into an AD within CAMMAC, but in AD-CAMMAC we specify no AD type to do that. I had not thought that we'd care about this binding in Auth Indicator work, but I see S4U2Proxy is mentioned there, so perhaps we actually do ? Would it be bad to define a new AD-CLIENT-INDICATOR data type as part of this RFC ? The AD would be defined as: AD-CLIENT-INDICATOR ::= SEQUENCE { principal [0] PrincipalName realm [1] Realm } The client indicator would be optional, but if it is included in a CAMMAC the KDC MUST verify that the client in the ticket including the CAMMAC matches the indicator. The AD Auth indicator security considerations would mention that if support for things like S4U2Proxy is desired and no other AD element in the CAMMAC ties the CAMMAC to a specific principal, then AD_CLIENT_INDICATOR SHOULD be used, and the KDC SHOULD deny a S4U2 operation (or perhaps simply omit the CAMMAC from the resulting ticket) if AD-CLIENT-INDICATOR is missing. Comments ? Simo. -- Simo Sorce * Red Hat, Inc * New York