From nobody Mon Jun 2 15:33:42 2014 Return-Path: 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 6D2E51A03DB for ; Mon, 2 Jun 2014 15:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LgIp78s0oBzv for ; Mon, 2 Jun 2014 15:33:39 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E3F1A02BA for ; Mon, 2 Jun 2014 15:33:39 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s52MXWNu000429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Jun 2014 22:33:33 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s52MXVrH008435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Jun 2014 22:33:32 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s52MXVoE023703 for ; Mon, 2 Jun 2014 22:33:31 GMT Received: from shawn-emerys-computer.local (/10.159.175.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Jun 2014 15:33:30 -0700 Message-ID: <538CFBBA.1080900@oracle.com> Date: Mon, 02 Jun 2014 16:33:30 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/axbAXwcN27TlC9Y94xVPFz8wGUA Subject: [kitten] IETF 90 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 22:33:40 -0000 Please provide any agenda items for a possible Toronto session. Please submit these topics to the list or co-chairs no later than this Friday, June 6th 2014. Shawn. kitten co-chair -- From nobody Fri Jun 6 09:22:23 2014 Return-Path: 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 67FC61A00A2 for ; Fri, 6 Jun 2014 09:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2Kix9dz5O5uI for ; Fri, 6 Jun 2014 09:22:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728931A0095 for ; Fri, 6 Jun 2014 09:22:21 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s56GMDKj015195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Jun 2014 16:22:14 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s56GMCpG028273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jun 2014 16:22:13 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s56GMC9k029900 for ; Fri, 6 Jun 2014 16:22:12 GMT Received: from [10.159.74.196] (/10.159.74.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Jun 2014 09:22:11 -0700 Message-ID: <5391EACE.90600@oracle.com> Date: Fri, 06 Jun 2014 10:22:38 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11 MIME-Version: 1.0 To: kitten@ietf.org References: <538CFBBA.1080900@oracle.com> In-Reply-To: <538CFBBA.1080900@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1Bo-gzJtJK5YY4qjMz5Y9JOn_7I Subject: Re: [kitten] IETF 90 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 16:22:22 -0000 On 06/ 2/14 04:33 PM, Shawn M Emery wrote: > > Please provide any agenda items for a possible Toronto session. Please > submit these topics to the list or co-chairs no later than this > Friday, June 6th 2014. No one has submitted topics to discuss for Toronto's meeting, therefore there is no plan to meet for the upcoming conference unless we hear otherwise. Shawn. kitten co-chair -- From nobody Fri Jun 6 09:24:02 2014 Return-Path: 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 E8E601A0095 for ; Fri, 6 Jun 2014 09:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ebZ8CegtPgf8 for ; Fri, 6 Jun 2014 09:23:59 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662161A007D for ; Fri, 6 Jun 2014 09:23:59 -0700 (PDT) Received: from mail119-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE001.bigfish.com (10.236.130.64) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Jun 2014 16:23:52 +0000 Received: from mail119-co9 (localhost [127.0.0.1]) by mail119-co9-R.bigfish.com (Postfix) with ESMTP id 50481700480; Fri, 6 Jun 2014 16:23:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: 7 X-BigFish: VPS7(zzzz1f42h1d77h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch2297h1fc6h208chzzz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h27e2h1b1cn1b1bi) Received-SPF: pass (mail119-co9: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail119-co9 (localhost.localdomain [127.0.0.1]) by mail119-co9 (MessageSwitch) id 1402071830902825_28457; Fri, 6 Jun 2014 16:23:50 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.231]) by mail119-co9.bigfish.com (Postfix) with ESMTP id CE04C6A0074; Fri, 6 Jun 2014 16:23:50 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Jun 2014 16:23:50 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf06 (Postfix) with ESMTPS id 7802A3C0074; Fri, 6 Jun 2014 12:19:22 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 12:23:49 -0400 From: "Cantor, Scott" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] IETF 90 - Agenda Items Thread-Index: AQHPfrK2gU7wgLBNb0SVCcIWiRbqSJtkjLgA//+9C/A= Date: Fri, 6 Jun 2014 16:23:48 +0000 Message-ID: References: <538CFBBA.1080900@oracle.com> <5391EACE.90600@oracle.com> In-Reply-To: <5391EACE.90600@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.212.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/PK0tHX0AWx0Pe7y0y59QsmZvtAQ Subject: Re: [kitten] IETF 90 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 16:24:01 -0000 > No one has submitted topics to discuss for Toronto's meeting, therefore > there is no plan to meet for the upcoming conference unless we hear > otherwise. I doubt I'll have time to issue a new SAML-EC draft responding to the revie= w (thank you all), so I don't have anything to discuss on that. I will get = to it. -- Scott From nobody Fri Jun 6 17:32:17 2014 Return-Path: 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 2076B1A01FF for ; Fri, 6 Jun 2014 17:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 JyuqgTO8mC3L for ; Fri, 6 Jun 2014 17:32:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8199D1A01F1 for ; Fri, 6 Jun 2014 17:32:09 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s570W1T7004162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 7 Jun 2014 00:32:02 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s570W1KN020762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 7 Jun 2014 00:32:01 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s570W0pj016487 for ; Sat, 7 Jun 2014 00:32:01 GMT Received: from [10.159.74.196] (/10.159.74.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Jun 2014 17:32:00 -0700 Message-ID: <53925D92.7040209@oracle.com> Date: Fri, 06 Jun 2014 18:32:18 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11 MIME-Version: 1.0 To: kitten@ietf.org References: <538CFBBA.1080900@oracle.com> <5391EACE.90600@oracle.com> In-Reply-To: <5391EACE.90600@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sSZ1goPFIqfjefVHDYI62EI_dd8 Subject: Re: [kitten] IETF 90 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 00:32:14 -0000 On 06/ 6/14 10:22 AM, Shawn M Emery wrote: > On 06/ 2/14 04:33 PM, Shawn M Emery wrote: >> >> Please provide any agenda items for a possible Toronto session. >> Please submit these topics to the list or co-chairs no later than >> this Friday, June 6th 2014. > > No one has submitted topics to discuss for Toronto's meeting, > therefore there is no plan to meet for the upcoming conference unless > we hear otherwise. There has been a couple of requests made to me off-line for a slot on the agenda. Therefore we've requested a session for Toronto. Please let us know if there are any other topics to cover within a month. Shawn. -- From nobody Mon Jun 9 19:02:48 2014 Return-Path: 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 DC5601A0336 for ; Mon, 9 Jun 2014 19:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3liIrJFCeagD for ; Mon, 9 Jun 2014 19:02:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0ED91A032E for ; Mon, 9 Jun 2014 19:02:43 -0700 (PDT) Received: from CO1PR06CA038.namprd06.prod.outlook.com (10.242.160.28) by CO1PR06MB046.namprd06.prod.outlook.com (10.242.162.143) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 10 Jun 2014 02:02:41 +0000 Received: from BN1AFFO11FD031.protection.gbl (2a01:111:f400:7c10::152) by CO1PR06CA038.outlook.office365.com (2a01:111:e400:1014::28) with Microsoft SMTP Server (TLS) id 15.0.954.9 via Frontend Transport; Tue, 10 Jun 2014 02:02:40 +0000 Received: from mail.usda.gov (199.135.140.11) by BN1AFFO11FD031.mail.protection.outlook.com (10.58.52.185) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Tue, 10 Jun 2014 02:02:40 +0000 Received: from 001FSN2MPN1-044.001f.mgd2.msft.net ([169.254.4.134]) by 001FSN2MMR1-001.001f.mgd2.msft.net ([199.135.140.11]) with mapi id 14.03.0181.007; Tue, 10 Jun 2014 02:02:39 +0000 From: "Nordgren, Bryce L -FS" To: "kitten@ietf.org" Thread-Topic: Clarification on draft-williams-kitten-krb5-pkcross-02 Thread-Index: Ac+ETQ3RExzeDHp9RLadpfuazEFVzQ== Date: Tue, 10 Jun 2014 02:02:38 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30@001FSN2MPN1-044.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.63] Content-Type: multipart/alternative; boundary="_000_82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30001FSN2MPN1044001_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:199.135.140.11; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438001)(164054003)(199002)(189002)(86146001)(104016001)(76482001)(71186001)(4396001)(85852003)(19300405004)(15202345003)(6806004)(69596002)(16236675004)(97736001)(68736004)(19580395003)(66066001)(80022001)(79102001)(512954002)(77982001)(74662001)(20776003)(84676001)(64706001)(55846006)(99396002)(15843345004)(74502001)(84326002)(86362001)(31966008)(21056001)(92566001)(87936001)(92726001)(2656002)(50986999)(83322001)(81156002)(81342001)(33656002)(54356999)(19625215002)(46102001)(19580405001)(15975445006)(44976005)(74482001)(83072002)(81542001)(80862004)(79686001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR06MB046; H:mail.usda.gov; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0238AEEDB0 Received-SPF: Pass (: domain of fs.fed.us designates 199.135.140.11 as permitted sender) receiver=; client-ip=199.135.140.11; helo=mail.usda.gov; Authentication-Results: spf=pass (sender IP is 199.135.140.11) smtp.mailfrom=bnordgren@fs.fed.us; X-OriginatorOrg: fs.fed.us Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LVThZ5fREJaDJSzbXjgWh3076j4 Subject: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 02:02:47 -0000 --_000_82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30001FSN2MPN1044001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moving this here because it seemed more appropriate. On the kerberos@mit.edu list, Nico said: my idea is to use TGS anyways, but with a PKINIT pre-auth instead of PA-TGS= , and with a "cross-realm" certificate But in the draft I see that step 4 of the protocol is: Request a TGT from the destination realm using PKINIT [RFC4556]. The draft seems to be saying to me that Step 4 is to initiate an AS exchang= e with the destination realm using PKINIT. If I understand your comment cor= rectly, the crux of your idea is to have the client initiate a TGS exchange= with the destination realm using alternative padata. Can you clarify this = situation for me? :) Thanks, Bryce This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. --_000_82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30001FSN2MPN1044001_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Moving this here because it seemed more appropriate.=

 

On the kerberos@= mit.edu list, Nico said:

 

my idea is to use TGS anyways, but with a PKINIT = pre-auth instead of PA-TGS, and with a "cross-realm"

certificate

 

But in the draft I see that step 4 of the protocol i= s:

 

Request a TGT from the destination realm using PKINIT [RFC4556].=

 

The draft seems to be saying to me that Step 4 is to= initiate an AS exchange with the destination realm using PKINIT. If I unde= rstand your comment correctly, the crux of your idea is to have the client = initiate a TGS exchange with the destination realm using alternative padata. Can you clarify this situation for me? J

 

Thanks,

Bryce

 

 





This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you have received this message in er= ror, please notify the sender and delete the email immediately. --_000_82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30001FSN2MPN1044001_-- From nobody Mon Jun 9 19:45:43 2014 Return-Path: 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 5EA431A0358 for ; Mon, 9 Jun 2014 19:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 Rhm53CltZqrG for ; Mon, 9 Jun 2014 19:45:38 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E94D51A034F for ; Mon, 9 Jun 2014 19:45:37 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id B83A92F4060 for ; Mon, 9 Jun 2014 19:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VdKN7UngXk9Mt3J1uXMK f2G7fLc=; b=n6dqJ6ACdPcKGb51DjxTAhDFLOBRSxoAluFTscliiuIdlI5BPdjA wBr17G+RXZQlNBK3yj9DFjvbeRS9+GrT5+soHfGo0xqhhjF20gfzaAOMTG9w7WAY EZjHT4K8OZOr1EFXAAYx4igrbefBfRKmRiTuu+GjX3PXsOwXhSd7fMI= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 6C0302F4057 for ; Mon, 9 Jun 2014 19:45:37 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so766866wgg.32 for ; Mon, 09 Jun 2014 19:45:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.77.177 with SMTP id t17mr11680286wjw.55.1402368336072; Mon, 09 Jun 2014 19:45:36 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 9 Jun 2014 19:45:35 -0700 (PDT) In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30@001FSN2MPN1-044.001f.mgd2.msft.net> Date: Mon, 9 Jun 2014 21:45:35 -0500 Message-ID: From: Nico Williams To: "Nordgren, Bryce L -FS" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/9eM8sIdyY1Bz_GXQ_sD2EosKwYI Cc: "kitten@ietf.org" Subject: Re: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 02:45:39 -0000 On Mon, Jun 9, 2014 at 9:02 PM, Nordgren, Bryce L -FS wrote: > The draft seems to be saying to me that Step 4 is to initiate an AS exchange > with the destination realm using PKINIT. If I understand your comment > correctly, the crux of your idea is to have the client initiate a TGS > exchange with the destination realm using alternative padata. Can you > clarify this situation for me? J As I wrote the I-D you'd use an AS exchange, but I do believe a TGS would be better, if only because it'd be weird to have an AS-REP issue a non-INITIAL ticket or a ticket with non-empty transit path, or a ticket for client and service principals with different realms. But, really, aside from that, the choice of PA, and the outermost tag, (and any other nit-y things I might be forgetting) the two KDC exchanges are the same. The thing to expect is that the KDC recognizes the request as a PKCROSS request because it uses PKINIT pre-auth with a client cert from an issuer a) not corresponding to any of the KDC's realms, b) for which the KDC can work out a realm name [see below] or which has a Kerberos name SAN that the KDC can authorize the issuer to. The the KDC would figure out the client principal's realm name and the transit path, and write it all into a non-INITIAL ticket. For the transit path we already have "X.500 style" realm naming and transit path compression. For the client principal's realm name we could also use an X.500 style realm name if a DOMAIN style realm name cannot be figured out. This should be straightforward to implement, except for the part about X.500 style realm naming: I doubt any current Kerberos implementation has support for it, the transit path compression part in particular. Note that libraries too need X.500 style realm naming support for transit path validation -- I have not looked at what this takes, but it might be easy as long as you don't expect hierarchical transit path support for X.500. Mapping DNs to DOMAIN style names would be best whenever possible, but this requires having decent trust anchors. (I'm assuming that PKINIT implementations already check that only configured issuers are permitted to issue certs for the realm's client principals.) Finally, we should want an option for stuffing the entire cert (and cert chain) into an authz-data element of the issued ticket, possibly at the KDC's discretion, possibly at the client's request. Nico -- From nobody Mon Jun 9 20:41:51 2014 Return-Path: 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 763F81A0393 for ; Mon, 9 Jun 2014 20:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 CBJbDyed-dWp for ; Mon, 9 Jun 2014 20:41:48 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3141A036E for ; Mon, 9 Jun 2014 20:41:47 -0700 (PDT) X-AuditID: 1209190f-f79576d00000578b-85-53967e7afe6a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 58.6C.22411.A7E76935; Mon, 9 Jun 2014 23:41:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s5A3fjEv018519; Mon, 9 Jun 2014 23:41:45 -0400 Received: from [18.101.8.222] (vpn-18-101-8-222.mit.edu [18.101.8.222]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s5A3fgxp024113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2014 23:41:44 -0400 Message-ID: <53967E76.8050200@mit.edu> Date: Mon, 09 Jun 2014 23:41:42 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Nico Williams , "Nordgren, Bryce L -FS" References: <82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30@001FSN2MPN1-044.001f.mgd2.msft.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1q2qmxZs8O6snsXVNz9ZLY5uXsVi ceraETYHZo+Xp84xetx+c5bFY8mSn0wBzFFcNimpOZllqUX6dglcGTO2n2QtmMxZMW15N1MD 43r2LkYODgkBE4mTL0O7GDmBTDGJC/fWs3UxcnEICcxmknj3sJMRwtnAKNE69ywLhHOYSWL3 kj/sIC28AmoSO1t3gNksAqoSM/ecZwax2QSUJQ6e/cYCYosKhEl8PLqODaJeUOLkzCdgcRGB RInHC44zglzBLKAusXM3WKuwgI/Ex9unWSF2zWGUaP6/Emw+p0CgxLxTU5ggTpWU2LboGFic WUBH4l3fA2YIW15i+9s5zBMYhWYhWTcLSdksJGULGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW 6Zro5WaW6KWmlG5iBAe7JP8Oxm8HlQ4xCnAwKvHwTjg0NViINbGsuDL3EKMkB5OSKG9S2bRg Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK8rB+BynlTEiurUovyYVLSHCxK4rxvra2ChQTSE0tS s1NTC1KLYLIyHBxKErzstUBDBYtS01Mr0jJzShDSTBycIMN5gIYb1wDV8BYXJOYWZ6ZD5E8x KkqJ8wqANAuAJDJK8+B6YcnoFaM40CvCvBtA2nmAiQyu+xXQYCagwaIRIFcXlyQipKQaGEvD btY7xoaVbVu5aE6VTJTza7myg43bjYxD9CzWfN1+gGMC9+xniV/TI5xl9vYrxE6W4dt+J+/H csVF82uPLt2x5ZbFaY/UkzIXj6iENLKn7//Pd/PMBIVam968qjf2s+U9nqQ8/vjOdgLvgqnG Jg3tkse99S/bJ7M9S7iXZPbkU9TNHyFMxkosxRmJhlrMRcWJAEPzxF0hAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Z1u4bZ0vXf_ekIPi91lRRy74hnE Cc: "kitten@ietf.org" Subject: Re: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 03:41:49 -0000 On 06/09/2014 10:45 PM, Nico Williams wrote: > As I wrote the I-D you'd use an AS exchange, but I do believe a TGS > would be better, if only because it'd be weird to have an AS-REP issue > a non-INITIAL ticket or a ticket with non-empty transit path, or a > ticket for client and service principals with different realms. The TGS-REQ path is already too complicated. The KDC already has to deal with at least five cases: 1. Traditional TGS requests to get a service ticket using a TGT 2. Ticket modification requests (of TGTs or service tickets) 3. User-to-user authentication (session key from second ticket) 4. S4U2Self (issue ticket for client specified by padata) 5. S4U2Proxy (issue ticket for client specified by second ticket) Cases 4 and 5 aren't the IETF's doing, of course, but that doesn't mean we can reasonably avoid supporting them. I'd probably rather add a third type of KDC request than add a sixth variant of TGS which uses the AS-REQ preauth machinery and doesn't use a header ticket. (An AS-REQ variant might still be a reasonable option; I haven't reviewed the draft in enough detail to have a strong opinion about that.) From nobody Mon Jun 9 21:03:54 2014 Return-Path: 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 939061A0398 for ; Mon, 9 Jun 2014 21:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 IhBdBVAiwagF for ; Mon, 9 Jun 2014 21:03:51 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAA1A0396 for ; Mon, 9 Jun 2014 21:03:51 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id AFB5231805D for ; Mon, 9 Jun 2014 21:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4uRjefeH8oH5FgzDPDHQ hjo1K/8=; b=rUiQXHntrF5Xr1z22h58qijPZkzr6lFx+LvUXH0T742g/X+Airfc DPuCrQP/4oYKnghWb1QrElTQmSs/LyjdyKyNyKBrP/PydcQAzN92e8j4SONBjzj8 e5DQxD/QW+dyBeV+TkWkHkKgExQZr8SDxBmnPWYbQgItpjcX51GrLGE= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 621BC318059 for ; Mon, 9 Jun 2014 21:03:51 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so5331297wiw.16 for ; Mon, 09 Jun 2014 21:03:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.195.11.132 with SMTP id ei4mr263479wjd.95.1402373030223; Mon, 09 Jun 2014 21:03:50 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 9 Jun 2014 21:03:50 -0700 (PDT) In-Reply-To: <53967E76.8050200@mit.edu> References: <82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30@001FSN2MPN1-044.001f.mgd2.msft.net> <53967E76.8050200@mit.edu> Date: Mon, 9 Jun 2014 23:03:50 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Hu53ccU5srNMyIGIh2fFIE7baHk Cc: "kitten@ietf.org" Subject: Re: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 04:03:52 -0000 On Mon, Jun 9, 2014 at 10:41 PM, Greg Hudson wrote: > On 06/09/2014 10:45 PM, Nico Williams wrote: >> As I wrote the I-D you'd use an AS exchange, but I do believe a TGS >> would be better, if only because it'd be weird to have an AS-REP issue >> a non-INITIAL ticket or a ticket with non-empty transit path, or a >> ticket for client and service principals with different realms. > > The TGS-REQ path is already too complicated. The KDC already has to > deal with at least five cases: > ... > > Cases 4 and 5 aren't the IETF's doing, of course, but that doesn't mean > we can reasonably avoid supporting them. I'd probably rather add a > third type of KDC request than add a sixth variant of TGS which uses the > AS-REQ preauth machinery and doesn't use a header ticket. (An AS-REQ > variant might still be a reasonable option; I haven't reviewed the draft > in enough detail to have a strong opinion about that.) I find adding a new request type that will differ mostly only as to the application tag and pre-auth choice a bit silly. There's a cost to it too: dissectors for things like Wireshark and Netmon won't know about the new requests, even though the new request will be so like the old. The main reason to separate these at all is for separation of services, which for Kerberos is really mostly about class of service / load balancing -- give higher priority to TGS requests than to PKINIT. TGS requests are usually fast: it's all symmetric key crypto, while PKINIT AS requests are slower due to the PK crypto. At a high-level we have: - has PA-TGS -> TGS - has x-realm PKINIT -> new thing - anything else -> AS Separation of service should have been done by using [optionally] different port numbers, not different tag numbers. Thinking of it this way this, I'd rather use AS for this and not a new request type, due a) to the fact that we already have slow AS requests, but not slow TGS requests, b) AS req Nico -- From nobody Mon Jun 9 21:07:02 2014 Return-Path: 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 C6A691A0398 for ; Mon, 9 Jun 2014 21:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 pVNWwbh_HtGN for ; Mon, 9 Jun 2014 21:06:58 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 39FCD1A0396 for ; Mon, 9 Jun 2014 21:06:58 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id DBC2F2F4060 for ; Mon, 9 Jun 2014 21:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Go69vfln4gGz6ChmM8ly mhLzkiI=; b=LrQvR7L0Y86SswihKLh+fqvMz0a/jqg2J6O8bcs9gizf1jlrpGvA amJjH51GS/NVwpmN2GpABq8ZuDaRWaR0TviWNA0m3zMyKMSwdi6ExSo5tqeqx73X VlEfq/kXeUegT6bHs4jysV2LpjPKHLcSuKMIDwp9Dz/gXFNkdpzdNhI= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 8EA622F4059 for ; Mon, 9 Jun 2014 21:06:57 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so5324872wiw.14 for ; Mon, 09 Jun 2014 21:06:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr8423813wiw.5.1402373216297; Mon, 09 Jun 2014 21:06:56 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 9 Jun 2014 21:06:56 -0700 (PDT) In-Reply-To: References: <82E7C9A01FD0764CACDD35D10F5DFB6E6D4B30@001FSN2MPN1-044.001f.mgd2.msft.net> <53967E76.8050200@mit.edu> Date: Mon, 9 Jun 2014 23:06:56 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CQZUwL9KdQI6-FcXk7JTVZxeZJw Cc: "kitten@ietf.org" Subject: Re: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 04:06:59 -0000 Sent too soon. To complete that sentence: Thinking of it this way this, I'd rather use AS for this and not a new request type, due a) to the fact that we already have slow AS requests, but not slow TGS requests, b) AS requests are generally less frequent than TGS requests, c) I'd rather not have to update dissectors for Wireshark, snoop, tcpdump, Netmon, and so on. [Ab]Using AS for this means we can more easily separate class of service. We should still have different SRV RRset labels for each service (AS, TGS, PKCROSS). Nico -- From nobody Tue Jun 10 05:20:39 2014 Return-Path: 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 9EBBA1A0032 for ; Tue, 10 Jun 2014 05:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 yMeOcGmHg_aj for ; Tue, 10 Jun 2014 05:20:30 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6B81A0515 for ; Tue, 10 Jun 2014 05:20:15 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 10 Jun 2014 05:15:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,1008,1392192000"; d="scan'208,217";a="545676219" Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36]) by fmsmga001.fm.intel.com with ESMTP; 10 Jun 2014 05:19:49 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Jun 2014 05:19:44 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Jun 2014 05:19:43 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.34]) by shsmsx102.ccr.corp.intel.com ([169.254.2.190]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 20:19:20 +0800 From: "Zheng, Kai" To: "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQ== Date: Tue, 10 Jun 2014 12:19:19 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/alternative; boundary="_000_8D5F7E3237B3ED47B84CF187BB17B666118D870FSHSMSX103ccrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/JHqdFt8qZpnK-3hSXk2gzVhsb1k Subject: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 12:20:34 -0000 --_000_8D5F7E3237B3ED47B84CF187BB17B666118D870FSHSMSX103ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to mention an effort regarding Kerberos and propose a new Kerb= eros preauth mechanism, token-preauth. Before dive into that, please kindly= allow me to introduce, mainly for the background and scenario for the prop= osal. I'm an engineer from Intel and develop identity and security related produc= ts. The current focus is Apache Hadoop, and our goal is enabling Hadoop to = support more authentication mechanisms and providers. Currently Hadoop only= supports Kerberos authentication method as the built-in secured one and it= 's not easy to add more since it involves changing into many projects on to= p of it in the large ecosystem. The community had proposed a token based au= thentication, planned to add TokenAuth method for Hadoop and by TokenAuth t= hen all kinds of authentication providers can be supported since their auth= entication results can be wrapped into token, and the token can be employed= to authenticate to Hadoop across the ecosystem. The effort is still underg= oing. Considering the complexity, risk and deployment overhead of this appr= oach, our team investigate and think of another possible solution, i.e. sup= port token in Kerberos. The basic idea is allow end users to authenticate t= o Kerberos with their tokens and obtain tickets, then access Hadoop service= s using the tickets as current flow goes. The PoC was already done, and we = make it work seamlessly from MIT Kerberos to Java world and Hadoop. However= we think it's very important to get the key point token-preauth be reviewe= d by you security and Kerberos experts, to make sure it's defined and imple= mented in compliance with the existing standards and protocols, without inv= olving security critical leaks. So please kindly give your feedback and we = appreciate it. The proposal - Kerberos token-preauth This proposes to add another preauthentication mechanism similar to OTP and= PKINIT for Kerberos, based on Kerberos preauthentication framework and FAS= T tunnel. It allows 3rd party token in JWT format like OAuth bearer token c= an be used as credential to authenticate to KDC for a normal principal inst= ead of user password. When using the token to request a tgt, the user name = or other attributes claimed in the token must match the target Kerberos pri= ncipal. PKI is used to establish the trust relationship between 3rd party t= oken issuer and KDC. According to configured certificate and public/private= keys KDC decrypt and verify the token, and determines to issue ticket or n= ot according to configured policy. The token itself will be wrapped into ti= cket as new authorization data and carried on to application server side. T= he tgt and derived service ticket resulted from token are not in much diffe= rence except the contained token and work exactly as normally. Besides that= in application servers, token can be extracted from service ticket and emp= loyed further to do fine-grained authorization since the token can contain = rich identity attributes. POC implementation 1. We implement a token-preauth plugin for MIT Kerberos like OTP one = and it does all the necessary work that should be done for Kerberos itself = in both client side and KDC side. We need update krb5.conf and kdc.conf to = use and enable the mechanism. The plugin is a so module and can be separate= ly installed/deployed. To protect token between client and KDC in KDC-REQ/K= DC-REP exchanges, FAST must be used, therefore we suggest PKINIT be deploye= d also. 2. For end users, we provide ktinit tool as follows: ktinit -h This tool uses token to authenticate to KDC and obtains tgt for you. ktinit [-t token | -T token-cache-file] [-c kerb-ccache-file] when no token specified, ~/.tokenauth.token will be used by default In the behind, it requests the needed armor ticket using PKINIT anonymous a= nd then executes kinit with the armor ticket and token with -X option, gets= tgt and puts the tgt in specified credential cache 3. For JAVA application servers (Apache Hadoop services), we figured = out how to extract token from service tickets from both GSSAPI layer and SA= SL layer. It's planned to have a draft for this work. Our team is making effort to en= able Kerberos to be easily deployed in large Hadoop clusters and big data p= latform and can integrate with other authn & authz solutions well from ente= rprise and internet. Thanks for your input, feedback and correction. Regards, Kai --_000_8D5F7E3237B3ED47B84CF187BB17B666118D870FSHSMSX103ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I would like to mention an effo= rt regarding Kerberos and propose a new Kerberos preauth mechanism, token-p= reauth. Before dive into that, please kindly allow me to introduce, mainly = for the background and scenario for the proposal.

 

I’m an engineer from Inte= l and develop identity and security related products. The current focus is = Apache Hadoop, and our goal is enabling Hadoop to support more authenticati= on mechanisms and providers. Currently Hadoop only supports Kerberos authentication method as the built-in secured one a= nd it’s not easy to add more since it involves changing into many pro= jects on top of it in the large ecosystem. The community had proposed a tok= en based authentication, planned to add TokenAuth method for Hadoop and by TokenAuth then all kinds of authenticat= ion providers can be supported since their authentication results can be wr= apped into token, and the token can be employed to authenticate to Hadoop a= cross the ecosystem. The effort is still undergoing. Considering the complexity, risk and deployment overh= ead of this approach, our team investigate and think of another possible so= lution, i.e. support token in Kerberos. The basic idea is allow end users t= o authenticate to Kerberos with their tokens and obtain tickets, then access Hadoop services using the tic= kets as current flow goes. The PoC was already done, and we make it work se= amlessly from MIT Kerberos to Java world and Hadoop. However we think it= 217;s very important to get the key point token-preauth be reviewed by you security and Kerberos experts, to make su= re it’s defined and implemented in compliance with the existing stand= ards and protocols, without involving security critical leaks. So please ki= ndly give your feedback and we appreciate it.

 

 

The proposal – Kerberos t= oken-preauth

 

This proposes to add another pr= eauthentication mechanism similar to OTP and PKINIT for Kerberos, based on = Kerberos preauthentication framework and FAST tunnel. It allows 3rd party token in JWT format like OAuth bearer token can be used as credential to authenticate to KDC for a normal= principal instead of user password. When using the token to request a tgt,= the user name or other attributes claimed in the token must match the targ= et Kerberos principal. PKI is used to establish the trust relationship between 3rd party token issuer and KDC= . According to configured certificate and public/private keys KDC decrypt a= nd verify the token, and determines to issue ticket or not according to con= figured policy. The token itself will be wrapped into ticket as new authorization data and carried on to ap= plication server side. The tgt and derived service ticket resulted from tok= en are not in much difference except the contained token and work exactly a= s normally. Besides that in application servers, token can be extracted from service ticket and employed further t= o do fine-grained authorization since the token can contain rich identity a= ttributes.

 

 

POC implementation

 

1= .   &= nbsp;   We implement a token-pr= eauth plugin for MIT Kerberos like OTP one and it does all the necessary wo= rk that should be done for Kerberos itself in both client side and KDC side= . We need update krb5.conf and kdc.conf to use and enable the mechanism. The plugin is a so module and can be sepa= rately installed/deployed. To protect token between client and KDC in KDC-R= EQ/KDC-REP exchanges, FAST must be used, therefore we suggest PKINIT be dep= loyed also.

2= .   &= nbsp;   For end users, we provi= de ktinit tool as follows:

kt= init -h

Th= is tool uses token to authenticate to KDC and obtains tgt for you.

kt= init [-t token | -T token-cache-file] [-c kerb-ccache-file]

&n= bsp;     when no token specified, ~/.tokenauth.token wi= ll be used by default

 

In= the behind, it requests the needed armor ticket using PKINIT anonymous and= then executes kinit with the armor ticket and token with –X option, = gets tgt and puts the tgt in specified credential cache

3= .   &= nbsp;   For JAVA application se= rvers (Apache Hadoop services), we figured out how to extract token from se= rvice tickets from both GSSAPI layer and SASL layer.

 

It’s planned to have a dr= aft for this work. Our team is making effort to enable Kerberos to be easil= y deployed in large Hadoop clusters and big data platform and can integrate= with other authn & authz solutions well from enterprise and internet. Thanks for your input, feedback and correction.

 

Regards,

Kai

 

--_000_8D5F7E3237B3ED47B84CF187BB17B666118D870FSHSMSX103ccrcor_-- From nobody Tue Jun 10 08:10:11 2014 Return-Path: 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 2DA021B27FF for ; Tue, 10 Jun 2014 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 FDKwpZgRsCSX for ; Tue, 10 Jun 2014 08:10:06 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F491B2802 for ; Tue, 10 Jun 2014 08:10:05 -0700 (PDT) X-AuditID: 12074423-f79916d000000c54-a2-53971fcce8d7 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 07.F6.03156.CCF17935; Tue, 10 Jun 2014 11:10:04 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s5AFA32l001809; Tue, 10 Jun 2014 11:10:04 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (oc11exedge3.exchange.mit.edu [18.9.3.21]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id s5AFA22e014699; Tue, 10 Jun 2014 11:10:03 -0400 Received: from OC11EXHUB9.exchange.mit.edu (18.9.3.23) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 11:09:53 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.212]) by OC11EXHUB9.exchange.mit.edu ([18.9.3.23]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 11:10:01 -0400 From: Thomas Hardjono To: "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQLHZRBA Date: Tue, 10 Jun 2014 15:10:00 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A71539056@OC11EXPO24.exchange.mit.edu> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [18.111.19.235] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001E_01CF849C.84C8CAF0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjk+LIzCtJLcpLzFFi42IR4hRV1j0jPz3YYGqfhsXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcep8E2vBt7SKB3dvsDUwfo3tYuTkkBAwkVi8bwozhC0mceHe ejYQW0hgNpNE92u+LkYuIPsAo8SahoVMEM5xRomW7R8YIZxtjBKPZj9mgXBWMUp8+t/EDtLP JqAhce73XjBbRMBL4s+F3WC2sIC6xN9/nVBxDYlfKw9D2UYSmxa+ZgSxWQRUJbqXX2YCsXkF giRebZjCAnFTsMS15vlgt3IKhEjM+ziFFcRmBLr7+6k1YPXMAuISt57MZ4L4R0Ti4cXTbDC/ /dv1EMpWlGhsn8YMcjSzQC+jxPYji6CWCUqcnPmEZQKj+Cwks2Yhq5uFpA6iyEDi/qEOVghb W2LZwtfMELa1xIxfB9kgbEWJKd0P2SFsU4nXRz8yLmDkWMUom5JbpZubmJlTnJqsW5ycmJeX WqRrppebWaKXmlK6iREUvewuyjsY/xxUOsQowMGoxMN7QGJ6sBBrYllxZe4hRkkOJiVR3s9S QCG+pPyUyozE4oz4otKc1OJDjCpAux5tWH2BUYolLz8vVUmEt+3vtGAh3pTEyqrUonyYMmkO FiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJXh85oAWCRanpqRVpmTklCGkmDs5DjBIcPEDD DUBqeIsLEnOLM9Mh8qcYdTluNZxpYxICu0BKnDdBFqhIAKQoozQPbg4sGb9iFAd6UZg3FmQU DzCRw016BbSECWiJaMRUkCUliQgpqQZGEyF2a1XbnewTM92nZZupB/J/fDVL9fWpLpnIz3vY PgVIs69iNJVwLClWeP+0Qbw6Y73lCvNdn+ZPyA8W+xQkpbZs1cngjLLPXnt0zk4WkZ/d11wb mmjPsCNlSf1ll7XvgpyFCk6yhJZpH/8l4yJu09Ibkudy+4qeVai8/vOZy6zCLdYpVymxFGck GmoxFxUnAgDIubwBoQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dTW17KGmVeFRWl3qFNqdfAziRII Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:10:09 -0000 ------=_NextPart_000_001E_01CF849C.84C8CAF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kai, I think a token-preauth mechanism would be a very useful addition to the set of mechanisms that we have today. =20 When do you plan to submit the draft to the KITTEN WG? Best. /thomas/ ____________________________________________ From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Zheng, Kai Sent: Tuesday, June 10, 2014 8:19 AM To: kitten@ietf.org; krbdev@mit.edu Subject: [kitten] Token Preauth for Kerberos Hi all, I would like to mention an effort regarding Kerberos and propose a new Kerberos preauth mechanism, token-preauth. Before dive into that, please kindly allow me to introduce, mainly for the background and scenario for the proposal. I=92m an engineer from Intel and develop identity and security related products. The current focus is Apache Hadoop, and our goal is enabling Hadoop to support more authentication mechanisms and providers. Currently Hadoop only supports Kerberos authentication method as the built-in secured one and it=92s not easy to add more since it involves changing into many projects on top of it in the large ecosystem. The community had proposed a token based authentication, planned to add TokenAuth method for Hadoop and by TokenAuth then all kinds of authentication providers can be supported since their authentication results can be wrapped into token, and the token can be employed to authenticate to Hadoop across the ecosystem. The effort is still undergoing. Considering the complexity, risk and deployment overhead of this approach, our team investigate and think of another possible solution, i.e. support token in Kerberos. The basic idea is allow end users to authenticate to Kerberos with their tokens and obtain tickets, then access Hadoop services using the tickets as current flow goes. The PoC was already done, and we make it work seamlessly from MIT Kerberos to Java world and Hadoop. However we think it=92s very important to get the key point token-preauth be reviewed by you security and Kerberos experts, to make sure it=92s defined and implemented in compliance with the existing standards and protocols, without involving security critical leaks. So please kindly give your feedback and we appreciate it. The proposal =96 Kerberos token-preauth This proposes to add another preauthentication mechanism similar to OTP and PKINIT for Kerberos, based on Kerberos preauthentication framework and FAST tunnel. It allows 3rd party token in JWT format like OAuth bearer token can be used as credential to authenticate to KDC for a normal principal instead of user password. When using the token to request a tgt, the user name or other attributes claimed in the token must match the target Kerberos principal. PKI is used to establish the trust relationship between 3rd party token issuer and KDC. According to configured certificate and public/private keys KDC decrypt and verify the token, and determines to issue ticket or not according to configured policy. The token itself will be wrapped into ticket as new authorization data and carried on to application server side. The tgt and derived service ticket resulted from token are not in much difference except the contained token and work exactly as normally. Besides that in application servers, token can be extracted from service ticket and employed further to do fine-grained authorization since the token can contain rich identity attributes. POC implementation 1.=A0=A0=A0=A0=A0=A0 We implement a token-preauth plugin for MIT Kerberos like OTP one and it does all the necessary work that should be done for Kerberos itself in both client side and KDC side. We need update krb5.conf and kdc.conf to use and enable the mechanism. The plugin is a so module and can be separately installed/deployed. To protect token between client and KDC in KDC-REQ/KDC-REP exchanges, FAST must be used, therefore we suggest PKINIT be deployed also. 2.=A0=A0=A0=A0=A0=A0 For end users, we provide ktinit tool as follows: ktinit -h This tool uses token to authenticate to KDC and obtains tgt for you. ktinit [-t token | -T token-cache-file] [-c kerb-ccache-file] =A0=A0=A0=A0=A0 when no token specified, ~/.tokenauth.token will be used by default In the behind, it requests the needed armor ticket using PKINIT anonymous and then executes kinit with the armor ticket and token with =96X option, gets tgt and puts the tgt in specified credential cache 3.=A0=A0=A0=A0=A0=A0 For JAVA application servers (Apache Hadoop services), we figured out how to extract token from service tickets from both GSSAPI layer and SASL layer. It=92s planned to have a draft for this work. Our team is making effort to enable Kerberos to be easily deployed in large Hadoop clusters and big data platform and can integrate with other authn & authz solutions well from enterprise and internet. Thanks for your input, feedback and correction. Regards, Kai ------=_NextPart_000_001E_01CF849C.84C8CAF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRYzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG+zCCBeOgAwIBAgIQZinWIcJoBXWy amTeGLwOXDANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTQwMzEzMDAwMDAwWhcNMTUwMzE0MjM1OTU5WjCBwjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM5NDcyMDUzMDM3NzEfMB0GCSqGSIb3 DQEJARYQaGFyZGpvbm9AbWl0LmVkdTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHTAbBgNVBAoM FFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAldwe JSLJ1cE66HSP0U5B226vuOF+DaQknIDJ/NkcRY32lYORq41PkQZ8i6sA5OuNJsNFmsh8+2/Y27jt txJ6D0k0mao5UMWB/EP1yxcTz0d13F4ZM2k5MniihLjrKMNnJWhdgrnu2gaCWN6qsBYZdqQLmfTI juGi0nqDQxNhzCM2RWw84CM6Mjp3FepY/ElvZ6qs1ErqPHBHAH0u5B9G07R1NNYj3Zthlwr+tefl Wnz0vgTQOrehCXoY3OhverIY6LsfX8k70jj8BO1s496grGga9IaEBEG+xeX/MRln5dJwGJidhgm3 u1OF0AHvLdmLuM/13UBJzljauuJ67j6R3QIDAQABo4IDBTCCAwEwDAYDVR0TAQH/BAIwADAOBgNV HQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQf qxJcVHYXcktkA9hu2yxr2cel7jAbBgNVHREEFDASgRBoYXJkam9ub0BtaXQuZWR1MB8GA1UdIwQY MBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUF BzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMl MjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIw T1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1h bnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0 aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQ oE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVm MDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8v d3d3LnN5bWF1dGguY29tL3JwYTArBgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85v FgUxMDkyMjA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhW MGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBU+20ff1cQSUmPgcdmRkvjK2xNG9Pq3ZCcxz/t jsZ/MY0x5NyVgg/Ko0tCoFkCSPB2uUiNGoqJDsXeaGwJ2s4kcynVo84uHK1bi2ZfUgK7eLT5ib4F IQ4cwxqG12sA8J1N0p8nLbkC8zm7eI0rrumZcrla+M4oyJNp8wpUFlds4EsOAxpxgR5sGxG2FIWq I75dE2PQdRNAzi35J00ZXYb5csaw5Upv0acZ/WzMrw5JVJXDufU1h4bi8TcRhuqJ1hkBrhjL1Ajr cnAX1QH7ta9AuUGWR76VpxN1vQ4Fn70IguzJF54kddeSv88lce9MhxX9rLE/oHFf6YrdoZ9qQCnZ MYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEc0AhBmKdYhwmgFdbJqZN4YvA5cMAkGBSsOAwIaBQCgggKrMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYxMDE1MDk1OVowIwYJKoZIhvcNAQkE MRYEFPn/ZhSZYo6HSzH7tdgXgoY4b5p3MIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQC AzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBmKdYhwmgFdbJq ZN4YvA5cMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEGYp1iHCaAV1smpk3hi8DlwwDQYJKoZIhvcNAQEB BQAEggEALK/HlTFuD8gtaN96OTGGv312igGPJVy9xN+ZIM1GFpyXLVBhdkBD8E2IakzBgEuDYJ5I lDgZjDOmDvuVRIIYhx/cXaMPtCc6tbhKT7MvrpOrVsPOS+sNWoPfqezTNaBKuyKJ15DdsMcclnRl 6M4KphLj6G+SNEitA1ymtnEM+thtqzyrjHXidcvTLSAazhoBMzezDjQVZr31Quy5bzxgqJUZVQjG QJcksVAvaabjr9OLDDBiP2wGD3Gl5FbIF/Ki6WIaryk67mz6ASkXShLKOT0CnWyCQ9VkGYQUNUwn YEXM3IlbP0qDfzA594xK/mPBPCtI7SwbXvhDR7fByGHNSAAAAAAAAA== ------=_NextPart_000_001E_01CF849C.84C8CAF0-- From nobody Tue Jun 10 09:30:20 2014 Return-Path: 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 5229B1A01FB for ; Tue, 10 Jun 2014 09:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6oRsJ9d_ZzOU for ; Tue, 10 Jun 2014 09:30:16 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553311A019B for ; Tue, 10 Jun 2014 09:30:16 -0700 (PDT) X-AuditID: 1209190e-f79946d000000c39-d1-5397329625a1 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B6.A9.03129.69237935; Tue, 10 Jun 2014 12:30:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s5AGUDcc023535; Tue, 10 Jun 2014 12:30:14 -0400 Received: from [18.101.8.248] (vpn-18-101-8-248.mit.edu [18.101.8.248]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s5AGUAnk023711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Jun 2014 12:30:13 -0400 Message-ID: <5397328E.6020005@mit.edu> Date: Tue, 10 Jun 2014 12:30:06 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Zheng, Kai" , "kitten@ietf.org" , "krbdev@mit.edu" References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nojvNaHqwwbc1lhbrW0+zWBzdvIrF gcljyZKfTB6L97xkCmCK4rJJSc3JLEst0rdL4Mpouv2FsWCtVMW88wuZGxgXiXYxcnJICJhI LHt3nBHCFpO4cG89WxcjF4eQwGwmiRPfLrBCOBsZJd4+X8IC4Rxhklh19zZYC6+AmsSGc7vZ QWwWAVWJuTv2MoPYbALKEgfPfmMBsUUFwiQ+Hl3HBlEvKHFy5hOgOAeHiEC5xIurGiBhYQED ie57N8FKhASCJa41zwcbwykQIjHv4xRWiOskJbYtOga2illAR+Jd3wNmCFteYvvbOcwTGAVn IdkwC0nZLCRlCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6+VmluilppRuYgQFMKck3w7G rweVDjEKcDAq8fAekJgeLMSaWFZcmXuIUZKDSUmU94k8UIgvKT+lMiOxOCO+qDQntfgQowQH s5IIb9vfacFCvCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJ3omGQEMF i1LTUyvSMnNKENJMHJwgw3mAhluA1PAWFyTmFmemQ+RPMSpKifOygiQEQBIZpXlwvbAE84pR HOgVYd45IFU8wOQE1/0KaDAT0GDRiKkgg0sSEVJSDYxcM5ysppd5qXXINHJ0yR8udxMUlND9 5vk21inlxo74JRlyW9SL515cqp+2p0eOz1OEW0/Y+ceCi7/VQ994Shw8eePjF5Ho3M7TqyJ4 o4+/b4ltYVB1r72z5Jm5n1JE7eqNd189EHTd7vlqymPGrByN20vPhbm+lPj19+L5uftWvPXa 3nnPrk+JpTgj0VCLuag4EQAoCpauCwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/8LcnTe1nHBY-HNk40fVUpgUvY-4 Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:30:18 -0000 On 06/10/2014 08:19 AM, Zheng, Kai wrote: > This proposes to add another preauthentication mechanism similar to OTP > and PKINIT for Kerberos, based on Kerberos preauthentication framework > and FAST tunnel. It allows 3^rd party token in JWT format like OAuth > bearer token can be used as credential to authenticate to KDC for a > normal principal instead of user password. Without knowing more details, here are three areas where there might be concerns: 1. How is the reply key computed during an AS request? I am guessing that you took the OTP approach of using the FAST armor key as the reply key. This is not ideal, but may be the path of least resistance if you have to work with bearer tokens. The limitations of this approach are: * It precludes the preauth mechanism from working securely inside FAST channels which do not authenticate the KDC (such as anonymous PKINIT channels without KDC certificate verification). * It means any holder of the FAST armor key (e.g. someone who has the host keytab) can passively observe the exchange and decrypt the ticket, not just the holder of some user-specific authentication secret. If you use holder-of-key tokens instead of bearer tokens, the key can be used in one of several ways to more securely establish a reply key. The last time I talked about this with Sam Hartman in person, he suggested that perhaps mechanisms which can't securely establish a reply key should be doing an unauthenticated DH exchange within the FAST channel, which would prevent a passive observer with the armor key from decrypting the ticket. That would add a lot of complexity and have a performance impact, however. 2. Can a service impersonate the client to other services? If you're handing out client bearer tokens to each service the client authenticates to, and the bearer token can be used to obtain a TGT, then a service can use that bearer token to get its own TGT and authenticate as the user to other services. This problem goes away if the bearer tokens are restricted to particular services and the KDC doesn't issue TGTs. The client would make an AS request for a specific server (identified in the bearer token) and get a service ticket for that server directly, without making a TGS request. The service can then only impersonate a user to itself, which is harmless. 3. Is the authdata correctly packaged? In the Kerberos 5 authdata model, the KDC is assumed to blindly pass through authdata requested by the client. If the authdata is to be trusted by the target service as something vetted by the KDC, it needs to be packaged accordingly. The traditional method for doing this is a container called AD-KDC-ISSUED which contains a checksum for the authdata in a key which cannot be known (in advance) by the client. This container has not seen much practical use, and it turns out that RFC 4120 says conflicting things about which key to use for the checksum. To the extent that there are implementations, they use the ticket session key. A more recent container for this purpose is AD-CAMMAC, as specified in: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-01 In addition to not having key ambiguity issues, AD-CAMMAC also contains a KDC verifier which allows the authdata to be propagated through an S4U2Proxy request. From nobody Tue Jun 10 13:57:53 2014 Return-Path: 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 80D8A1A0439 for ; Tue, 10 Jun 2014 13:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7hlAA_jOD4-O for ; Tue, 10 Jun 2014 13:57:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557651A02F4 for ; Tue, 10 Jun 2014 13:57:34 -0700 (PDT) Received: from BY2PR06CA032.namprd06.prod.outlook.com (10.141.250.150) by BY2PR06MB043.namprd06.prod.outlook.com (10.242.44.143) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 10 Jun 2014 20:57:31 +0000 Received: from BN1AFFO11FD040.protection.gbl (2a01:111:f400:7c10::124) by BY2PR06CA032.outlook.office365.com (2a01:111:e400:2c60::22) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Tue, 10 Jun 2014 20:57:31 +0000 Received: from mail.usda.gov (199.135.140.17) by BN1AFFO11FD040.mail.protection.outlook.com (10.58.52.251) with Microsoft SMTP Server (TLS) id 15.0.959.15 via Frontend Transport; Tue, 10 Jun 2014 20:57:30 +0000 Received: from 001FSN2MMR1-011.001f.mgd2.msft.net (199.135.140.50) by 001FSN2MMR1-007.001f.mgd2.msft.net (199.135.140.17) with Microsoft SMTP Server (TLS) id 14.3.181.7; Tue, 10 Jun 2014 20:56:41 +0000 Received: from 001FSN2MPN1-044.001f.mgd2.msft.net ([169.254.4.134]) by 001FSN2MMR1-011.001f.mgd2.msft.net ([199.135.140.50]) with mapi id 14.03.0181.007; Tue, 10 Jun 2014 20:56:41 +0000 From: "Nordgren, Bryce L -FS" To: "Zheng, Kai" , "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQLSYH4w Date: Tue, 10 Jun 2014 20:56:41 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6D5EBE@001FSN2MPN1-044.001f.mgd2.msft.net> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:199.135.140.17; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438001)(199002)(189002)(2171001)(23726002)(46406003)(50986999)(69596002)(21056001)(50466002)(97736001)(33656002)(2656002)(87936001)(99396002)(68736004)(81156002)(86362001)(16796002)(6806004)(84676001)(74502001)(19580405001)(47776003)(4396001)(74662001)(79102001)(83322001)(44976005)(74482001)(55846006)(81542001)(81342001)(77982001)(46102001)(92726001)(54356999)(551544002)(2201001)(86146001)(92566001)(31966008)(97756001)(85852003)(80022001)(76176999)(76482001)(64706001)(83072002)(20776003)(66066001)(80862004); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR06MB043; H:mail.usda.gov; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0238AEEDB0 Received-SPF: Pass (: domain of fs.fed.us designates 199.135.140.17 as permitted sender) receiver=; client-ip=199.135.140.17; helo=mail.usda.gov; Authentication-Results: spf=pass (sender IP is 199.135.140.17) smtp.mailfrom=bnordgren@fs.fed.us; X-OriginatorOrg: fs.fed.us Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mP3CgngUli_KdIUP4EILPbrWoOs Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:57:36 -0000 >This proposes to add another preauthentication mechanism similar to >OTP and PKINIT for Kerberos, based on Kerberos preauthentication >framework and FAST tunnel. It allows 3rd party token in JWT format >like OAuth bearer token can be used as credential to authenticate to >KDC for a normal principal instead of user password. When using the >token to request a tgt, the user name or other attributes claimed in the >token must match the target Kerberos principal. PKI is used to establish >the trust relationship between 3rd party token issuer and KDC. Very cool. Might I ask how you map identities from the 3rd party scheme into the Kerbe= ros PRINCIPAL@REALM scheme? I assume from the above that the actual binding= is performed using a kx509 certificate issued by a trusted CA? Is there a = proposed algorithm to generate Kerberos identities from 3rd party ones, or = is this a function of the CA? Let me back up a bit. Is this being proposed as a gateway such that identit= ies from 3rd party identity systems have a standardized representation in K= erberos (thus ensuring that tokens and Kerberos identities are correctly as= sociated)? Or is this a means for manually created users in the local KDC t= o use their "regular" password? If the latter, how does one ensure that the= same person is in control of the Kerberos identity and the external one? Bryce PS: Is your MIT krb5 plugin code somewhere public? :) This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Tue Jun 10 23:47:14 2014 Return-Path: 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 146561A064A for ; Tue, 10 Jun 2014 23:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 aEBq2T_rB31b for ; Tue, 10 Jun 2014 23:47:11 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 95CFB1A063E for ; Tue, 10 Jun 2014 23:47:11 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 10 Jun 2014 23:47:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,456,1400050800"; d="scan'208";a="555563860" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by orsmga002.jf.intel.com with ESMTP; 10 Jun 2014 23:47:10 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Jun 2014 23:47:10 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Jun 2014 23:47:09 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.34]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.37]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 14:47:08 +0800 From: "Zheng, Kai" To: Thomas Hardjono , "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQLHZRBAACCL9CA= Date: Wed, 11 Jun 2014 06:47:07 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118D8CE2@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5E393DF26B791A428E5F003BB6C5342A71539056@OC11EXPO24.exchange.mit.edu> In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A71539056@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/F7ZoFzeciDkcbKzrNbSIVfAWBI0 Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 06:47:13 -0000 Hi Thomas, Thanks for your confirm and encouraging. I think the feedback and input fro= m the community for the idea are very important, so please kindly allow me to understand them and prepare well for the initi= al draft for your review. Thanks. Regards, Kai -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Thomas Hardjono Sent: Tuesday, June 10, 2014 11:10 PM To: kitten@ietf.org; krbdev@mit.edu Subject: Re: [kitten] Token Preauth for Kerberos Kai, I think a token-preauth mechanism would be a very useful addition to the se= t of mechanisms that we have today. =20 When do you plan to submit the draft to the KITTEN WG? Best. /thomas/ ____________________________________________ From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Zheng, Kai Sent: Tuesday, June 10, 2014 8:19 AM To: kitten@ietf.org; krbdev@mit.edu Subject: [kitten] Token Preauth for Kerberos Hi all, I would like to mention an effort regarding Kerberos and propose a new Kerb= eros preauth mechanism, token-preauth. Before dive into that, please kindly= allow me to introduce, mainly for the background and scenario for the prop= osal. I'm an engineer from Intel and develop identity and security related produc= ts. The current focus is Apache Hadoop, and our goal is enabling Hadoop to = support more authentication mechanisms and providers. Currently Hadoop only= supports Kerberos authentication method as the built-in secured one and it= 's not easy to add more since it involves changing into many projects on to= p of it in the large ecosystem. The community had proposed a token based au= thentication, planned to add TokenAuth method for Hadoop and by TokenAuth t= hen all kinds of authentication providers can be supported since their auth= entication results can be wrapped into token, and the token can be employed= to authenticate to Hadoop across the ecosystem. The effort is still underg= oing. Considering the complexity, risk and deployment overhead of this approach, = our team investigate and think of another possible solution, i.e. support token in Kerberos. The basic idea is allow end users to authenticat= e to Kerberos with their tokens and obtain tickets, then access Hadoop serv= ices using the tickets as current flow goes. The PoC was already done, and we make it work seamlessly from MIT Kerberos = to Java world and Hadoop. However we think it's very important to get the k= ey point token-preauth be reviewed by you security and Kerberos experts, to= make sure it's defined and implemented in compliance with the existing sta= ndards and protocols, without involving security critical leaks. So please = kindly give your feedback and we appreciate it. The proposal - Kerberos token-preauth This proposes to add another preauthentication mechanism similar to OTP and= PKINIT for Kerberos, based on Kerberos preauthentication framework and FAS= T tunnel. It allows 3rd party token in JWT format like OAuth bearer token c= an be used as credential to authenticate to KDC for a normal principal inst= ead of user password. When using the token to request a tgt, the user name = or other attributes claimed in the token must match the target Kerberos pri= ncipal. PKI is used to establish the trust relationship between 3rd party t= oken issuer and KDC. According to configured certificate and public/private= keys KDC decrypt and verify the token, and determines to issue ticket or n= ot according to configured policy. The token itself will be wrapped into ti= cket as new authorization data and carried on to application server side. T= he tgt and derived service ticket resulted from token are not in much diffe= rence except the contained token and work exactly as normally. Besides that= in application servers, token can be extracted from service ticket and emp= loyed further to do fine-grained authorization since the token can contain = rich identity attributes. POC implementation 1.=A0=A0=A0=A0=A0=A0 We implement a token-preauth plugin for MIT Kerberos l= ike OTP one and it does all the necessary work that should be done for Kerb= eros itself in both client side and KDC side. We need update krb5.conf and = kdc.conf to use and enable the mechanism. The plugin is a so module and can= be separately installed/deployed. To protect token between client and KDC = in KDC-REQ/KDC-REP exchanges, FAST must be used, therefore we suggest PKINI= T be deployed also. 2.=A0=A0=A0=A0=A0=A0 For end users, we provide ktinit tool as follows: ktinit -h This tool uses token to authenticate to KDC and obtains tgt for you. ktinit [-t token | -T token-cache-file] [-c kerb-ccache-file] =A0=A0=A0=A0=A0 when no token specified, ~/.tokenauth.token will be used by= default In the behind, it requests the needed armor ticket using PKINIT anonymous a= nd then executes kinit with the armor ticket and token with -X option, gets= tgt and puts the tgt in specified credential cache 3.=A0=A0=A0=A0=A0=A0 Fo= r JAVA application servers (Apache Hadoop services), we figured out how to = extract token from service tickets from both GSSAPI layer and SASL layer. It's planned to have a draft for this work. Our team is making effort to en= able Kerberos to be easily deployed in large Hadoop clusters and big data p= latform and can integrate with other authn & authz solutions well from ente= rprise and internet. Thanks for your input, feedback and correction. Regards, Kai From nobody Wed Jun 11 01:16:06 2014 Return-Path: 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 D5CEB1A04C5 for ; Wed, 11 Jun 2014 01:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 9PyPL2K-lc1n for ; Wed, 11 Jun 2014 01:15:42 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id DF2FA1A0426 for ; Wed, 11 Jun 2014 01:15:41 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 11 Jun 2014 01:10:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,456,1400050800"; d="scan'208";a="555598215" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by orsmga002.jf.intel.com with ESMTP; 11 Jun 2014 01:15:35 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Jun 2014 01:15:34 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.34]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.23]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 16:15:32 +0800 From: "Zheng, Kai" To: Greg Hudson , "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQK5hzIAAC7IIlA= Date: Wed, 11 Jun 2014 08:15:32 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118D8E14@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> In-Reply-To: <5397328E.6020005@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/yIB3ZomsbbCBu-x-JyFIHfmYMA8 Cc: "Jiang, Weihua" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 08:15:44 -0000 Hi Greg, Thanks for your valuable feedback and suggestions! 1. Yes you're right I'm taking the OTP approach and use the FAST armor key = as the reply key. As mentioned in the proposal we suggest PKINIT be deploye= d along with this mechanism, And client uses PKINIT anonymous to obtain the armor ticket. It doesn't pro= vide mutual authentication since only KDC is authenticated to client with t= he configured certificate of KDC and=20 client doesn't due to lacking of certificate as to avoid the deployment ove= rhead in our solution. So protecting the token here in AS-REQ exchange main= ly depends on the FAST tunnel and client should be careful about the armor ticket. I agree using Holder-of-Key token is much secure. Does that mean KDC needs = to authenticate client and user still needs to provide credential like pass= word right. Perhaps we could support=20 both since they're useful in different situations and requirements. 2. Can a service impersonate the client to other services? It depends. Some= times we want to avoid the impersonation as you mentioned for security conc= ern, sometimes it's desired like=20 we might consider to support similar flows as S4U2Self and S4U2Proxy. What = do you think about this? Could we do it in a restricted way like constraine= d delegation? At least if we have to=20 avoid the impersonation, sure we can consider your suggestion and don't get= tgt but get service ticket directly using token. A problem would be it's h= ard for now to make it work in JAVA=20 because using tgt requesting service ticket is buried in JRE and we can't h= ack into it. Getting tgt using token works well because we can put the cred= ential into cache then JRE picks it from the cache file to request service ticket without extra effort. Another way to avoid the im= personation would be we don't pass token to service. Since only token attri= butes are really needed for authorization stuff=20 so KDC could just emit the token attributes into service ticket and don't p= ut the token into it. But I'm not very sure if token itself is desired or n= ot in more general cases. 3. Yes we considered support packing the new authorization data type, thoug= h not in AD-KDC-ISSUED, AD-IF-RELEVANT instead. We would encrypt the data u= sing the server key probably as MS-PAC does. Sure we can use more secure way if it doesn't involve too much deploy= ment overhead for services. Please help clarify and correct, and again thanks for your great input. Regards, Kai -----Original Message----- From: Greg Hudson [mailto:ghudson@MIT.EDU]=20 Sent: Wednesday, June 11, 2014 12:30 AM To: Zheng, Kai; kitten@ietf.org; krbdev@mit.edu Subject: Re: [kitten] Token Preauth for Kerberos On 06/10/2014 08:19 AM, Zheng, Kai wrote: > This proposes to add another preauthentication mechanism similar to=20 > OTP and PKINIT for Kerberos, based on Kerberos preauthentication=20 > framework and FAST tunnel. It allows 3^rd party token in JWT format=20 > like OAuth bearer token can be used as credential to authenticate to=20 > KDC for a normal principal instead of user password. Without knowing more details, here are three areas where there might be concerns: 1. How is the reply key computed during an AS request? I am guessing that you took the OTP approach of using the FAST armor key as= the reply key. This is not ideal, but may be the path of least resistance= if you have to work with bearer tokens. The limitations of this approach = are: * It precludes the preauth mechanism from working securely inside FAST chan= nels which do not authenticate the KDC (such as anonymous PKINIT channels w= ithout KDC certificate verification). * It means any holder of the FAST armor key (e.g. someone who has the host = keytab) can passively observe the exchange and decrypt the ticket, not just= the holder of some user-specific authentication secret. If you use holder-of-key tokens instead of bearer tokens, the key can be us= ed in one of several ways to more securely establish a reply key. The last time I talked about this with Sam Hartman in person, he suggested = that perhaps mechanisms which can't securely establish a reply key should b= e doing an unauthenticated DH exchange within the FAST channel, which would= prevent a passive observer with the armor key from decrypting the ticket. = That would add a lot of complexity and have a performance impact, however. 2. Can a service impersonate the client to other services? If you're handing out client bearer tokens to each service the client authe= nticates to, and the bearer token can be used to obtain a TGT, then a servi= ce can use that bearer token to get its own TGT and authenticate as the use= r to other services. This problem goes away if the bearer tokens are restricted to particular se= rvices and the KDC doesn't issue TGTs. The client would make an AS request= for a specific server (identified in the bearer token) and get a service t= icket for that server directly, without making a TGS request. The service can then only impersonate a user to itself, which is harmless. 3. Is the authdata correctly packaged? In the Kerberos 5 authdata model, the KDC is assumed to blindly pass throug= h authdata requested by the client. If the authdata is to be trusted by th= e target service as something vetted by the KDC, it needs to be packaged ac= cordingly. The traditional method for doing this is a container called AD-KDC-ISSUED w= hich contains a checksum for the authdata in a key which cannot be known (i= n advance) by the client. This container has not seen much practical use, = and it turns out that RFC 4120 says conflicting things about which key to u= se for the checksum. To the extent that there are implementations, they us= e the ticket session key. A more recent container for this purpose is AD-CAMMAC, as specified in: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-01 In addition to not having key ambiguity issues, AD-CAMMAC also contains a K= DC verifier which allows the authdata to be propagated through an S4U2Proxy= request. From nobody Wed Jun 11 05:21:08 2014 Return-Path: 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 557AA1B2886 for ; Wed, 11 Jun 2014 05:21:05 -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 HIPyovVpweUL for ; Wed, 11 Jun 2014 05:21:02 -0700 (PDT) Received: from officesmtp1.one.com (officesmtp1.one.com [195.47.247.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6B11B286D for ; Wed, 11 Jun 2014 05:21:01 -0700 (PDT) Received: from [172.16.16.74] (unknown [46.30.211.29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by officesmtp1.one.com (Postfix) with ESMTPSA id BCEB8801173A2; Wed, 11 Jun 2014 12:20:59 +0000 (UTC) Message-ID: <539849AA.4000506@one.com> Date: Wed, 11 Jun 2014 14:20:58 +0200 From: Peter Mogensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Greg Hudson , "kitten@ietf.org" , "krbdev@mit.edu" References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> In-Reply-To: <5397328E.6020005@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/w9ST-bHo2RNq-mvLQgSLTb307cY Subject: [kitten] Verified authorization data X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:21:05 -0000 Hi, Greg Hudson summes up the situation fine here. I feel the urge to comment. (below) On 2014-06-10 18:30, Greg Hudson wrote: > In the Kerberos 5 authdata model, the KDC is assumed to blindly pass > through authdata requested by the client. If the authdata is to be > trusted by the target service as something vetted by the KDC, it needs > to be packaged accordingly. > > The traditional method for doing this is a container called > AD-KDC-ISSUED which contains a checksum for the authdata in a key which > cannot be known (in advance) by the client. This container has not seen > much practical use, and it turns out that RFC 4120 says conflicting > things about which key to use for the checksum. To the extent that > there are implementations, they use the ticket session key. > > A more recent container for this purpose is AD-CAMMAC, as specified in: > > http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-01 > > In addition to not having key ambiguity issues, AD-CAMMAC also contains > a KDC verifier which allows the authdata to be propagated through an > S4U2Proxy request. I did some work to implement RFC6806 AD-LOGIN-ALIAS which requires AD-KDC-ISSUED and noticed the ambiguity in RFC4120 regarding which key to use for the checksum. I also noticed that AD-CAMMAC explicitly uses the service-key (and not the ticket session key) to do the same. ... and that to embed a ~10 bytes username in a ticket as AD-LOGIN-ALIAS I end up increasing the ticket size with about 110 bytes. - which is a rather significant increase if you are worried about ticket sizes. So, I wonder... is this really the optimal way to extend a ticket with verified information? If I just wanted to verify the login-alias to the service it seems like a waste of ~100 bytes to checksum it with the service-key (like RFC4120 also states). If it wasn't for the authdata-model Greg describes above, where the DC is assumed to blindly pass through authdata requested by the client, then no checksum would have been needed. The ticket it self would protect the integrity of the field. (and saving ~100 bytes ticket size). It seems to me that a lot of complexity in verifying authdata originates from this authdata model where the client can put anything it likes in the authorization-data. This is of course useful for negative authorization, but makes things complicated for positive authorization data. (like simple info the KDC just want to assert to the service, like AD-LOGIN-ALIAS) The solution in AD-CAMMAC seems very complex too, requiring effectively calculating the entire EncTicketPart twice - and once for every present AD-CAMMAC present. Things would have been much simpler if there were an authdata field in a ticket outside of the clients control. Now, - I know - there's probably very good reasons why extending the EncTicketPart and Ticket definitions is difficult, but... In an ideal world, maybe something like: EncTicketPart ::= [APPLICATION 3] SEQUENCE { flags [0] TicketFlags, key [1] EncryptionKey, crealm [2] Realm, cname [3] PrincipalName, transited [4] TransitedEncoding, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, caddr [9] HostAddresses OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL protected-authdata [11] AuthorizationData OPTIONAL } Where the client can't add to "protected-authdata". This would make the AD-KDC-ISSUED and svc-verifier of AD-CAMMAC redundant. ( It would also relieve the clients from having to verify every AD-KDC-ISSUED element in order to find the one it's interested in - of course, this is an API artifact of libkrb5's krb5_verify_authdata_kdc_issued(). ) And then: Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER (5), realm [1] Realm, sname [2] PrincipalName, enc-part [3] EncryptedData -- EncTicketPart kdc-verifier [4] Verifier-MAC OPTIONAL, } Which would solve the S4U2proxy use case mentioned where the KDC needs to protect the Ticket from tampering by the service. Of course this changes some of the binding semantics of the current AD-CAMMAC draft. Specically this now binds all authdata together with one checksum. But the kdc-verifier cannot be verified without the Ticket anyway. This would also make the need for a special AD-CAMMAC limited to providing for "other-verifiers" I realize that it's non-trivial to extend these ASN.1 definitions, but something similar was suggested in draft-ietf-krb-wg-ticket-extensions To do the above example there will also have to be API-changes. Like krb5_find_authdata() needs to know about this. But it seems AD-CAMMAC will require minor API changes too, since it uses the service-key and not the session-key like implementations of AD-KDC-ISSUED (as Greg mentioned). Using the session-key is a lot easier for client verification. Using the service-key would probably need krb5_rd_req() to verify AD-CAMMAC to avoid the application having to look up its service-key independently . So maybe it's worth investigating if there's anyway to provide verified/signed AD-DATA in a simpler way, requiring smaller tickets and less computation when signing/verifying. I hope these thoughts are not so naive that the answer is that it will require a new protocol version or a new tkt-vno... ;-) /Peter From nobody Wed Jun 11 06:29:02 2014 Return-Path: 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 939211A0088 for ; Wed, 11 Jun 2014 06:29:01 -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 C-lZjgEyC7pR for ; Wed, 11 Jun 2014 06:28:59 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 286EA1A0084 for ; Wed, 11 Jun 2014 06:28:59 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 11 Jun 2014 06:23:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,458,1400050800"; d="scan'208";a="546274730" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by fmsmga001.fm.intel.com with ESMTP; 11 Jun 2014 06:28:43 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Jun 2014 06:28:43 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Jun 2014 06:28:43 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.122]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 21:28:41 +0800 From: "Zheng, Kai" To: "Nordgren, Bryce L -FS" , "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQLSYH4wABj0KrA= Date: Wed, 11 Jun 2014 13:28:40 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118E445F@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6D5EBE@001FSN2MPN1-044.001f.mgd2.msft.net> In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6D5EBE@001FSN2MPN1-044.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EZOFPJX4BEp8PIokpVa3KbFBl0w Cc: "Jiang, Weihua" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:29:01 -0000 Hi Bryce, Thanks for your interest and valuable input. The proposal assumes identities from 3rd party identity system are already = synced with KDC backend identity store, either by manually or automatic pro= cess,=20 either from other identity system to KDC or from KDC to other identity syst= em. It assumes token authority against the identity system can issue JWT to= ken with defined header attributes by this mechanism, so that Kerberos and the = mechanism can determine the principal and realm based on the token as=20 target client principal to issue ticket. However, I understand it's important to also consider the sync process betw= een other identity system and KDC backend store for the users/principals th= at need to do token authentication against KDC. It might be covered in this wo= rk but better in future version, or another effort. So far I just have some= questions as follows. 1. Could we define standard admin protocol to allow automatic user/principa= l sync between target identity system and KDC in both directions? Can kx509= =20 help here or other lightweight approach? Sure the process should be done in= separate secure channel by KDC admin. Can the sync be done in acceptable t= ime? 2. Related, is there any existing standard or practice to dynamically provi= sioning or destroying Kerberos principal accounts on demand in batch mode o= r one by one?=20 This could be useful in large cluster with thousands of nodes (each require= s quite a few service principals). 3. Could we relax Kerberos further, allow KDC issue ticket for non-exist pr= incipal and just determine the principal using defined token attributes (or= mapping)? I'm not=20 very sure this makes sense since this may violate Kerberos protocol but thi= nk about in some cases Kerberos can be just used as secure channel like SSL= and the primary authentication is already done for token prior to ticket requesting. Or if = principal is absolutely a must and should be exist in KDC backend anyway, c= ould it be dynamically provisioned in the client request channel when KDC find the principal isn't= exist but the KDC policy allows to create it right now? =20 >> Is your MIT krb5 plugin code somewhere public? Well I would clean up the POC codes and make it look better. When it's read= y we'll make it public and update here. Hope this can be done soon. Regards, Kai -----Original Message----- From: Nordgren, Bryce L -FS [mailto:bnordgren@fs.fed.us]=20 Sent: Wednesday, June 11, 2014 4:57 AM To: Zheng, Kai; kitten@ietf.org; krbdev@mit.edu Subject: RE: Token Preauth for Kerberos >This proposes to add another preauthentication mechanism similar to OTP=20 >and PKINIT for Kerberos, based on Kerberos preauthentication framework=20 >and FAST tunnel. It allows 3rd party token in JWT format like OAuth=20 >bearer token can be used as credential to authenticate to KDC for a=20 >normal principal instead of user password. When using the token to=20 >request a tgt, the user name or other attributes claimed in the token=20 >must match the target Kerberos principal. PKI is used to establish the=20 >trust relationship between 3rd party token issuer and KDC. Very cool. Might I ask how you map identities from the 3rd party scheme into the Kerbe= ros PRINCIPAL@REALM scheme? I assume from the above that the actual binding= is performed using a kx509 certificate issued by a trusted CA? Is there a = proposed algorithm to generate Kerberos identities from 3rd party ones, or = is this a function of the CA? Let me back up a bit. Is this being proposed as a gateway such that identit= ies from 3rd party identity systems have a standardized representation in K= erberos (thus ensuring that tokens and Kerberos identities are correctly as= sociated)? Or is this a means for manually created users in the local KDC t= o use their "regular" password? If the latter, how does one ensure that the= same person is in control of the Kerberos identity and the external one? Bryce PS: Is your MIT krb5 plugin code somewhere public? :) This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Wed Jun 11 06:43:30 2014 Return-Path: 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 6112D1A00DD for ; Wed, 11 Jun 2014 06:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 MBFOi0WFV4Oj for ; Wed, 11 Jun 2014 06:43:27 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAA51A00DA for ; Wed, 11 Jun 2014 06:43:27 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 11 Jun 2014 06:43:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,458,1400050800"; d="scan'208";a="444278606" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by azsmga001.ch.intel.com with ESMTP; 11 Jun 2014 06:43:03 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Jun 2014 06:43:03 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Jun 2014 06:43:03 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.81]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 21:42:57 +0800 From: "Zheng, Kai" To: "Zheng, Kai" , "Nordgren, Bryce L -FS" , "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQLSYH4wABj0KrAAC1/DgA== Date: Wed, 11 Jun 2014 13:42:56 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118E6498@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6D5EBE@001FSN2MPN1-044.001f.mgd2.msft.net> <8D5F7E3237B3ED47B84CF187BB17B666118E445F@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118E445F@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4MqBcgPDxSYokj4uiol5OG6PzaM Cc: "Jiang, Weihua" , "Smith, Ned" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:43:29 -0000 -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Zheng, Kai Sent: Wednesday, June 11, 2014 9:29 PM To: Nordgren, Bryce L -FS; kitten@ietf.org; krbdev@mit.edu Cc: Jiang, Weihua Subject: Re: [kitten] Token Preauth for Kerberos Hi Bryce, Thanks for your interest and valuable input. The proposal assumes identities from 3rd party identity system are already = synced with KDC backend identity store, either by manually or automatic pro= cess, either from other identity system to KDC or from KDC to other identit= y system. It assumes token authority against the identity system can issue = JWT token with defined header attributes by this mechanism, so that Kerbero= s and the mechanism can determine the principal and realm based on the toke= n as target client principal to issue ticket. However, I understand it's important to also consider the sync process betw= een other identity system and KDC backend store for the users/principals th= at need to do token authentication against KDC. It might be covered in this= work but better in future version, or another effort. So far I just have s= ome questions as follows. 1. Could we define standard admin protocol to allow automatic user/principa= l sync between target identity system and KDC in both directions? Can kx509= help here or other lightweight approach? Sure the process should be done i= n separate secure channel by KDC admin. Can the sync be done in acceptable = time? 2. Related, is there any existing standard or practice to dynamically provi= sioning or destroying Kerberos principal accounts on demand in batch mode o= r one by one?=20 This could be useful in large cluster with thousands of nodes (each require= s quite a few service principals). 3. Could we relax Kerberos further, allow KDC issue ticket for non-exist pr= incipal and just determine the principal using defined token attributes (or= mapping)? I'm not very sure this makes sense since this may violate Kerber= os protocol but think about in some cases Kerberos can be just used as secu= re channel like SSL and the primary authentication is already done for toke= n prior to ticket requesting. Or if principal is absolutely a must and shou= ld be exist in KDC backend anyway, could it be dynamically provisioned in t= he client request channel when KDC find the principal isn't exist but the K= DC policy allows to create it right now? =20 >> Is your MIT krb5 plugin code somewhere public? Well I would clean up the POC codes and make it look better. When it's read= y we'll make it public and update here. Hope this can be done soon. Regards, Kai -----Original Message----- From: Nordgren, Bryce L -FS [mailto:bnordgren@fs.fed.us] Sent: Wednesday, June 11, 2014 4:57 AM To: Zheng, Kai; kitten@ietf.org; krbdev@mit.edu Subject: RE: Token Preauth for Kerberos >This proposes to add another preauthentication mechanism similar to OTP=20 >and PKINIT for Kerberos, based on Kerberos preauthentication framework=20 >and FAST tunnel. It allows 3rd party token in JWT format like OAuth=20 >bearer token can be used as credential to authenticate to KDC for a=20 >normal principal instead of user password. When using the token to=20 >request a tgt, the user name or other attributes claimed in the token=20 >must match the target Kerberos principal. PKI is used to establish the=20 >trust relationship between 3rd party token issuer and KDC. Very cool. Might I ask how you map identities from the 3rd party scheme into the Kerbe= ros PRINCIPAL@REALM scheme? I assume from the above that the actual binding= is performed using a kx509 certificate issued by a trusted CA? Is there a = proposed algorithm to generate Kerberos identities from 3rd party ones, or = is this a function of the CA? Let me back up a bit. Is this being proposed as a gateway such that identit= ies from 3rd party identity systems have a standardized representation in K= erberos (thus ensuring that tokens and Kerberos identities are correctly as= sociated)? Or is this a means for manually created users in the local KDC t= o use their "regular" password? If the latter, how does one ensure that the= same person is in control of the Kerberos identity and the external one? Bryce PS: Is your MIT krb5 plugin code somewhere public? :) This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nobody Wed Jun 11 09:17:37 2014 Return-Path: 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 EC2251A05F5 for ; Wed, 11 Jun 2014 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 xaOkCZNmwdEh for ; Wed, 11 Jun 2014 09:17:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id DB5D21A01AB for ; Wed, 11 Jun 2014 09:17:26 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5BGHQcm005412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Jun 2014 12:17:26 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5BGHO0P006680; Wed, 11 Jun 2014 12:17:25 -0400 Message-ID: <1402503444.13617.1.camel@willson.usersys.redhat.com> From: Simo Sorce To: Peter Mogensen Date: Wed, 11 Jun 2014 12:17:24 -0400 In-Reply-To: <539849AA.4000506@one.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> <539849AA.4000506@one.com> 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.23 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tu7-FVNrKKZ_CMmjtY07W3SOrI8 Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:17:34 -0000 On Wed, 2014-06-11 at 14:20 +0200, Peter Mogensen wrote: > The solution in AD-CAMMAC seems very complex too, requiring > effectively calculating the entire EncTicketPart twice - and once for > every present AD-CAMMAC present. I am confused about this statement. The AD-CAMMAC draft specifies that it contains a sequence of AD elements, that means you have only 1 AD-CAMMAC for all the AD data you want to protect. You check the whole thing only once. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Jun 11 10:03:17 2014 Return-Path: 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 8AF291A01CE for ; Wed, 11 Jun 2014 10:03:15 -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 MANsdRQpZ4Bv for ; Wed, 11 Jun 2014 10:03:13 -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 41BA91A01B7 for ; Wed, 11 Jun 2014 10:03:13 -0700 (PDT) Received: from [10.163.144.45] (unknown [80.62.117.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by officesmtp2.one.com (Postfix) with ESMTPSA id 42951801173A3; Wed, 11 Jun 2014 17:03:06 +0000 (UTC) Message-ID: <53988BB6.8010409@one.com> Date: Wed, 11 Jun 2014 19:02:46 +0200 From: Peter Mogensen 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 References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> <539849AA.4000506@one.com> <1402503444.13617.1.camel@willson.usersys.redhat.com> In-Reply-To: <1402503444.13617.1.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/fGY6HtjqJWzbNQgFOYH-rdKl5Yc Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:03:15 -0000 On 2014-06-11 18:17, Simo Sorce wrote: > On Wed, 2014-06-11 at 14:20 +0200, Peter Mogensen wrote: >> The solution in AD-CAMMAC seems very complex too, requiring >> effectively calculating the entire EncTicketPart twice - and once for >> every present AD-CAMMAC present. > > I am confused about this statement. The AD-CAMMAC draft specifies that > it contains a sequence of AD elements, that means you have only 1 > AD-CAMMAC for all the AD data you want to protect. You check the whole > thing only once. I were not sure whether you could rule out any use case requiring merging of 2 AD-CAMMAC elements with - say - different other-verifier checksums for which the KDC didn't have all the keys. But I guess that since other-verifier restricts the principals to be in the KDC realm, that could not happen. Still... the whole EncTicketPart has to be constructed and DER-encoded twice to add a kdc-verifier. /Peter From nobody Wed Jun 11 10:08:25 2014 Return-Path: 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 7F6C11A01B7 for ; Wed, 11 Jun 2014 10:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 sPAXNIklvZKk for ; Wed, 11 Jun 2014 10:08:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 609291A01FA for ; Wed, 11 Jun 2014 10:08:13 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5BH8C1A009779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Jun 2014 13:08:12 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5BH8BiE005199; Wed, 11 Jun 2014 13:08:11 -0400 Message-ID: <1402506490.13617.9.camel@willson.usersys.redhat.com> From: Simo Sorce To: Peter Mogensen Date: Wed, 11 Jun 2014 13:08:10 -0400 In-Reply-To: <53988BB6.8010409@one.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> 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.23 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/_1qVReQq9N-XLQIlnnJr0SvVSzE Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:08:23 -0000 On Wed, 2014-06-11 at 19:02 +0200, Peter Mogensen wrote: > On 2014-06-11 18:17, Simo Sorce wrote: > > On Wed, 2014-06-11 at 14:20 +0200, Peter Mogensen wrote: > >> The solution in AD-CAMMAC seems very complex too, requiring > >> effectively calculating the entire EncTicketPart twice - and once for > >> every present AD-CAMMAC present. > > > > I am confused about this statement. The AD-CAMMAC draft specifies that > > it contains a sequence of AD elements, that means you have only 1 > > AD-CAMMAC for all the AD data you want to protect. You check the whole > > thing only once. > > > I were not sure whether you could rule out any use case requiring > merging of 2 AD-CAMMAC elements with - say - different other-verifier > checksums for which the KDC didn't have all the keys. > But I guess that since other-verifier restricts the principals to be in > the KDC realm, that could not happen. > > Still... the whole EncTicketPart has to be constructed and DER-encoded > twice to add a kdc-verifier. That is done to bind the CAMMAC to a specific ticket, it is an additional protection that you probably want for your use case too. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum@redhat.com Wed Jun 11 07:52:13 2014 Return-Path: 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 705C91A0141 for ; Wed, 11 Jun 2014 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 SyiA8cZi3_5v for ; Wed, 11 Jun 2014 07:52:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 05C7E1A0127 for ; Wed, 11 Jun 2014 07:52:10 -0700 (PDT) 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 s5BEq9GW007246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Jun 2014 10:52:10 -0400 Received: from vpn-52-75.rdu2.redhat.com (vpn-52-75.rdu2.redhat.com [10.10.52.75]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5BEq4cT027981 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jun 2014 10:52:07 -0400 Message-ID: <1402498324.2955.2.camel@ipa.example.com> From: Nathaniel McCallum To: "Zheng, Kai" Date: Wed, 11 Jun 2014 10:52:04 -0400 In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118D8E14@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> <8D5F7E3237B3ED47B84CF187BB17B666118D8E14@SHSMSX103.ccr.corp.intel.com> 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/nN-klsmxitDJVGDyv5Q9bFByi6w X-Mailman-Approved-At: Wed, 11 Jun 2014 16:40:54 -0700 Cc: "kitten@ietf.org" , "Jiang, Weihua" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:53:25 -0000 On Wed, 2014-06-11 at 08:15 +0000, Zheng, Kai wrote: > Hi Greg, > > Thanks for your valuable feedback and suggestions! > > 1. Yes you're right I'm taking the OTP approach and use the FAST armor key as the reply key. As mentioned in the proposal we suggest PKINIT be deployed along with this mechanism, > And client uses PKINIT anonymous to obtain the armor ticket. It doesn't provide mutual authentication since only KDC is authenticated to client with the configured certificate of KDC and > client doesn't due to lacking of certificate as to avoid the deployment overhead in our solution. So protecting the token here in AS-REQ exchange mainly depends on the FAST tunnel and > client should be careful about the armor ticket. You may be interested in this proposal: http://mailman.mit.edu/pipermail/krbdev/2014-May/011958.html Nathaniel From nobody Thu Jun 12 00:12:19 2014 Return-Path: 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 9884B1A022B for ; Thu, 12 Jun 2014 00:12:16 -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 xxlJ624u5Yzr for ; Thu, 12 Jun 2014 00:12:14 -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 759DD1A01DC for ; Thu, 12 Jun 2014 00:12:14 -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 98035801173A3; Thu, 12 Jun 2014 07:12:12 +0000 (UTC) Message-ID: <539952CC.8020703@one.com> Date: Thu, 12 Jun 2014 09:12:12 +0200 From: Peter Mogensen 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 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> In-Reply-To: <1402506490.13617.9.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/CAoMlJ0AxTCdKrMKS8_RgG0GdN0 Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:12:16 -0000 On 2014-06-11 19:08, Simo Sorce wrote: >> Still... the whole EncTicketPart has to be constructed and DER-encoded >> twice to add a kdc-verifier. > > That is done to bind the CAMMAC to a specific ticket, it is an > additional protection that you probably want for your use case too. 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. As the cammac draft says: "...assuring the KDC that a malicious service has not substituted a mismatched CAMMAC received from another ticket." But if the kdc-verifier was placed out side the EncTicketPart, then that would also provide that protection and not require computing the ticket twice - right? /Peter From nobody Thu Jun 12 05:47:19 2014 Return-Path: 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 DE9E01B29F5 for ; Thu, 12 Jun 2014 05:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 KQ1-nmcT4BM1 for ; Thu, 12 Jun 2014 05:47:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id A38681B2864 for ; Thu, 12 Jun 2014 05:47:16 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5CClEnZ008237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jun 2014 08:47:14 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CClCfZ009548; Thu, 12 Jun 2014 08:47:13 -0400 Message-ID: <1402577232.22737.26.camel@willson.usersys.redhat.com> From: Simo Sorce To: Peter Mogensen Date: Thu, 12 Jun 2014 08:47:12 -0400 In-Reply-To: <539952CC.8020703@one.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> 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.27 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sWSoA1wvWEV6V_CxLbDx5Sx0QP4 Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:47:18 -0000 On Thu, 2014-06-12 at 09:12 +0200, Peter Mogensen wrote: > On 2014-06-11 19:08, Simo Sorce wrote: > >> Still... the whole EncTicketPart has to be constructed and DER-encoded > >> twice to add a kdc-verifier. > > > > That is done to bind the CAMMAC to a specific ticket, it is an > > additional protection that you probably want for your use case too. > > 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. > As the cammac draft says: > "...assuring the KDC that a malicious service has not substituted a > mismatched CAMMAC received from another ticket." > > But if the kdc-verifier was placed out side the EncTicketPart, then that > would also provide that protection and not require computing the ticket > twice - right? Exactly, the computing of EncTicketPart is used to bind the CAMMAC to a specific TGT, it is an additional feature that basically allows you to bind service tickets back to the original TGT and back to the original AS Request (assuming you keep track of that information via some sort of auditing logs and perhaps a new AD with a session number). Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Jun 12 05:55:37 2014 Return-Path: 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 ; 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 ; 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 ; 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 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 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Thu Jun 12 06:01:09 2014 Return-Path: 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 CBABB1B286B for ; Thu, 12 Jun 2014 06:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 A__DhlTqUHhp for ; Thu, 12 Jun 2014 06:01:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 33ADA1A03ED for ; Thu, 12 Jun 2014 06:01:03 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5CD12x7012043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jun 2014 09:01:02 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CD11C0032394; Thu, 12 Jun 2014 09:01:01 -0400 Message-ID: <1402578060.22737.30.camel@willson.usersys.redhat.com> From: Simo Sorce To: Peter Mogensen Date: Thu, 12 Jun 2014 09:01:00 -0400 In-Reply-To: <5399A341.3070104@one.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> <5399A341.3070104@one.com> 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.24 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VqVghfkcLOfcYzEkpX2CehoVUEA Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:01:08 -0000 On Thu, 2014-06-12 at 14:55 +0200, Peter Mogensen wrote: > 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? Yes, but we could as well have added just the principal name and the expiration time of the authdata owner as an AD inside the CAMMAC, and that was considered. But in the end we found more useful to just add all the data from EncTicketPart as it included all the above and additionally bind to the ticket. > 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. Yes there are plans see the old draft about PAD which we put on hold until CAMMAC was ready, that is an example of what you say. > 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. Yes, we decided to combine this protection with ticket binding in one single operation by using EncTicketPart in the MAC calculation, makign the CAMMAC *simpler* to build. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Jun 12 06:19:58 2014 Return-Path: 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 9C3101B2A17 for ; Thu, 12 Jun 2014 06:19:57 -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 d-68aLxS5Su4 for ; Thu, 12 Jun 2014 06:19:56 -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 D55851B2A16 for ; Thu, 12 Jun 2014 06:19:55 -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 DDE23801173A3; Thu, 12 Jun 2014 13:19:53 +0000 (UTC) Message-ID: <5399A8F9.50609@one.com> Date: Thu, 12 Jun 2014 15:19:53 +0200 From: Peter Mogensen 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 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> <5399A341.3070104@one.com> <1402578060.22737.30.camel@willson.usersys.redhat.com> In-Reply-To: <1402578060.22737.30.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/ebSpxZaM8qysGLZlkKYhf8i0JaU Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:19:57 -0000 On 2014-06-12 15:01, Simo Sorce wrote: > Yes, we decided to combine this protection with ticket binding in one > single operation by using EncTicketPart in the MAC calculation, makign > the CAMMAC *simpler* to build. I must have misunderstood something fundamental then. The draft says: "the KDC computes the MAC in the kdc- verifier over the ASN.1 DER encoding of the EncTicketPart of the surrounding ticket, *but* where the AuthorizationData value in the EncTicketPart contains the AuthorizationData value contained in the CAMMAC instead of the AuthorizationData value that would otherwise be present in the ticket." (My emphasis) So it's not the actual EncTicketPart which is used for the MAC. It's another version with different AuthorizationData. You have to compute both versions. Compared to simply just placing the kdc-verifier outside of the EncTicketPart and using the actual EncTicketPart for computing the MAC. ... which I know can give compatability problems, but just so we understand what each other is talking about. I would intuitively think it was simpler to just sign the entire actual EncTicketPart with the kdc-verifier. Of course, that will then bind to also any other authdata in the ticket. /Peter From nobody Thu Jun 12 06:23:32 2014 Return-Path: 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 319421B2A17 for ; Thu, 12 Jun 2014 06:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 2m3IUlk7DKBp for ; Thu, 12 Jun 2014 06:23:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 687871B2A0A for ; Thu, 12 Jun 2014 06:23:29 -0700 (PDT) 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 s5CDNQpC007944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jun 2014 09:23:27 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CDNPA3027374; Thu, 12 Jun 2014 09:23:26 -0400 Message-ID: <1402579405.22737.37.camel@willson.usersys.redhat.com> From: Simo Sorce To: Peter Mogensen Date: Thu, 12 Jun 2014 09:23:25 -0400 In-Reply-To: <5399A8F9.50609@one.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> <5399A341.3070104@one.com> <1402578060.22737.30.camel@willson.usersys.redhat.com> <5399A8F9.50609@one.com> 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/5uNKfx8exGMfsYeT4y91ceCXU2w Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:23:31 -0000 On Thu, 2014-06-12 at 15:19 +0200, Peter Mogensen wrote: > On 2014-06-12 15:01, Simo Sorce wrote: > > Yes, we decided to combine this protection with ticket binding in one > > single operation by using EncTicketPart in the MAC calculation, makign > > the CAMMAC *simpler* to build. > > I must have misunderstood something fundamental then. > > The draft says: > "the KDC computes the MAC in the kdc- > verifier over the ASN.1 DER encoding of the EncTicketPart of the > surrounding ticket, *but* where the AuthorizationData value in the > EncTicketPart contains the AuthorizationData value contained in > the CAMMAC instead of the AuthorizationData value that would > otherwise be present in the ticket." > > (My emphasis) > > So it's not the actual EncTicketPart which is used for the MAC. It's > another version with different AuthorizationData. You have to compute > both versions. > Compared to simply just placing the kdc-verifier outside of the > EncTicketPart and using the actual EncTicketPart for computing the MAC. > ... which I know can give compatability problems, but just so we > understand what each other is talking about. > > I would intuitively think it was simpler to just sign the entire actual > EncTicketPart with the kdc-verifier. Of course, that will then bind to > also any other authdata in the ticket. The idea is to compute MAC on: 1) EncTicketPart w/o any Authorization Data (otherwise chicken-egg as you are still computing AD data, CAMMAC is AD data itself) + 2) AD Data contained in CAMMAC (we want to protect data within the CAMMAC, anything outside of it is not our business). Makes sense ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Jun 12 06:38:26 2014 Return-Path: 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 AABEE1B2A2C for ; Thu, 12 Jun 2014 06:38:20 -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 GNegVdXPKj1d for ; Thu, 12 Jun 2014 06:38:17 -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 C1A431A0086 for ; Thu, 12 Jun 2014 06:38:16 -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 7F4EB801173A3; Thu, 12 Jun 2014 13:38:15 +0000 (UTC) Message-ID: <5399AD46.4020805@one.com> Date: Thu, 12 Jun 2014 15:38:14 +0200 From: Peter Mogensen 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 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> <5399A341.3070104@one.com> <1402578060.22737.30.camel@willson.usersys.redhat.com> <5399A8F9.50609@one.com> <1402579405.22737.37.camel@willson.usersys.redhat.com> In-Reply-To: <1402579405.22737.37.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/g9gfaJCq01_EXVKGDUIlnQ9fxKY Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:38:21 -0000 On 2014-06-12 15:23, Simo Sorce wrote: > The idea is to compute MAC on: > > 1) EncTicketPart w/o any Authorization Data (otherwise chicken-egg as > you are still computing AD data, CAMMAC is AD data itself) > + > 2) AD Data contained in CAMMAC (we want to protect data within the > CAMMAC, anything outside of it is not our business). > > Makes sense ? Yes. And that's also the way I've read the draft and which is the basis for what I wrote. So, do you agree that the chicken-egg problem in 1) would also have been solved if the kdc-verifier were placed in the ticket outside of the EncTicketPart? Are you saying that computing EncTicketPart w/o any Authorization Data + computing the final EncTicketPart is simpler than just computing the final EncTicketPart? And is it correct that even though AD not in the CAMMAC is not our business it doesn't make much difference whether it's included in the kdc-verifier, since it can only be verified having that specific ticket anyway? In an ideal world I would have considered placing the kdc-verifier outside of EncTicketPart more intutive. Anyway... I guess my primary grief is not the kdc-verifier, but the svc-verifier and that just adding a small piece of data in AD-CAMMAC to a ticket will increase its size from 400-500 bytes (AFAIR) to >600. About 20%. That's a problem if you try to squeeze several tickets into 1 IP packet. ... and it seems like only necessary because of the rule that the client can add anything to authorization-data. Otherwise the data would already have been protected by the service-key once. /Peter From nobody Thu Jun 12 06:50:11 2014 Return-Path: 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 9D8891B2A3B for ; Thu, 12 Jun 2014 06:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 oo8dkCR6S3lY for ; Thu, 12 Jun 2014 06:50:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C8FBD1A00D5 for ; Thu, 12 Jun 2014 06:50:06 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5CDo6RS005771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jun 2014 09:50:06 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CDo4e2021589; Thu, 12 Jun 2014 09:50:05 -0400 Message-ID: <1402581004.22737.39.camel@willson.usersys.redhat.com> From: Simo Sorce To: Peter Mogensen Date: Thu, 12 Jun 2014 09:50:04 -0400 In-Reply-To: <5399AD46.4020805@one.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> <5399A341.3070104@one.com> <1402578060.22737.30.camel@willson.usersys.redhat.com> <5399A8F9.50609@one.com> <1402579405.22737.37.camel@willson.usersys.redhat.com> <5399AD46.4020805@one.com> 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.27 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/b6Wuvxj_zX9skMYsiZBvVLo1TNw Cc: "kitten@ietf.org" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:50:09 -0000 On Thu, 2014-06-12 at 15:38 +0200, Peter Mogensen wrote: > On 2014-06-12 15:23, Simo Sorce wrote: > > The idea is to compute MAC on: > > > > 1) EncTicketPart w/o any Authorization Data (otherwise chicken-egg as > > you are still computing AD data, CAMMAC is AD data itself) > > + > > 2) AD Data contained in CAMMAC (we want to protect data within the > > CAMMAC, anything outside of it is not our business). > > > > Makes sense ? > > Yes. And that's also the way I've read the draft and which is the basis > for what I wrote. > > So, do you agree that the chicken-egg problem in 1) would also have been > solved if the kdc-verifier were placed in the ticket outside of the > EncTicketPart? > > Are you saying that computing EncTicketPart w/o any Authorization Data + > computing the final EncTicketPart is simpler than just computing the > final EncTicketPart? > > And is it correct that even though AD not in the CAMMAC is not our > business it doesn't make much difference whether it's included in the > kdc-verifier, since it can only be verified having that specific ticket > anyway? > > In an ideal world I would have considered placing the kdc-verifier > outside of EncTicketPart more intutive. > > Anyway... I guess my primary grief is not the kdc-verifier, but the > svc-verifier and that just adding a small piece of data in AD-CAMMAC to > a ticket will increase its size from 400-500 bytes (AFAIR) to >600. > About 20%. That's a problem if you try to squeeze several tickets into 1 > IP packet. ... and it seems like only necessary because of the rule that > the client can add anything to authorization-data. Otherwise the data > would already have been protected by the service-key once. We have to work within the framework of RFC 4120 I am afraid, so it is what it is. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Jun 12 14:37:23 2014 Return-Path: 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 8794A1A025E for ; Thu, 12 Jun 2014 14:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 4CkqHCKvEv7q for ; Thu, 12 Jun 2014 14:37:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF731A01CE for ; Thu, 12 Jun 2014 14:37:20 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5CLbJ6i022433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jun 2014 17:37:19 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CLbIIt010555; Thu, 12 Jun 2014 17:37:19 -0400 Message-ID: <1402609038.22737.57.camel@willson.usersys.redhat.com> From: Simo Sorce To: "Zheng, Kai" Date: Thu, 12 Jun 2014 17:37:18 -0400 In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> 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.24 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/n-xF6FzVxPzETC-nYIcez849LGc Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:37:21 -0000 On Tue, 2014-06-10 at 12:19 +0000, Zheng, Kai wrote: > Hi all, > > I would like to mention an effort regarding Kerberos and propose a new > Kerberos preauth mechanism, token-preauth. Before dive into that, > please kindly allow me to introduce, mainly for the background and > scenario for the proposal. > > I'm an engineer from Intel and develop identity and security related > products. The current focus is Apache Hadoop, and our goal is enabling > Hadoop to support more authentication mechanisms and providers. > Currently Hadoop only supports Kerberos authentication method as the > built-in secured one and it's not easy to add more since it involves > changing into many projects on top of it in the large ecosystem. The > community had proposed a token based authentication, planned to add > TokenAuth method for Hadoop and by TokenAuth then all kinds of > authentication providers can be supported since their authentication > results can be wrapped into token, and the token can be employed to > authenticate to Hadoop across the ecosystem. The effort is still > undergoing. Considering the complexity, risk and deployment overhead > of this approach, our team investigate and think of another possible > solution, i.e. support token in Kerberos. The basic idea is allow end > users to authenticate to Kerberos with their tokens and obtain > tickets, then access Hadoop services using the tickets as current flow > goes. The PoC was already done, and we make it work seamlessly from > MIT Kerberos to Java world and Hadoop. However we think it's very > important to get the key point token-preauth be reviewed by you > security and Kerberos experts, to make sure it's defined and > implemented in compliance with the existing standards and protocols, > without involving security critical leaks. So please kindly give your > feedback and we appreciate it. Kai, have you considered protocol transition (s4u2self) + constrained delegation (s4u2proxy) to get tickets at an authentication gateway instead of a new pre auth mechanism ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Jun 13 00:16:26 2014 Return-Path: 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 09D331B28C7 for ; Fri, 13 Jun 2014 00:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 QA8I-Na8PfwM for ; Fri, 13 Jun 2014 00:16:23 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 96A501A00DD for ; Fri, 13 Jun 2014 00:16:23 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 13 Jun 2014 00:16:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,470,1400050800"; d="scan'208";a="445051835" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by azsmga001.ch.intel.com with ESMTP; 13 Jun 2014 00:16:22 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Jun 2014 00:16:22 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Jun 2014 00:16:21 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.122]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 15:16:20 +0800 From: "Zheng, Kai" To: Simo Sorce Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDA= Date: Fri, 13 Jun 2014 07:16:19 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> In-Reply-To: <1402609038.22737.57.camel@willson.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UCu7dRMUDvjavOyyzWZSgbH38PA Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 07:16:25 -0000 SGkgU2ltbywNCg0KPj4gaGF2ZSB5b3UgY29uc2lkZXJlZCBwcm90b2NvbCB0cmFuc2l0aW9uIChz NHUyc2VsZikgKyBjb25zdHJhaW5lZCBkZWxlZ2F0aW9uIChzNHUycHJveHkpIHRvIGdldCB0aWNr ZXRzIGF0IGFuIGF1dGhlbnRpY2F0aW9uIGdhdGV3YXkgaW5zdGVhZCBvZiBhIG5ldyBwcmUgYXV0 aCBtZWNoYW5pc20gPw0KDQpZZXMgd2UgcHJvcG9zZWQgZm9yIHRoZSBIYWRvb3AgY29tbXVuaXR5 IGEgY2VudHJhbGl6ZWQgQXV0aG4gJiBBdXRoeiBTZXJ2ZXIgKEhBUykgdGhhdCBtaWdodCBiZSBs aWtlIHRoZSBnYXRld2F5IGFzIHlvdSBtZW50aW9uZWQuIEl0J3Mgd2lkZWx5IGRpc2N1c3NlZCBh bmQgY29uZmlybWVkIHRoYXQgaXQgd291bGQgYmUgZ3JlYXQgdGhlIHNlcnZlciBhbGxvd3MgcGx1 Z2luIG9mIGF1dGhlbnRpY2F0aW9uIG1vZHVsZS9wcm92aWRlciBidXQgYWxsIG1lY2hhbmlzbXMg b3V0cHV0IHRva2VuLiBTdXJlIEkgZ3Vlc3MgaXQncyBwb3NzaWJsZSB0byB1c2UgdG9rZW4gdG8g Z28gdGhydSBzNHUyc2VsZiBhbmQgczR1MnByb3h5IGluIHRoZSBLZXJiZXJvcyBmYWNpbGl0eSBh Y3Jvc3MgdGhlIGVjb3N5c3RlbSBidXQgYXMgZmFyIGFzIEkga25vdyBKUkUganVzdCBzdGFydHMg dG8gc3VwcG9ydCBpdCBmcm9tIEpESzguIEFueWhvdyBJIHdvdWxkIGNoZWNrIHRoaXMgYW5kIG1h a2Ugc3VyZSBpdCdzIGEgZG9hYmxlIG9wdGlvbiBub3QgaW4gc28gbG9uZyBmdXR1cmUuDQoNCkEg cXVlc3Rpb24gcmVnYXJkaW5nIHRoaXM6DQpJcyBpdCBwb3NzaWJsZSB0byBjb250YWluIHRoZSB0 b2tlbiBpbiBzZXJ2aWNlIHRpY2tldCByZXN1bHRlZCBmcm9tIHM0dTJzZWxmIGFuZCBzNHUycHJv eHkgYXMgYXV0aG9yaXphdGlvbiBkYXRhIHNvIHRoYXQgc2VydmljZXMgY2FuIGdldCBpdCBhcyBw cm9wb3NlZCBpbiB0b2tlbi1wcmVhdXRoPyBOb3RlIGluIG91ciB3YW50ZWQgc29sdXRpb24sIHRv a2VuIG5vdCBqdXN0IHNlcnZlcyBmb3IgYXV0aGVudGljYXRpb24sIGJ1dCBhbHNvIGlzIG1lYW50 IHRvIGJlIHBhc3NlZCAob3IgdGhlIHRva2VuIGF0dHJpYnV0ZXMpIHRvIHNlcnZpY2Ugc2lkZSBm b3IgZmluZS1ncmFpbmVkIGF1dGhvcml6YXRpb24uDQoNClRoYW5rcyAmIHJlZ2FyZHMsDQpLYWkN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNpbW8gU29yY2UgW21haWx0bzpz aW1vQHJlZGhhdC5jb21dIA0KU2VudDogRnJpZGF5LCBKdW5lIDEzLCAyMDE0IDU6MzcgQU0NClRv OiBaaGVuZywgS2FpDQpDYzoga2l0dGVuQGlldGYub3JnOyBrcmJkZXZAbWl0LmVkdQ0KU3ViamVj dDogUmU6IFtraXR0ZW5dIFRva2VuIFByZWF1dGggZm9yIEtlcmJlcm9zDQoNCk9uIFR1ZSwgMjAx NC0wNi0xMCBhdCAxMjoxOSArMDAwMCwgWmhlbmcsIEthaSB3cm90ZToNCj4gSGkgYWxsLA0KPiAN Cj4gSSB3b3VsZCBsaWtlIHRvIG1lbnRpb24gYW4gZWZmb3J0IHJlZ2FyZGluZyBLZXJiZXJvcyBh bmQgcHJvcG9zZSBhIG5ldyANCj4gS2VyYmVyb3MgcHJlYXV0aCBtZWNoYW5pc20sIHRva2VuLXBy ZWF1dGguIEJlZm9yZSBkaXZlIGludG8gdGhhdCwgDQo+IHBsZWFzZSBraW5kbHkgYWxsb3cgbWUg dG8gaW50cm9kdWNlLCBtYWlubHkgZm9yIHRoZSBiYWNrZ3JvdW5kIGFuZCANCj4gc2NlbmFyaW8g Zm9yIHRoZSBwcm9wb3NhbC4NCj4gDQo+IEknbSBhbiBlbmdpbmVlciBmcm9tIEludGVsIGFuZCBk ZXZlbG9wIGlkZW50aXR5IGFuZCBzZWN1cml0eSByZWxhdGVkIA0KPiBwcm9kdWN0cy4gVGhlIGN1 cnJlbnQgZm9jdXMgaXMgQXBhY2hlIEhhZG9vcCwgYW5kIG91ciBnb2FsIGlzIGVuYWJsaW5nIA0K PiBIYWRvb3AgdG8gc3VwcG9ydCBtb3JlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgYW5kIHBy b3ZpZGVycy4NCj4gQ3VycmVudGx5IEhhZG9vcCBvbmx5IHN1cHBvcnRzIEtlcmJlcm9zIGF1dGhl bnRpY2F0aW9uIG1ldGhvZCBhcyB0aGUgDQo+IGJ1aWx0LWluIHNlY3VyZWQgb25lIGFuZCBpdCdz IG5vdCBlYXN5IHRvIGFkZCBtb3JlIHNpbmNlIGl0IGludm9sdmVzIA0KPiBjaGFuZ2luZyBpbnRv IG1hbnkgcHJvamVjdHMgb24gdG9wIG9mIGl0IGluIHRoZSBsYXJnZSBlY29zeXN0ZW0uIFRoZSAN Cj4gY29tbXVuaXR5IGhhZCBwcm9wb3NlZCBhIHRva2VuIGJhc2VkIGF1dGhlbnRpY2F0aW9uLCBw bGFubmVkIHRvIGFkZCANCj4gVG9rZW5BdXRoIG1ldGhvZCBmb3IgSGFkb29wIGFuZCBieSBUb2tl bkF1dGggdGhlbiBhbGwga2luZHMgb2YgDQo+IGF1dGhlbnRpY2F0aW9uIHByb3ZpZGVycyBjYW4g YmUgc3VwcG9ydGVkIHNpbmNlIHRoZWlyIGF1dGhlbnRpY2F0aW9uIA0KPiByZXN1bHRzIGNhbiBi ZSB3cmFwcGVkIGludG8gdG9rZW4sIGFuZCB0aGUgdG9rZW4gY2FuIGJlIGVtcGxveWVkIHRvIA0K PiBhdXRoZW50aWNhdGUgdG8gSGFkb29wIGFjcm9zcyB0aGUgZWNvc3lzdGVtLiBUaGUgZWZmb3J0 IGlzIHN0aWxsIA0KPiB1bmRlcmdvaW5nLiBDb25zaWRlcmluZyB0aGUgY29tcGxleGl0eSwgcmlz ayBhbmQgZGVwbG95bWVudCBvdmVyaGVhZCANCj4gb2YgdGhpcyBhcHByb2FjaCwgb3VyIHRlYW0g aW52ZXN0aWdhdGUgYW5kIHRoaW5rIG9mIGFub3RoZXIgcG9zc2libGUgDQo+IHNvbHV0aW9uLCBp LmUuIHN1cHBvcnQgdG9rZW4gaW4gS2VyYmVyb3MuIFRoZSBiYXNpYyBpZGVhIGlzIGFsbG93IGVu ZCANCj4gdXNlcnMgdG8gYXV0aGVudGljYXRlIHRvIEtlcmJlcm9zIHdpdGggdGhlaXIgdG9rZW5z IGFuZCBvYnRhaW4gDQo+IHRpY2tldHMsIHRoZW4gYWNjZXNzIEhhZG9vcCBzZXJ2aWNlcyB1c2lu ZyB0aGUgdGlja2V0cyBhcyBjdXJyZW50IGZsb3cgDQo+IGdvZXMuIFRoZSBQb0Mgd2FzIGFscmVh ZHkgZG9uZSwgYW5kIHdlIG1ha2UgaXQgd29yayBzZWFtbGVzc2x5IGZyb20gDQo+IE1JVCBLZXJi ZXJvcyB0byBKYXZhIHdvcmxkIGFuZCBIYWRvb3AuIEhvd2V2ZXIgd2UgdGhpbmsgaXQncyB2ZXJ5 IA0KPiBpbXBvcnRhbnQgdG8gZ2V0IHRoZSBrZXkgcG9pbnQgdG9rZW4tcHJlYXV0aCBiZSByZXZp ZXdlZCBieSB5b3UgDQo+IHNlY3VyaXR5IGFuZCBLZXJiZXJvcyBleHBlcnRzLCB0byBtYWtlIHN1 cmUgaXQncyBkZWZpbmVkIGFuZCANCj4gaW1wbGVtZW50ZWQgaW4gY29tcGxpYW5jZSB3aXRoIHRo ZSBleGlzdGluZyBzdGFuZGFyZHMgYW5kIHByb3RvY29scywgDQo+IHdpdGhvdXQgaW52b2x2aW5n IHNlY3VyaXR5IGNyaXRpY2FsIGxlYWtzLiBTbyBwbGVhc2Uga2luZGx5IGdpdmUgeW91ciANCj4g ZmVlZGJhY2sgYW5kIHdlIGFwcHJlY2lhdGUgaXQuDQoNCkthaSwNCmhhdmUgeW91IGNvbnNpZGVy ZWQgcHJvdG9jb2wgdHJhbnNpdGlvbiAoczR1MnNlbGYpICsgY29uc3RyYWluZWQgZGVsZWdhdGlv biAoczR1MnByb3h5KSB0byBnZXQgdGlja2V0cyBhdCBhbiBhdXRoZW50aWNhdGlvbiBnYXRld2F5 IGluc3RlYWQgb2YgYSBuZXcgcHJlIGF1dGggbWVjaGFuaXNtID8NCg0KU2ltby4NCg0KLS0NClNp bW8gU29yY2UgKiBSZWQgSGF0LCBJbmMgKiBOZXcgWW9yaw0KDQo= From nobody Fri Jun 13 00:31:15 2014 Return-Path: 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 735211A0204 for ; Fri, 13 Jun 2014 00:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 XyL637yoAcga for ; Fri, 13 Jun 2014 00:31:12 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 302C11A014E for ; Fri, 13 Jun 2014 00:31:12 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 13 Jun 2014 00:25:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,470,1400050800"; d="scan'208";a="527877181" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by orsmga001.jf.intel.com with ESMTP; 13 Jun 2014 00:31:11 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Jun 2014 00:31:10 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Jun 2014 00:31:10 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.36]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 15:31:08 +0800 From: "Zheng, Kai" To: Wang Weijun Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAAENj7gA== Date: Fri, 13 Jun 2014 07:31:08 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118ED053@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/8b8KLvx6mNfmSR0e3QKVg7P3smE Cc: "kitten@ietf.org" , Simo Sorce , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 07:31:13 -0000 SGkgTWF4LA0KDQpXb3VsZCB5b3UgaGVscCBjbGFyaWZ5IHRoZSBzdXBwb3J0IHNpdHVhdGlvbiBv ciBwbGFuL3NjaGVkdWxlIGluIEpSRS9KREsgZm9yIHRoZSBtZW50aW9uZWQgcHJvdG9jb2wgdHJh bnNpdGlvbiAoczR1MnNlbGYpICsgY29uc3RyYWluZWQgZGVsZWdhdGlvbiAoczR1MnByb3h5KSBp ZiBJJ20gbm90IGNvcnJlY3Q/IFRoYW5rcy4NCg0KUmVnYXJkcywNCkthaQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWmhlbmcsIEthaSANClNlbnQ6IEZyaWRheSwgSnVuZSAx MywgMjAxNCAzOjE2IFBNDQpUbzogJ1NpbW8gU29yY2UnDQpDYzoga2l0dGVuQGlldGYub3JnOyBr cmJkZXZAbWl0LmVkdQ0KU3ViamVjdDogUkU6IFtraXR0ZW5dIFRva2VuIFByZWF1dGggZm9yIEtl cmJlcm9zDQoNCkhpIFNpbW8sDQoNCj4+IGhhdmUgeW91IGNvbnNpZGVyZWQgcHJvdG9jb2wgdHJh bnNpdGlvbiAoczR1MnNlbGYpICsgY29uc3RyYWluZWQgZGVsZWdhdGlvbiAoczR1MnByb3h5KSB0 byBnZXQgdGlja2V0cyBhdCBhbiBhdXRoZW50aWNhdGlvbiBnYXRld2F5IGluc3RlYWQgb2YgYSBu ZXcgcHJlIGF1dGggbWVjaGFuaXNtID8NCg0KWWVzIHdlIHByb3Bvc2VkIGZvciB0aGUgSGFkb29w IGNvbW11bml0eSBhIGNlbnRyYWxpemVkIEF1dGhuICYgQXV0aHogU2VydmVyIChIQVMpIHRoYXQg bWlnaHQgYmUgbGlrZSB0aGUgZ2F0ZXdheSBhcyB5b3UgbWVudGlvbmVkLiBJdCdzIHdpZGVseSBk aXNjdXNzZWQgYW5kIGNvbmZpcm1lZCB0aGF0IGl0IHdvdWxkIGJlIGdyZWF0IHRoZSBzZXJ2ZXIg YWxsb3dzIHBsdWdpbiBvZiBhdXRoZW50aWNhdGlvbiBtb2R1bGUvcHJvdmlkZXIgYnV0IGFsbCBt ZWNoYW5pc21zIG91dHB1dCB0b2tlbi4gU3VyZSBJIGd1ZXNzIGl0J3MgcG9zc2libGUgdG8gdXNl IHRva2VuIHRvIGdvIHRocnUgczR1MnNlbGYgYW5kIHM0dTJwcm94eSBpbiB0aGUgS2VyYmVyb3Mg ZmFjaWxpdHkgYWNyb3NzIHRoZSBlY29zeXN0ZW0gYnV0IGFzIGZhciBhcyBJIGtub3cgSlJFIGp1 c3Qgc3RhcnRzIHRvIHN1cHBvcnQgaXQgZnJvbSBKREs4LiBBbnlob3cgSSB3b3VsZCBjaGVjayB0 aGlzIGFuZCBtYWtlIHN1cmUgaXQncyBhIGRvYWJsZSBvcHRpb24gbm90IGluIHNvIGxvbmcgZnV0 dXJlLg0KDQpBIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGlzOg0KSXMgaXQgcG9zc2libGUgdG8gY29u dGFpbiB0aGUgdG9rZW4gaW4gc2VydmljZSB0aWNrZXQgcmVzdWx0ZWQgZnJvbSBzNHUyc2VsZiBh bmQgczR1MnByb3h5IGFzIGF1dGhvcml6YXRpb24gZGF0YSBzbyB0aGF0IHNlcnZpY2VzIGNhbiBn ZXQgaXQgYXMgcHJvcG9zZWQgaW4gdG9rZW4tcHJlYXV0aD8gTm90ZSBpbiBvdXIgd2FudGVkIHNv bHV0aW9uLCB0b2tlbiBub3QganVzdCBzZXJ2ZXMgZm9yIGF1dGhlbnRpY2F0aW9uLCBidXQgYWxz byBpcyBtZWFudCB0byBiZSBwYXNzZWQgKG9yIHRoZSB0b2tlbiBhdHRyaWJ1dGVzKSB0byBzZXJ2 aWNlIHNpZGUgZm9yIGZpbmUtZ3JhaW5lZCBhdXRob3JpemF0aW9uLg0KDQpUaGFua3MgJiByZWdh cmRzLA0KS2FpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaW1vIFNvcmNl IFttYWlsdG86c2ltb0ByZWRoYXQuY29tXQ0KU2VudDogRnJpZGF5LCBKdW5lIDEzLCAyMDE0IDU6 MzcgQU0NClRvOiBaaGVuZywgS2FpDQpDYzoga2l0dGVuQGlldGYub3JnOyBrcmJkZXZAbWl0LmVk dQ0KU3ViamVjdDogUmU6IFtraXR0ZW5dIFRva2VuIFByZWF1dGggZm9yIEtlcmJlcm9zDQoNCk9u IFR1ZSwgMjAxNC0wNi0xMCBhdCAxMjoxOSArMDAwMCwgWmhlbmcsIEthaSB3cm90ZToNCj4gSGkg YWxsLA0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIG1lbnRpb24gYW4gZWZmb3J0IHJlZ2FyZGluZyBL ZXJiZXJvcyBhbmQgcHJvcG9zZSBhIG5ldyANCj4gS2VyYmVyb3MgcHJlYXV0aCBtZWNoYW5pc20s IHRva2VuLXByZWF1dGguIEJlZm9yZSBkaXZlIGludG8gdGhhdCwgDQo+IHBsZWFzZSBraW5kbHkg YWxsb3cgbWUgdG8gaW50cm9kdWNlLCBtYWlubHkgZm9yIHRoZSBiYWNrZ3JvdW5kIGFuZCANCj4g c2NlbmFyaW8gZm9yIHRoZSBwcm9wb3NhbC4NCj4gDQo+IEknbSBhbiBlbmdpbmVlciBmcm9tIElu dGVsIGFuZCBkZXZlbG9wIGlkZW50aXR5IGFuZCBzZWN1cml0eSByZWxhdGVkIA0KPiBwcm9kdWN0 cy4gVGhlIGN1cnJlbnQgZm9jdXMgaXMgQXBhY2hlIEhhZG9vcCwgYW5kIG91ciBnb2FsIGlzIGVu YWJsaW5nIA0KPiBIYWRvb3AgdG8gc3VwcG9ydCBtb3JlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bXMgYW5kIHByb3ZpZGVycy4NCj4gQ3VycmVudGx5IEhhZG9vcCBvbmx5IHN1cHBvcnRzIEtlcmJl cm9zIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBhcyB0aGUgDQo+IGJ1aWx0LWluIHNlY3VyZWQgb25l IGFuZCBpdCdzIG5vdCBlYXN5IHRvIGFkZCBtb3JlIHNpbmNlIGl0IGludm9sdmVzIA0KPiBjaGFu Z2luZyBpbnRvIG1hbnkgcHJvamVjdHMgb24gdG9wIG9mIGl0IGluIHRoZSBsYXJnZSBlY29zeXN0 ZW0uIFRoZSANCj4gY29tbXVuaXR5IGhhZCBwcm9wb3NlZCBhIHRva2VuIGJhc2VkIGF1dGhlbnRp Y2F0aW9uLCBwbGFubmVkIHRvIGFkZCANCj4gVG9rZW5BdXRoIG1ldGhvZCBmb3IgSGFkb29wIGFu ZCBieSBUb2tlbkF1dGggdGhlbiBhbGwga2luZHMgb2YgDQo+IGF1dGhlbnRpY2F0aW9uIHByb3Zp ZGVycyBjYW4gYmUgc3VwcG9ydGVkIHNpbmNlIHRoZWlyIGF1dGhlbnRpY2F0aW9uIA0KPiByZXN1 bHRzIGNhbiBiZSB3cmFwcGVkIGludG8gdG9rZW4sIGFuZCB0aGUgdG9rZW4gY2FuIGJlIGVtcGxv eWVkIHRvIA0KPiBhdXRoZW50aWNhdGUgdG8gSGFkb29wIGFjcm9zcyB0aGUgZWNvc3lzdGVtLiBU aGUgZWZmb3J0IGlzIHN0aWxsIA0KPiB1bmRlcmdvaW5nLiBDb25zaWRlcmluZyB0aGUgY29tcGxl eGl0eSwgcmlzayBhbmQgZGVwbG95bWVudCBvdmVyaGVhZCANCj4gb2YgdGhpcyBhcHByb2FjaCwg b3VyIHRlYW0gaW52ZXN0aWdhdGUgYW5kIHRoaW5rIG9mIGFub3RoZXIgcG9zc2libGUgDQo+IHNv bHV0aW9uLCBpLmUuIHN1cHBvcnQgdG9rZW4gaW4gS2VyYmVyb3MuIFRoZSBiYXNpYyBpZGVhIGlz IGFsbG93IGVuZCANCj4gdXNlcnMgdG8gYXV0aGVudGljYXRlIHRvIEtlcmJlcm9zIHdpdGggdGhl aXIgdG9rZW5zIGFuZCBvYnRhaW4gDQo+IHRpY2tldHMsIHRoZW4gYWNjZXNzIEhhZG9vcCBzZXJ2 aWNlcyB1c2luZyB0aGUgdGlja2V0cyBhcyBjdXJyZW50IGZsb3cgDQo+IGdvZXMuIFRoZSBQb0Mg d2FzIGFscmVhZHkgZG9uZSwgYW5kIHdlIG1ha2UgaXQgd29yayBzZWFtbGVzc2x5IGZyb20gDQo+ IE1JVCBLZXJiZXJvcyB0byBKYXZhIHdvcmxkIGFuZCBIYWRvb3AuIEhvd2V2ZXIgd2UgdGhpbmsg aXQncyB2ZXJ5IA0KPiBpbXBvcnRhbnQgdG8gZ2V0IHRoZSBrZXkgcG9pbnQgdG9rZW4tcHJlYXV0 aCBiZSByZXZpZXdlZCBieSB5b3UgDQo+IHNlY3VyaXR5IGFuZCBLZXJiZXJvcyBleHBlcnRzLCB0 byBtYWtlIHN1cmUgaXQncyBkZWZpbmVkIGFuZCANCj4gaW1wbGVtZW50ZWQgaW4gY29tcGxpYW5j ZSB3aXRoIHRoZSBleGlzdGluZyBzdGFuZGFyZHMgYW5kIHByb3RvY29scywgDQo+IHdpdGhvdXQg aW52b2x2aW5nIHNlY3VyaXR5IGNyaXRpY2FsIGxlYWtzLiBTbyBwbGVhc2Uga2luZGx5IGdpdmUg eW91ciANCj4gZmVlZGJhY2sgYW5kIHdlIGFwcHJlY2lhdGUgaXQuDQoNCkthaSwNCmhhdmUgeW91 IGNvbnNpZGVyZWQgcHJvdG9jb2wgdHJhbnNpdGlvbiAoczR1MnNlbGYpICsgY29uc3RyYWluZWQg ZGVsZWdhdGlvbiAoczR1MnByb3h5KSB0byBnZXQgdGlja2V0cyBhdCBhbiBhdXRoZW50aWNhdGlv biBnYXRld2F5IGluc3RlYWQgb2YgYSBuZXcgcHJlIGF1dGggbWVjaGFuaXNtID8NCg0KU2ltby4N Cg0KLS0NClNpbW8gU29yY2UgKiBSZWQgSGF0LCBJbmMgKiBOZXcgWW9yaw0KDQo= From nobody Fri Jun 13 00:35:00 2014 Return-Path: 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 C9F631A01F9 for ; Fri, 13 Jun 2014 00:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8TvrBqGfjklT for ; Fri, 13 Jun 2014 00:34:57 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD161A014E for ; Fri, 13 Jun 2014 00:34:57 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5D7YtAm003773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 07:34:56 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5D7YqhB014248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 07:34:53 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5D7YqFm004051; Fri, 13 Jun 2014 07:34:52 GMT Received: from [192.168.10.106] (/114.250.164.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2014 00:34:52 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Wang Weijun In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118ED053@SHSMSX103.ccr.corp.intel.com> Date: Fri, 13 Jun 2014 15:35:04 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <21D762F1-C6F7-49E4-B24B-ADFC6F511F28@oracle.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED053@SHSMSX103.ccr.corp.intel.com> To: "Zheng, Kai" X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OrH206X_EnGQx9noOQdLYGRkw_0 Cc: "kitten@ietf.org" , Simo Sorce , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 07:34:58 -0000 JDK 8 has S4U2self and S4U2proxy, but it hasn't been tested in the real = world. Also, client, service and backend service must be in the same = realm now, since referral is still not supported. --Max On Jun 13, 2014, at 15:31, Zheng, Kai wrote: > Hi Max, >=20 > Would you help clarify the support situation or plan/schedule in = JRE/JDK for the mentioned protocol transition (s4u2self) + constrained = delegation (s4u2proxy) if I'm not correct? Thanks. >=20 > Regards, > Kai >=20 > -----Original Message----- > From: Zheng, Kai=20 > Sent: Friday, June 13, 2014 3:16 PM > To: 'Simo Sorce' > Cc: kitten@ietf.org; krbdev@mit.edu > Subject: RE: [kitten] Token Preauth for Kerberos >=20 > Hi Simo, >=20 >>> have you considered protocol transition (s4u2self) + constrained = delegation (s4u2proxy) to get tickets at an authentication gateway = instead of a new pre auth mechanism ? >=20 > Yes we proposed for the Hadoop community a centralized Authn & Authz = Server (HAS) that might be like the gateway as you mentioned. It's = widely discussed and confirmed that it would be great the server allows = plugin of authentication module/provider but all mechanisms output = token. Sure I guess it's possible to use token to go thru s4u2self and = s4u2proxy in the Kerberos facility across the ecosystem but as far as I = know JRE just starts to support it from JDK8. Anyhow I would check this = and make sure it's a doable option not in so long future. >=20 > A question regarding this: > Is it possible to contain the token in service ticket resulted from = s4u2self and s4u2proxy as authorization data so that services can get it = as proposed in token-preauth? Note in our wanted solution, token not = just serves for authentication, but also is meant to be passed (or the = token attributes) to service side for fine-grained authorization. >=20 > Thanks & regards, > Kai >=20 > -----Original Message----- > From: Simo Sorce [mailto:simo@redhat.com] > Sent: Friday, June 13, 2014 5:37 AM > To: Zheng, Kai > Cc: kitten@ietf.org; krbdev@mit.edu > Subject: Re: [kitten] Token Preauth for Kerberos >=20 > On Tue, 2014-06-10 at 12:19 +0000, Zheng, Kai wrote: >> Hi all, >>=20 >> I would like to mention an effort regarding Kerberos and propose a = new=20 >> Kerberos preauth mechanism, token-preauth. Before dive into that,=20 >> please kindly allow me to introduce, mainly for the background and=20 >> scenario for the proposal. >>=20 >> I'm an engineer from Intel and develop identity and security related=20= >> products. The current focus is Apache Hadoop, and our goal is = enabling=20 >> Hadoop to support more authentication mechanisms and providers. >> Currently Hadoop only supports Kerberos authentication method as the=20= >> built-in secured one and it's not easy to add more since it involves=20= >> changing into many projects on top of it in the large ecosystem. The=20= >> community had proposed a token based authentication, planned to add=20= >> TokenAuth method for Hadoop and by TokenAuth then all kinds of=20 >> authentication providers can be supported since their authentication=20= >> results can be wrapped into token, and the token can be employed to=20= >> authenticate to Hadoop across the ecosystem. The effort is still=20 >> undergoing. Considering the complexity, risk and deployment overhead=20= >> of this approach, our team investigate and think of another possible=20= >> solution, i.e. support token in Kerberos. The basic idea is allow end=20= >> users to authenticate to Kerberos with their tokens and obtain=20 >> tickets, then access Hadoop services using the tickets as current = flow=20 >> goes. The PoC was already done, and we make it work seamlessly from=20= >> MIT Kerberos to Java world and Hadoop. However we think it's very=20 >> important to get the key point token-preauth be reviewed by you=20 >> security and Kerberos experts, to make sure it's defined and=20 >> implemented in compliance with the existing standards and protocols,=20= >> without involving security critical leaks. So please kindly give your=20= >> feedback and we appreciate it. >=20 > Kai, > have you considered protocol transition (s4u2self) + constrained = delegation (s4u2proxy) to get tickets at an authentication gateway = instead of a new pre auth mechanism ? >=20 > Simo. >=20 > -- > Simo Sorce * Red Hat, Inc * New York >=20 From nobody Fri Jun 13 00:49:14 2014 Return-Path: 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 57D131A01CE for ; Fri, 13 Jun 2014 00:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 iNm-Y58bl3D0 for ; Fri, 13 Jun 2014 00:49:11 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 648AA1A016C for ; Fri, 13 Jun 2014 00:49:11 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 13 Jun 2014 00:49:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,470,1400050800"; d="scan'208";a="554899518" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by fmsmga002.fm.intel.com with ESMTP; 13 Jun 2014 00:40:28 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Jun 2014 00:40:27 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.81]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 15:40:25 +0800 From: "Zheng, Kai" To: Wang Weijun Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAAENj7gP//fQ8A//94fGA= Date: Fri, 13 Jun 2014 07:40:25 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118ED070@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED053@SHSMSX103.ccr.corp.intel.com> <21D762F1-C6F7-49E4-B24B-ADFC6F511F28@oracle.com> In-Reply-To: <21D762F1-C6F7-49E4-B24B-ADFC6F511F28@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/W1BAcfn40d9rRHiyWBJBPKH3mo8 Cc: "kitten@ietf.org" , Simo Sorce , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 07:49:13 -0000 Got it, thanks Max. -----Original Message----- From: Wang Weijun [mailto:weijun.wang@oracle.com]=20 Sent: Friday, June 13, 2014 3:35 PM To: Zheng, Kai Cc: kitten@ietf.org; krbdev@mit.edu; Simo Sorce Subject: Re: [kitten] Token Preauth for Kerberos JDK 8 has S4U2self and S4U2proxy, but it hasn't been tested in the real wor= ld. Also, client, service and backend service must be in the same realm now= , since referral is still not supported. --Max On Jun 13, 2014, at 15:31, Zheng, Kai wrote: > Hi Max, >=20 > Would you help clarify the support situation or plan/schedule in JRE/JDK = for the mentioned protocol transition (s4u2self) + constrained delegation (= s4u2proxy) if I'm not correct? Thanks. >=20 > Regards, > Kai >=20 > -----Original Message----- > From: Zheng, Kai > Sent: Friday, June 13, 2014 3:16 PM > To: 'Simo Sorce' > Cc: kitten@ietf.org; krbdev@mit.edu > Subject: RE: [kitten] Token Preauth for Kerberos >=20 > Hi Simo, >=20 >>> have you considered protocol transition (s4u2self) + constrained delega= tion (s4u2proxy) to get tickets at an authentication gateway instead of a n= ew pre auth mechanism ? >=20 > Yes we proposed for the Hadoop community a centralized Authn & Authz Serv= er (HAS) that might be like the gateway as you mentioned. It's widely discu= ssed and confirmed that it would be great the server allows plugin of authe= ntication module/provider but all mechanisms output token. Sure I guess it'= s possible to use token to go thru s4u2self and s4u2proxy in the Kerberos f= acility across the ecosystem but as far as I know JRE just starts to suppor= t it from JDK8. Anyhow I would check this and make sure it's a doable optio= n not in so long future. >=20 > A question regarding this: > Is it possible to contain the token in service ticket resulted from s4u2s= elf and s4u2proxy as authorization data so that services can get it as prop= osed in token-preauth? Note in our wanted solution, token not just serves f= or authentication, but also is meant to be passed (or the token attributes)= to service side for fine-grained authorization. >=20 > Thanks & regards, > Kai >=20 > -----Original Message----- > From: Simo Sorce [mailto:simo@redhat.com] > Sent: Friday, June 13, 2014 5:37 AM > To: Zheng, Kai > Cc: kitten@ietf.org; krbdev@mit.edu > Subject: Re: [kitten] Token Preauth for Kerberos >=20 > On Tue, 2014-06-10 at 12:19 +0000, Zheng, Kai wrote: >> Hi all, >>=20 >> I would like to mention an effort regarding Kerberos and propose a=20 >> new Kerberos preauth mechanism, token-preauth. Before dive into that,=20 >> please kindly allow me to introduce, mainly for the background and=20 >> scenario for the proposal. >>=20 >> I'm an engineer from Intel and develop identity and security related=20 >> products. The current focus is Apache Hadoop, and our goal is=20 >> enabling Hadoop to support more authentication mechanisms and providers. >> Currently Hadoop only supports Kerberos authentication method as the=20 >> built-in secured one and it's not easy to add more since it involves=20 >> changing into many projects on top of it in the large ecosystem. The=20 >> community had proposed a token based authentication, planned to add=20 >> TokenAuth method for Hadoop and by TokenAuth then all kinds of=20 >> authentication providers can be supported since their authentication=20 >> results can be wrapped into token, and the token can be employed to=20 >> authenticate to Hadoop across the ecosystem. The effort is still=20 >> undergoing. Considering the complexity, risk and deployment overhead=20 >> of this approach, our team investigate and think of another possible=20 >> solution, i.e. support token in Kerberos. The basic idea is allow end=20 >> users to authenticate to Kerberos with their tokens and obtain=20 >> tickets, then access Hadoop services using the tickets as current=20 >> flow goes. The PoC was already done, and we make it work seamlessly=20 >> from MIT Kerberos to Java world and Hadoop. However we think it's=20 >> very important to get the key point token-preauth be reviewed by you=20 >> security and Kerberos experts, to make sure it's defined and=20 >> implemented in compliance with the existing standards and protocols,=20 >> without involving security critical leaks. So please kindly give your=20 >> feedback and we appreciate it. >=20 > Kai, > have you considered protocol transition (s4u2self) + constrained delegati= on (s4u2proxy) to get tickets at an authentication gateway instead of a new= pre auth mechanism ? >=20 > Simo. >=20 > -- > Simo Sorce * Red Hat, Inc * New York >=20 From nobody Fri Jun 13 01:08:55 2014 Return-Path: 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 739781A025F for ; Fri, 13 Jun 2014 01:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 o8xN014wKxcC for ; Fri, 13 Jun 2014 01:08:42 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3630D1A02EA for ; Fri, 13 Jun 2014 01:08:11 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 13 Jun 2014 01:08:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,470,1400050800"; d="scan'208";a="556803104" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga002.jf.intel.com with ESMTP; 13 Jun 2014 01:07:52 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Jun 2014 01:07:52 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Jun 2014 01:07:52 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.81]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 16:07:50 +0800 From: "Zheng, Kai" To: Nathaniel McCallum Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQK5hzIAAC7IIlAAABX8AABnJeLw Date: Fri, 13 Jun 2014 08:07:50 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118ED099@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> <8D5F7E3237B3ED47B84CF187BB17B666118D8E14@SHSMSX103.ccr.corp.intel.com> <1402498324.2955.2.camel@ipa.example.com> In-Reply-To: <1402498324.2955.2.camel@ipa.example.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OlfueAHWf3NeflQS7XDWb7EdtcM Cc: "kitten@ietf.org" , "Jiang, Weihua" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 08:08:46 -0000 TmF0aGFuaWVsLA0KDQpZZXMgSSBsaWtlIHRoZSBpZGVhIGFuZCBob3BlZnVsbHkgdG9rZW4tcHJl YXV0aCBtZWNoYW5pc20gY2FuIGJlbmVmaXQgZnJvbSBpdC4gVGhhbmtzLg0KDQpSZWdhcmRzLA0K S2FpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOYXRoYW5pZWwgTWNDYWxs dW0gW21haWx0bzpucG1jY2FsbHVtQHJlZGhhdC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdW5l IDExLCAyMDE0IDEwOjUyIFBNDQpUbzogWmhlbmcsIEthaQ0KQ2M6IEdyZWcgSHVkc29uOyBraXR0 ZW5AaWV0Zi5vcmc7IGtyYmRldkBtaXQuZWR1OyBKaWFuZywgV2VpaHVhDQpTdWJqZWN0OiBSZTog W2tpdHRlbl0gVG9rZW4gUHJlYXV0aCBmb3IgS2VyYmVyb3MNCg0KT24gV2VkLCAyMDE0LTA2LTEx IGF0IDA4OjE1ICswMDAwLCBaaGVuZywgS2FpIHdyb3RlOg0KPiBIaSBHcmVnLA0KPiANCj4gVGhh bmtzIGZvciB5b3VyIHZhbHVhYmxlIGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucyENCj4gDQo+IDEu IFllcyB5b3UncmUgcmlnaHQgSSdtIHRha2luZyB0aGUgT1RQIGFwcHJvYWNoIGFuZCB1c2UgdGhl IEZBU1QgYXJtb3IgDQo+IGtleSBhcyB0aGUgcmVwbHkga2V5LiBBcyBtZW50aW9uZWQgaW4gdGhl IHByb3Bvc2FsIHdlIHN1Z2dlc3QgUEtJTklUIA0KPiBiZSBkZXBsb3llZCBhbG9uZyB3aXRoIHRo aXMgbWVjaGFuaXNtLCBBbmQgY2xpZW50IHVzZXMgUEtJTklUIA0KPiBhbm9ueW1vdXMgdG8gb2J0 YWluIHRoZSBhcm1vciB0aWNrZXQuIEl0IGRvZXNuJ3QgcHJvdmlkZSBtdXR1YWwgYXV0aGVudGlj YXRpb24gc2luY2Ugb25seSBLREMgaXMgYXV0aGVudGljYXRlZCB0byBjbGllbnQgd2l0aCB0aGUg Y29uZmlndXJlZCBjZXJ0aWZpY2F0ZSBvZiBLREMgYW5kIGNsaWVudCBkb2Vzbid0IGR1ZSB0byBs YWNraW5nIG9mIGNlcnRpZmljYXRlIGFzIHRvIGF2b2lkIHRoZSBkZXBsb3ltZW50IG92ZXJoZWFk IGluIG91ciBzb2x1dGlvbi4gU28gcHJvdGVjdGluZyB0aGUgdG9rZW4gaGVyZSBpbiBBUy1SRVEg ZXhjaGFuZ2UgbWFpbmx5IGRlcGVuZHMgb24gdGhlIEZBU1QgdHVubmVsIGFuZCBjbGllbnQgc2hv dWxkIGJlIGNhcmVmdWwgYWJvdXQgdGhlIGFybW9yIHRpY2tldC4NCg0KWW91IG1heSBiZSBpbnRl cmVzdGVkIGluIHRoaXMgcHJvcG9zYWw6DQpodHRwOi8vbWFpbG1hbi5taXQuZWR1L3BpcGVybWFp bC9rcmJkZXYvMjAxNC1NYXkvMDExOTU4Lmh0bWwNCg0KTmF0aGFuaWVsDQoNCg== From nobody Fri Jun 13 05:41:24 2014 Return-Path: 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 522381B2849 for ; Fri, 13 Jun 2014 05:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 04n5ySc2mfz0 for ; Fri, 13 Jun 2014 05:41:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05C1A04CA for ; Fri, 13 Jun 2014 05:41:19 -0700 (PDT) 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 s5DCfIMx013324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 08:41:18 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DCfHNR003814; Fri, 13 Jun 2014 08:41:17 -0400 Message-ID: <1402663277.22737.60.camel@willson.usersys.redhat.com> From: Simo Sorce To: "Zheng, Kai" Date: Fri, 13 Jun 2014 08:41:17 -0400 In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> 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/10PyXnd1ioPat7_h6_0XbzOeNrI Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:41:22 -0000 On Fri, 2014-06-13 at 07:16 +0000, Zheng, Kai wrote: > Hi Simo, > > >> have you considered protocol transition (s4u2self) + constrained > delegation (s4u2proxy) to get tickets at an authentication gateway > instead of a new pre auth mechanism ? > > Yes we proposed for the Hadoop community a centralized Authn & Authz > Server (HAS) that might be like the gateway as you mentioned. It's > widely discussed and confirmed that it would be great the server > allows plugin of authentication module/provider but all mechanisms > output token. Sure I guess it's possible to use token to go thru > s4u2self and s4u2proxy in the Kerberos facility across the ecosystem > but as far as I know JRE just starts to support it from JDK8. Anyhow I > would check this and make sure it's a doable option not in so long > future. You need to modify something anyway, constrained delegation sound like a better way than trying to devise a whole new pre-auth plugin. > A question regarding this: > Is it possible to contain the token in service ticket resulted from > s4u2self and s4u2proxy as authorization data so that services can get > it as proposed in token-preauth? Note in our wanted solution, token > not just serves for authentication, but also is meant to be passed (or > the token attributes) to service side for fine-grained authorization. Well, theorethically it should be possible to ad AD data in the ticket before the s4u2proxy call and the KDC should just preserve it. However you should only transmit the authorization data, not the whole token, otherwise you destroy every single security property of Kerberos. I can't see any krb admin as accepting something like that. Simo. -- Simo Sorce * Red Hat, Inc * New York From greg@wind.enjellic.com Fri Jun 13 02:11:06 2014 Return-Path: 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 5CAD11A035B for ; Fri, 13 Jun 2014 02:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HK_NAME_DR=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 lVG7Vmc6rdY0 for ; Fri, 13 Jun 2014 02:11:04 -0700 (PDT) Received: from wind.enjellic.com (wind.enjellic.com [76.10.64.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA21A030E for ; Fri, 13 Jun 2014 02:11:04 -0700 (PDT) Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id s5D9Axsi022461; Fri, 13 Jun 2014 04:11:00 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id s5D9AxVa022460; Fri, 13 Jun 2014 04:10:59 -0500 Date: Fri, 13 Jun 2014 04:10:59 -0500 From: "Dr. Greg Wettstein" Message-Id: <201406130910.s5D9AxVa022460@wind.enjellic.com> In-Reply-To: "Zheng, Kai" "Token Preauth for Kerberos" (Jun 10, 12:19pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: "Zheng, Kai" , "kitten@ietf.org" , "krbdev@mit.edu" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Fri, 13 Jun 2014 04:11:00 -0500 (CDT) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/w1JVXsBkhtj21U-Z-JTh7Ds4dU8 X-Mailman-Approved-At: Sun, 15 Jun 2014 21:25:52 -0700 Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gw@idfusion.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:09:47 -0000 On Jun 10, 12:19pm, "Zheng, Kai" wrote: } Subject: Token Preauth for Kerberos > Hi all, Good morning Kai, I hope the end of you week is going well. > I would like to mention an effort regarding Kerberos and propose a > new Kerberos preauth mechanism, token-preauth. Before dive into that, > please kindly allow me to introduce, mainly for the background and > scenario for the proposal. > > I'm an engineer from Intel and develop identity and security related > products. The current focus is Apache Hadoop, and our goal is > enabling Hadoop to support more authentication mechanisms and > providers. Currently Hadoop only supports Kerberos authentication > method as the built-in secured one and it's not easy to add more > since it involves changing into many projects on top of it in the > large ecosystem. The community had proposed a token based > authentication, planned to add TokenAuth method for Hadoop and by > TokenAuth then all kinds of authentication providers can be > supported since their authentication results can be wrapped into > token, and the token can be employed to authenticate to Hadoop > across the ecosystem. The effort is still undergoing. Considering > the complexity, risk and deployment overhead of this approach, our > team investigate and think of another possible solution, > i.e. support token in Kerberos. The basic idea is allow end users to > authenticate to Kerberos wit! h their tokens and obtain tickets, > then access Hadoop services using the tickets as current flow > goes. The PoC was already done, and we make it work seamlessly from > MIT Kerberos to Java world and Hadoop. However we think it's very > important to get the key point token-preauth be reviewed by you > security and Kerberos experts, to make sure it's defined and > implemented in compliance with the existing standards and protocols, > without involving security critical leaks. So please kindly give > your feedback and we appreciate it. > > The proposal - Kerberos token-preauth > This proposes to add another preauthentication mechanism similar to > OTP and PKINIT for Kerberos, based on Kerberos preauthentication > framework and FAST tunnel. It allows 3rd party token in JWT format > like OAuth bearer token can be used as credential to authenticate to > KDC for a normal principal instead of user password. When using the > token to request a tgt, the user name or other attributes claimed in > the token must match the target Kerberos principal. PKI is used to > establish the trust relationship between 3rd party token issuer and > KDC. According to configured certificate and public/private keys KDC > decrypt and verify the token, and determines to issue ticket or not > according to configured policy. The token itself will be wrapped > into ticket as new authorization data and carried on to application > server side. The tgt and derived service ticket resulted from token > are not in much difference except the contained token and work > exactly as normally. Besides that in applicatio! n servers, token > can be extracted from service ticket and employed further to do > fine-grained authorization since the token can contain rich identity > attributes. > > POC implementation > > 1. We implement a token-preauth plugin for MIT Kerberos like OTP > one and it does all the necessary work that should be done for > Kerberos itself in both client side and KDC side. We need update > krb5.conf and kdc.conf to use and enable the mechanism. The plugin is > a so module and can be separately installed/deployed. To protect token > between client and KDC in KDC-REQ/KDC-REP exchanges, FAST must be > used, therefore we suggest PKINIT be deployed also. .. [ much material deleted ] ... At a conceptual level we did a great deal of work on this back in 2007. Look through the archives of the Kerberos development list for 'One-Time-Identification'. Unfortunately at that time no one really thought authorization was all that important and there was a fair amount of contempt in the community for using the Kerberos supplied authorization data. OTI was an outgrowth of work which we started doing in 2001 on the issue of intrinsic definition of identity. In that work the notion of authorization for a service naturally falls out of the identity definition model. If you GOOGLE around a bit you will find a presentation we did at a Kerberos/AFS conference at Ann Arbor on how this was applied to Kerberos. We implemented OTI as a pre-authentication method and it was a fairly natural fit. The concept was roughly a bearer token model where the service authorization identity was used in concert with the user password to generate a one time encryption of the service authorization token. We've since taken that work into the trusted system domain and it continues to prove itself in combination with software/hardware attestation. > Regards, > Kai We've actually had ongoing conversations with your organization. If you are interested we could take an additional conversation offline. Have a good weekend. Greg }-- End of excerpt from "Zheng, Kai" As always, Dr. G.W. Wettstein, Ph.D. IDfusion.org 4206 N. 19th Ave. Unified health identity architecture. Fargo, ND 58102 PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@idfusion.org ------------------------------------------------------------------------------ "My thoughts on trusting Open-Source? A quote I once saw said it best: 'Remember, Amateurs built the ark. Professionals built the Titanic.' Perhaps most significantly the ark was one guy, there were no doubt committees involved with the Titanic project." -- Dr. G.W. Wettstein Resurrection From nobody Mon Jun 16 22:35:28 2014 Return-Path: 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 47C101A0271 for ; Mon, 16 Jun 2014 22:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ohn6k2pn0nxL for ; Mon, 16 Jun 2014 22:35:26 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC51A0266 for ; Mon, 16 Jun 2014 22:35:26 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 16 Jun 2014 22:35:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,492,1400050800"; d="scan'208";a="556597356" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by fmsmga002.fm.intel.com with ESMTP; 16 Jun 2014 22:35:25 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 22:35:25 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 22:35:24 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.209]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 13:35:24 +0800 From: "Zheng, Kai" To: Simo Sorce Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAACyy6gADKjG2g Date: Tue, 17 Jun 2014 05:35:23 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> In-Reply-To: <1402663277.22737.60.camel@willson.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/o9td7tclABXBUYX8fbKuY26AqkY Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 05:35:27 -0000 Pj4gWW91IG5lZWQgdG8gbW9kaWZ5IHNvbWV0aGluZyBhbnl3YXksIGNvbnN0cmFpbmVkIGRlbGVn YXRpb24gc291bmQgbGlrZSBhIGJldHRlciB3YXkgdGhhbiB0cnlpbmcgdG8gZGV2aXNlIGEgd2hv bGUgbmV3IHByZS1hdXRoIHBsdWdpbi4NCkFzIGZhciBhcyBJIGtub3cgczR1MnNlbGYgJiBzNHUy cHJveHkgcGx1cyBjb250cmFpbmVkIGRlbGVnYXRpb24gYXJlIGZyb20gTVMgYW5kIEknbSBub3Qg c3VyZSB3ZSBjb3VsZCBtb2RpZnkgaXQgYXMgd2UgbmVlZC4gQSBuZXcgdG9rZW4tcHJlYXV0aCBi YXNlZCBvbiBleGlzdGluZyBLZXJiZXJvcyBhbmQgZnJhbWV3b3JrIGlzIG1vcmUgcHJlZmVycmVk IGZvciB1cyBzaW5jZSB0aGUgcGx1Z2luIGlzIGVhc3kgdG8gZGVwbG95LCBhbHNvIHdlIGJlbGll dmUgdGhlIG1lY2hhbmlzbSB1c2luZyBKV1QgdG9rZW4gd2lsbCBvcGVuIHRoZSBkb29yIHRvIGlu dGVncmF0ZSBLZXJiZXJvcyB3aXRoIE9BdXRoLg0KDQo+Pkhvd2V2ZXIgeW91IHNob3VsZCBvbmx5 IHRyYW5zbWl0IHRoZSBhdXRob3JpemF0aW9uIGRhdGEsIG5vdCB0aGUgd2hvbGUgdG9rZW4sIG90 aGVyd2lzZSB5b3UgZGVzdHJveSBldmVyeSBzaW5nbGUgc2VjdXJpdHkgcHJvcGVydHkgb2YgS2Vy YmVyb3MuDQo+PkkgY2FuJ3Qgc2VlIGFueSBrcmIgYWRtaW4gYXMgYWNjZXB0aW5nIHNvbWV0aGlu ZyBsaWtlIHRoYXQuDQpZZXMgSSBhZ3JlZS4gQXMgZGlzY3Vzc2VkIHdpdGggR3JlZyBhbmQgYWxz byBzYWlkIGhlcmUgaW4gbXkgcHJldmlvdXMgZW1haWwsIHdlIHdpbGwgbm90IHBhc3MgdGhlIHRv a2VuIGl0c2VsZiB0byBzZXJ2aWNlLCBpbnN0ZWFkIHRva2VuIGF0dHJpYnV0ZXMgb3IgdGhlIGRl cml2YXRpb24gdGhhdCBjYW4ndCBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIEtEQy4gDQoN ClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay4NCg0KUmVnYXJkcywNCkthaQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2ltbyBTb3JjZSBbbWFpbHRvOnNpbW9AcmVkaGF0LmNv bV0gDQpTZW50OiBGcmlkYXksIEp1bmUgMTMsIDIwMTQgODo0MSBQTQ0KVG86IFpoZW5nLCBLYWkN CkNjOiBraXR0ZW5AaWV0Zi5vcmc7IGtyYmRldkBtaXQuZWR1DQpTdWJqZWN0OiBSZTogW2tpdHRl bl0gVG9rZW4gUHJlYXV0aCBmb3IgS2VyYmVyb3MNCg0KT24gRnJpLCAyMDE0LTA2LTEzIGF0IDA3 OjE2ICswMDAwLCBaaGVuZywgS2FpIHdyb3RlOg0KPiBIaSBTaW1vLA0KPiANCj4gPj4gaGF2ZSB5 b3UgY29uc2lkZXJlZCBwcm90b2NvbCB0cmFuc2l0aW9uIChzNHUyc2VsZikgKyBjb25zdHJhaW5l ZA0KPiBkZWxlZ2F0aW9uIChzNHUycHJveHkpIHRvIGdldCB0aWNrZXRzIGF0IGFuIGF1dGhlbnRp Y2F0aW9uIGdhdGV3YXkgDQo+IGluc3RlYWQgb2YgYSBuZXcgcHJlIGF1dGggbWVjaGFuaXNtID8N Cj4gDQo+IFllcyB3ZSBwcm9wb3NlZCBmb3IgdGhlIEhhZG9vcCBjb21tdW5pdHkgYSBjZW50cmFs aXplZCBBdXRobiAmIEF1dGh6IA0KPiBTZXJ2ZXIgKEhBUykgdGhhdCBtaWdodCBiZSBsaWtlIHRo ZSBnYXRld2F5IGFzIHlvdSBtZW50aW9uZWQuIEl0J3MgDQo+IHdpZGVseSBkaXNjdXNzZWQgYW5k IGNvbmZpcm1lZCB0aGF0IGl0IHdvdWxkIGJlIGdyZWF0IHRoZSBzZXJ2ZXIgDQo+IGFsbG93cyBw bHVnaW4gb2YgYXV0aGVudGljYXRpb24gbW9kdWxlL3Byb3ZpZGVyIGJ1dCBhbGwgbWVjaGFuaXNt cyANCj4gb3V0cHV0IHRva2VuLiBTdXJlIEkgZ3Vlc3MgaXQncyBwb3NzaWJsZSB0byB1c2UgdG9r ZW4gdG8gZ28gdGhydSANCj4gczR1MnNlbGYgYW5kIHM0dTJwcm94eSBpbiB0aGUgS2VyYmVyb3Mg ZmFjaWxpdHkgYWNyb3NzIHRoZSBlY29zeXN0ZW0gDQo+IGJ1dCBhcyBmYXIgYXMgSSBrbm93IEpS RSBqdXN0IHN0YXJ0cyB0byBzdXBwb3J0IGl0IGZyb20gSkRLOC4gQW55aG93IEkgDQo+IHdvdWxk IGNoZWNrIHRoaXMgYW5kIG1ha2Ugc3VyZSBpdCdzIGEgZG9hYmxlIG9wdGlvbiBub3QgaW4gc28g bG9uZyANCj4gZnV0dXJlLg0KDQpZb3UgbmVlZCB0byBtb2RpZnkgc29tZXRoaW5nIGFueXdheSwg Y29uc3RyYWluZWQgZGVsZWdhdGlvbiBzb3VuZCBsaWtlIGEgYmV0dGVyIHdheSB0aGFuIHRyeWlu ZyB0byBkZXZpc2UgYSB3aG9sZSBuZXcgcHJlLWF1dGggcGx1Z2luLg0KDQo+IEEgcXVlc3Rpb24g cmVnYXJkaW5nIHRoaXM6DQo+IElzIGl0IHBvc3NpYmxlIHRvIGNvbnRhaW4gdGhlIHRva2VuIGlu IHNlcnZpY2UgdGlja2V0IHJlc3VsdGVkIGZyb20gDQo+IHM0dTJzZWxmIGFuZCBzNHUycHJveHkg YXMgYXV0aG9yaXphdGlvbiBkYXRhIHNvIHRoYXQgc2VydmljZXMgY2FuIGdldCANCj4gaXQgYXMg cHJvcG9zZWQgaW4gdG9rZW4tcHJlYXV0aD8gTm90ZSBpbiBvdXIgd2FudGVkIHNvbHV0aW9uLCB0 b2tlbiANCj4gbm90IGp1c3Qgc2VydmVzIGZvciBhdXRoZW50aWNhdGlvbiwgYnV0IGFsc28gaXMg bWVhbnQgdG8gYmUgcGFzc2VkIChvciANCj4gdGhlIHRva2VuIGF0dHJpYnV0ZXMpIHRvIHNlcnZp Y2Ugc2lkZSBmb3IgZmluZS1ncmFpbmVkIGF1dGhvcml6YXRpb24uDQoNCldlbGwsIHRoZW9yZXRo aWNhbGx5IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBhZCBBRCBkYXRhIGluIHRoZSB0aWNrZXQg YmVmb3JlIHRoZSBzNHUycHJveHkgY2FsbCBhbmQgdGhlIEtEQyBzaG91bGQganVzdCBwcmVzZXJ2 ZSBpdC4NCkhvd2V2ZXIgeW91IHNob3VsZCBvbmx5IHRyYW5zbWl0IHRoZSBhdXRob3JpemF0aW9u IGRhdGEsIG5vdCB0aGUgd2hvbGUgdG9rZW4sIG90aGVyd2lzZSB5b3UgZGVzdHJveSBldmVyeSBz aW5nbGUgc2VjdXJpdHkgcHJvcGVydHkgb2YgS2VyYmVyb3MuDQpJIGNhbid0IHNlZSBhbnkga3Ji IGFkbWluIGFzIGFjY2VwdGluZyBzb21ldGhpbmcgbGlrZSB0aGF0Lg0KDQpTaW1vLg0KDQotLQ0K U2ltbyBTb3JjZSAqIFJlZCBIYXQsIEluYyAqIE5ldyBZb3JrDQoNCg== From nobody Mon Jun 16 23:30:28 2014 Return-Path: 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 276AF1A0299 for ; Mon, 16 Jun 2014 23:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 21ZjeVKHpdX5 for ; Mon, 16 Jun 2014 23:30:24 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 107091A0289 for ; Mon, 16 Jun 2014 23:30:24 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 16 Jun 2014 23:30:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,492,1400050800"; d="scan'208";a="549034599" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by fmsmga001.fm.intel.com with ESMTP; 16 Jun 2014 23:30:22 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 23:30:22 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 23:30:22 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.209]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 14:30:20 +0800 From: "Zheng, Kai" To: "gw@idfusion.org" , "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: Token Preauth for Kerberos Thread-Index: AQHPhudj/v5P0th/QSGCBpa/sVINTZt0znOA Date: Tue, 17 Jun 2014 06:30:20 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118F0A10@SHSMSX103.ccr.corp.intel.com> References: "Zheng, Kai" "Token Preauth for Kerberos" (Jun 10, 12:19pm) <201406130910.s5D9AxVa022460@wind.enjellic.com> In-Reply-To: <201406130910.s5D9AxVa022460@wind.enjellic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/goItY4hIHemoq_1G5Rm_f7u6jdo Cc: "Jiang, Weihua" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 06:30:26 -0000 Hi Greg, Thanks for letting know this and I did read your proposal. Identity token i= s a good point. Per my understanding, I noticed the following points, plea= se feel free to clarify or correct. 1. Looks like you modified the Kerberos implementation along with backend p= rincipal store to make it work. Our approach is a pure plugin for MIT Kerbe= ros and we tried to avoid=20 changing into the main programs and make sure it's easy to deploy the mecha= nism. 2. You introduced the identity token in a private format with corresponding= key generation algorithms. We propose to use JWT token since it's well def= ined in JWT/JWA/JWE/JWS etc.,=20 and also implemented well for OAuth2 related profiles. This allows the prop= osal to be easier defined based on the existing specs, and also enables to = integrate Kerberos with OAuth. 3. Looks like your identity token was tightly coupled with specific KDC. We= would prefer decouple the both and establish the trust relationship betwee= n token issuer and KDC via PKI. Token can be issued without knowing any KDC (its IP). Token domains/subject= s are mapped into Kerberos realms via defined token attributes or plugined = mapping provider. 4. In low level: you passed the token in authorization data in the AS-REQ exchange. Our work= based on pre-authentication framework and FAST tunnel, tokens are passed a= s PADATA in the FAST tunnel. This allows the mechanism can work together with other preauth mechanism li= ke PKINIT and make use of them for their provide facilities. Though, I'm wondering if it's possible to align the both efforts if the com= munity would. Still in drafting, we would prefer something like following: 1. define token-preauth mechanism using JWT token format; 2. define OAuth token for Kerberos profile based on token-preauth, that all= ows OAuth token work flow can integrate with existing Kerberos authenticate= d systems as resource servers. Considering to align with your work, one possible approach would be somethi= ng like following: 1. define token-preauth mechanism using opaque token, only if the token can= be verified, encrypted, and token attributes can be extracted. As to how t= o verify, encrypt, and extract attributes, it leaves for specific token provider to define and implement; 2. Based on token-preauth with opaque token, we define JWT token provider; 3. Based on JWT token provider, we define OAuth token support. At first glance looks token-preauth with opaque token is more general and u= seful. However I'm not sure if it's easily defined and implemented. I guess= the community can decide which way=20 should we go. Regards, Kai -----Original Message----- From: Dr. Greg Wettstein [mailto:greg@wind.enjellic.com]=20 Sent: Friday, June 13, 2014 5:11 PM To: Zheng, Kai; kitten@ietf.org; krbdev@mit.edu Subject: Re: Token Preauth for Kerberos On Jun 10, 12:19pm, "Zheng, Kai" wrote: } Subject: Token Preauth for Kerberos > Hi all, Good morning Kai, I hope the end of you week is going well. > I would like to mention an effort regarding Kerberos and propose a new=20 > Kerberos preauth mechanism, token-preauth. Before dive into that,=20 > please kindly allow me to introduce, mainly for the background and=20 > scenario for the proposal. > > I'm an engineer from Intel and develop identity and security related=20 > products. The current focus is Apache Hadoop, and our goal is enabling=20 > Hadoop to support more authentication mechanisms and providers.=20 > Currently Hadoop only supports Kerberos authentication method as the=20 > built-in secured one and it's not easy to add more since it involves=20 > changing into many projects on top of it in the large ecosystem. The=20 > community had proposed a token based authentication, planned to add=20 > TokenAuth method for Hadoop and by TokenAuth then all kinds of=20 > authentication providers can be supported since their authentication=20 > results can be wrapped into token, and the token can be employed to=20 > authenticate to Hadoop across the ecosystem. The effort is still=20 > undergoing. Considering the complexity, risk and deployment overhead=20 > of this approach, our team investigate and think of another possible=20 > solution, i.e. support token in Kerberos. The basic idea is allow end=20 > users to authenticate to Kerberos wit! h their tokens and obtain=20 > tickets, then access Hadoop services using the tickets as current flow=20 > goes. The PoC was already done, and we make it work seamlessly from=20 > MIT Kerberos to Java world and Hadoop. However we think it's very=20 > important to get the key point token-preauth be reviewed by you=20 > security and Kerberos experts, to make sure it's defined and=20 > implemented in compliance with the existing standards and protocols,=20 > without involving security critical leaks. So please kindly give your=20 > feedback and we appreciate it. >=20 > The proposal - Kerberos token-preauth > This proposes to add another preauthentication mechanism similar to=20 > OTP and PKINIT for Kerberos, based on Kerberos preauthentication=20 > framework and FAST tunnel. It allows 3rd party token in JWT format=20 > like OAuth bearer token can be used as credential to authenticate to=20 > KDC for a normal principal instead of user password. When using the=20 > token to request a tgt, the user name or other attributes claimed in=20 > the token must match the target Kerberos principal. PKI is used to=20 > establish the trust relationship between 3rd party token issuer and=20 > KDC. According to configured certificate and public/private keys KDC=20 > decrypt and verify the token, and determines to issue ticket or not=20 > according to configured policy. The token itself will be wrapped into=20 > ticket as new authorization data and carried on to application server=20 > side. The tgt and derived service ticket resulted from token are not=20 > in much difference except the contained token and work exactly as=20 > normally. Besides that in applicatio! n servers, token can be=20 > extracted from service ticket and employed further to do fine-grained=20 > authorization since the token can contain rich identity attributes. > > POC implementation > > 1. We implement a token-preauth plugin for MIT Kerberos like OTP one=20 > and it does all the necessary work that should be done for Kerberos=20 > itself in both client side and KDC side. We need update krb5.conf and=20 > kdc.conf to use and enable the mechanism. The plugin is a so module=20 > and can be separately installed/deployed. To protect token between=20 > client and KDC in KDC-REQ/KDC-REP exchanges, FAST must be used,=20 > therefore we suggest PKINIT be deployed also. .. [ much material deleted ] ... At a conceptual level we did a great deal of work on this back in 2007. Lo= ok through the archives of the Kerberos development list for 'One-Time-Iden= tification'. Unfortunately at that time no one really thought authorizatio= n was all that important and there was a fair amount of contempt in the com= munity for using the Kerberos supplied authorization data. OTI was an outgrowth of work which we started doing in 2001 on the issue of= intrinsic definition of identity. In that work the notion of authorizatio= n for a service naturally falls out of the identity definition model. If yo= u GOOGLE around a bit you will find a presentation we did at a Kerberos/AFS= conference at Ann Arbor on how this was applied to Kerberos. We implemented OTI as a pre-authentication method and it was a fairly natur= al fit. The concept was roughly a bearer token model where the service aut= horization identity was used in concert with the user password to generate = a one time encryption of the service authorization token. We've since taken that work into the trusted system domain and it continues= to prove itself in combination with software/hardware attestation. > Regards, > Kai We've actually had ongoing conversations with your organization. If you ar= e interested we could take an additional conversation offline. Have a good weekend. Greg }-- End of excerpt from "Zheng, Kai" As always, Dr. G.W. Wettstein, Ph.D. IDfusion.org 4206 N. 19th Ave. Unified health identity architecture. Fargo, ND 58102 PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@idfusion.org ---------------------------------------------------------------------------= --- "My thoughts on trusting Open-Source? A quote I once saw said it best: 'Remember, Amateurs built the ark. Professionals built the Titanic= .' Perhaps most significantly the ark was one guy, there were no doubt co= mmittees involved with the Titanic project." -- Dr. G.W. Wettstein Resurrection From nobody Tue Jun 17 05:43:37 2014 Return-Path: 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 92CEB1A0375 for ; Tue, 17 Jun 2014 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 9XrS-_QI_B0m for ; Tue, 17 Jun 2014 05:43:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id F353C1A036B for ; Tue, 17 Jun 2014 05:43:32 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5HChU4m012014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Jun 2014 08:43:30 -0400 Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5HChTg6029226; Tue, 17 Jun 2014 08:43:29 -0400 Message-ID: <1403009009.22737.129.camel@willson.usersys.redhat.com> From: Simo Sorce To: "Zheng, Kai" Date: Tue, 17 Jun 2014 08:43:29 -0400 In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> 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.27 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/V2aXz2JGGWUsqVVM66TC8mDKP_Y Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 12:43:34 -0000 On Tue, 2014-06-17 at 05:35 +0000, Zheng, Kai wrote: > >> You need to modify something anyway, constrained delegation sound > like a better way than trying to devise a whole new pre-auth plugin. > As far as I know s4u2self & s4u2proxy plus contrained delegation are > from MS and I'm not sure we could modify it as we need. A new > token-preauth based on existing Kerberos and framework is more > preferred for us since the plugin is easy to deploy, also we believe > the mechanism using JWT token will open the door to integrate Kerberos > with OAuth. I think AD data can be added with s4u2self/s4u2proxy as well, what other modifications do you have in mind ? > >>However you should only transmit the authorization data, not the > whole token, otherwise you destroy every single security property of > Kerberos. > >>I can't see any krb admin as accepting something like that. > Yes I agree. As discussed with Greg and also said here in my previous > email, we will not pass the token itself to service, instead token > attributes or the derivation that can't be used to authenticate with > KDC. Do you have a standardized AD element in mind, or are you going to define a new one ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Mon Jun 30 09:40:05 2014 Return-Path: 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 4716E1A03A8 for ; Mon, 30 Jun 2014 09:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qE6WllWZAFUu for ; Mon, 30 Jun 2014 09:40:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF90E1A03A1 for ; Mon, 30 Jun 2014 09:40:02 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5UGe1po013022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Jun 2014 16:40:02 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5UGe0Pg003973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jun 2014 16:40:01 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5UGe0WW019763 for ; Mon, 30 Jun 2014 16:40:00 GMT Received: from [10.159.102.187] (/10.159.102.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Jun 2014 09:40:00 -0700 Message-ID: <53B192F2.2060707@oracle.com> Date: Mon, 30 Jun 2014 10:40:18 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/YVkBtPryzEOb_IIn7yDN04TeWPw Subject: [kitten] IETF 90 - Draft Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:40:04 -0000 Please provide any additions or updates to the draft agenda posted here: http://www.ietf.org/proceedings/90/agenda/agenda-90-kitten by Monday, July 14th. Shawn. -- kitten co-chair From nobody Mon Jun 30 12:46:49 2014 Return-Path: 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 172C51A0A96; Mon, 30 Jun 2014 12:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NVz2gZ1lfs07; Mon, 30 Jun 2014 12:46:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F891A0A8C; Mon, 30 Jun 2014 12:46:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140630194645.30577.48140.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 12:46:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/msGaJxdhEAU3TsBV66X7eLZLUX8 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 19:46:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-08.txt Pages : 9 Date : 2014-06-30 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/