IETF Logo Mail Archive

Re: [kitten] Verified authorization data

Peter Mogensen <apm@one.com> Thu, 12 June 2014 12:55 UTC

Return-Path: <apm@one.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 30C571B286B for <kitten@ietfa.amsl.com>; Thu, 12 Jun 2014 05:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 iJZOQk2mmLsa for <kitten@ietfa.amsl.com>; Thu, 12 Jun 2014 05:55:32 -0700 (PDT)
Received: from officesmtp2.one.com (officesmtp2.one.com [195.47.247.17]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0AE01A03ED for <kitten@ietf.org>; Thu, 12 Jun 2014 05:55:32 -0700 (PDT)
Received: from [192.168.4.228] (unknown [92.246.16.62]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by officesmtp2.one.com (Postfix) with ESMTPSA id 8A4C9801173A3; Thu, 12 Jun 2014 12:55:30 +0000 (UTC)
Message-ID: <5399A341.3070104@one.com>
Date: Thu, 12 Jun 2014 14:55:29 +0200
From: Peter Mogensen <apm@one.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Simo Sorce <simo@redhat.com>
References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> <539849AA.4000506@one.com> <1402503444.13617.1.camel@willson.usersys.redhat.com> <53988BB6.8010409@one.com> <1402506490.13617.9.camel@willson.usersys.redhat.com> <539952CC.8020703@one.com> <1402577232.22737.26.camel@willson.usersys.redhat.com>
In-Reply-To: <1402577232.22737.26.camel@willson.usersys.redhat.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/MnIbtCA7la0zGN8LemnXKc53PDk
Cc: "kitten@ietf.org" <kitten@ietf.org>, "krbdev@mit.edu" <krbdev@MIT.EDU>
Subject: Re: [kitten] Verified authorization data
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: Thu, 12 Jun 2014 12:55:35 -0000

On 2014-06-12 14:47, Simo Sorce wrote:
> On Thu, 2014-06-12 at 09:12 +0200, Peter Mogensen wrote:
>> Sure... any solution to the S4U2proxy use case would require protecting
>> the ticket and attached authdata, which the KDC has to trust against
>> service tampering.
>
> Sorry, no, the binding to the specific ticket is not a requirement for
> s4u2proxy. The only requirement there is the KDC MAC which could be done
> the same way as the SVC MAC.


Doesn't that depend on what any authdata plugin at the KDC might need to 
do with any authdata in the evidence ticket when processing the 
S4U2proxy TGS?
Such authdata in the evidence ticket could be something which the KDC 
would be in a position to verify in the principal database and issue a 
fresh copy.
But it could also be that the KDC had to trust the authdata in the 
evidence ticket at copy that information into the issued ticket.
In that case, you would need to protect against a service inserting 
authdata from another ticket into the evidence ticket.

/Peter

v2.30.2 | Report a Bug | By Email | System Status