[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