From mpeck@mitre.org Mon Jan 6 12:26:45 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 64E181AE205 for ; Mon, 6 Jan 2014 12:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 oEd-M18822EL for ; Mon, 6 Jan 2014 12:26:41 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A539A1AE1FD for ; Mon, 6 Jan 2014 12:26:41 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A4B901F05BB for ; Mon, 6 Jan 2014 15:26:32 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8A5F01F041D for ; Mon, 6 Jan 2014 15:26:32 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.36]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Mon, 6 Jan 2014 15:26:32 -0500 From: "Peck, Michael A" To: "kitten@ietf.org" Thread-Topic: Moving forward with draft-ietf-kitten-aes-cts-hmac-sha2 Thread-Index: AQHPCx2WFQI85VLH+06sM72V8pZqMQ== Date: Mon, 6 Jan 2014 20:26:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [128.29.194.119] Content-Type: multipart/alternative; boundary="_000_CED4D260D7E7mpeckmitreorg_" MIME-Version: 1.0 Subject: [kitten] Moving forward with draft-ietf-kitten-aes-cts-hmac-sha2 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, 06 Jan 2014 20:26:45 -0000 --_000_CED4D260D7E7mpeckmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi - I believe two primary issues have been raised with the AES and SHA-2 encryp= tion type drafts: ciphertext stealing vs padding, and IV options. 1: CTS vs. CBC with PKCS7 padding We first submitted draft-ietf-kitten-aes-cts-hmac-sha2 (uses CTS mode, also= known as CBC mode with ciphertext stealing), then submitted draft-ietf-kit= ten-aes-cbc-hmac-sha2 (uses CBC mode with PKCS7 padding). A consensus call decided on CBC mode with PKCS7 padding, but immediately af= terwards Paul Miller from Microsoft stated that CBC with PKCS7 padding coul= d cause compatibility problems. Based on that feedback, I suggest we go wi= th CTS mode =96 are there any objections? 2: Initialization vector RFC 3961/3962 sets the formal CBC IV to the cipherstate (the next-to-last c= iphertext block of the previous message) - (it's my understanding the purp= ose of the cipher state is to enforce message sequencing) - and sets the fi= rst block of plaintext to a 128-bit random value (called a confounder). Th= e cipherstate is not sent with the message since it can be implicitly infer= red from the ciphertext of the previous message. The confounder (first blo= ck of plaintext) plays the cryptographic role of the IV. Draft-ietf-kitten-aes-cts-hmac-sha2 currently sets the CBC IV to a 128-bit = nonce XORed with the cipher state (in this draft, the cipher state is curre= ntly the previous message's 128-bit nonce). The nonce is sent in the clear= along with the ciphertext and the MAC. We followed this approach to be al= igned with the CTS definition found in the NIST Special Publication 800-38A= Addendum, which treats the IV as a parameter to be passed into the encrypt= and decrypt operations (and expects it to meet the required properties of = a CBC IV). (Side note: Currently the draft states that the MAC is computed over the no= nce and ciphertext. Upon another look, I'm thinking the MAC should instead= be computed over the IV and ciphertext, so that message reorderings are de= tected by the MAC verification.) Some have indicated interest in sticking with the RFC 3961/3962 confounder = approach. I'd like to suggest some options to choose from: Option 1: Define separate Kerberos enctypes for each of the two IV approaches. Define the cipherstate to be the next-to-last ciphertext block of the previ= ous message (like in RFC 3961/3962). If the confounder approach is being used (as signaled by the enctype), don'= t include an explicit nonce. Set the CBC IV =3D cipherstate. Set the firs= t block of plaintext to a 128-bit nonce. Omit the first block of plaintext= from the decrypt operation's plaintext output. ciphertext || MAC is transmitted. If the explicit nonce approach is being used (as signaled by the enctype), = set the CBC IV =3D cipherstate XOR nonce. nonce || ciphertext || MAC is transmitted. The MAC is computed over the IV || ciphertext in both cases. This option seems to provide the ability to deployers to decide which IV ap= proaches they're comfortable with (both or just one) through the allowed en= ctypes. Option 2: Define the cipher state to be the next-to-last ciphertext block of the prev= ious message (like in RFC 3961/3962). If the sender chooses the confounder approach, set the explicit nonce field= to the cipher state, and set the first block of plaintext to a 128-bit non= ce (confounder). If the sender chooses to use an explicit nonce, set the explicit nonce fiel= d to a 128-bit nonce, and set the first block of plaintext to the ciphersta= te. Either way, the CBC IV is set to the explicit nonce field. The MAC is computed over the explicit nonce field || ciphertext. Explicit nonce field || cipher text || MAC is transmitted. The recipient always omits the first block of plaintext from the decrypt op= eration's plaintext output. The recipient needs to make sure the cipherstate transmitted with the messa= ge is consistent with the previous message's ciphertext. Two downsides of this approach: It adds an unnecessary 128 bits to each message. It doesn't easily allow deployers to decide which IV techniques to allow ba= sed on policy considerations. Option 3: Pick one IV approach. Thanks, Mike --_000_CED4D260D7E7mpeckmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <333EBF7E5B9CDE41850138904A617039@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
Hi -

I believe two primary issues have been raised with the AES and SHA-2 e= ncryption type drafts: ciphertext stealing vs padding, and IV options.

1: CTS vs. CBC with PKCS7 padding

We first submitted draft-ietf-kitten-aes-cts-hmac-sha2 (uses CTS mode,= also known as CBC mode with ciphertext stealing), then submitted draft-iet= f-kitten-aes-cbc-hmac-sha2 (uses CBC mode with PKCS7 padding).

A consensus call decided on CBC mode with PKCS7 padding, but immediate= ly afterwards Paul Miller from Microsoft stated that CBC with PKCS7 padding= could cause compatibility problems.  Based on that feedback, I sugges= t we go with CTS mode =96 are there any objections?

2: Initialization vector

RFC 3961/3962 sets the formal CBC IV to the cipherstate (the next-to-l= ast ciphertext block of the previous message)  - (it's my understandin= g the purpose of the cipher state is to enforce message sequencing) - and s= ets the first block of plaintext to a 128-bit random value (called a confounder).  The cipherstate is not s= ent with the message since it can be implicitly inferred from the ciphertex= t of the previous message.  The confounder (first block of plaintext) = plays the cryptographic role of the IV.

Draft-ietf-kitten-aes-cts-hmac-sha2 currently sets the CBC IV to a 128= -bit nonce XORed with the cipher state (in this draft, the cipher state is = currently the previous message's 128-bit nonce).  The nonce is sent in= the clear along with the ciphertext and the MAC.  We followed this approach to be aligned with the CTS de= finition found in the NIST Special Publication 800-38A Addendum, which trea= ts the IV as a parameter to be passed into the encrypt and decrypt operatio= ns (and expects it to meet the required properties of a CBC IV).  
(Side note: Currently the draft states that the MAC is computed over t= he nonce and ciphertext.  Upon another look, I'm thinking the MAC shou= ld instead be computed over the IV and ciphertext, so that message reorderi= ngs are detected by the MAC verification.)

Some have indicated interest in sticking with the RFC 3961/3962 confou= nder approach.  
I'd like to suggest some options to choose from:

Option 1:

Define separate Kerberos enctypes for each of the two IV approaches.&n= bsp;

Define the cipherstate to be the next-to-last ciphertext block of the = previous message (like in RFC 3961/3962).

If the confounder approach is being used (as signaled by the enctype),= don't include an explicit nonce.  Set the CBC IV =3D cipherstate. &nb= sp;Set the first block of plaintext to a 128-bit nonce.  Omit the firs= t block of plaintext from the decrypt operation's plaintext output.  
ciphertext || MAC is transmitted.

If the explicit nonce approach is being used (as signaled by the encty= pe), set the CBC IV =3D cipherstate XOR nonce.  
nonce || ciphertext || MAC is transmitted.

The MAC is computed over the IV || ciphertext in both cases.

This option seems to provide the ability to deployers to decide which = IV approaches they're comfortable with (both or just one) through the allow= ed enctypes.

Option 2:

Define the cipher state to be the next-to-last ciphertext block of the= previous message (like in RFC 3961/3962).

If the sender chooses the confounder approach, set the explicit nonce = field to the cipher state, and set the first block of plaintext to a 128-bi= t nonce (confounder).

If the sender chooses to use an explicit nonce, set the explicit nonce= field to a 128-bit nonce, and set the first block of plaintext to the ciph= erstate.

Either way, the CBC IV is set to the explicit nonce field.
The MAC is computed over the explicit nonce field || ciphertext.

Explicit nonce field || cipher text || MAC is transmitted.

The recipient always omits the first block of plaintext from the decry= pt operation's plaintext output.
The recipient needs to make sure the cipherstate transmitted with the = message is consistent with the previous message's ciphertext.

Two downsides of this approach:
It adds an unnecessary 128 bits to each message.
It doesn't easily allow deployers to decide which IV techniques to all= ow based on policy considerations.

Option 3:

Pick one IV approach.

Thanks,
Mike
--_000_CED4D260D7E7mpeckmitreorg_-- From rtroll@google.com Mon Jan 6 16:09:50 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 8BF9F1AE381 for ; Mon, 6 Jan 2014 16:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 qmwjTRTFlf_Q for ; Mon, 6 Jan 2014 16:09:48 -0800 (PST) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC8F1AE38B for ; Mon, 6 Jan 2014 16:09:48 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id cy11so19253821qeb.41 for ; Mon, 06 Jan 2014 16:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0i/uXwkbPPOfec00RkLEHxlIAoNgAqKBV4qtX8MBkRk=; b=UWSWEYa/HVLQ4AYGgEiopwPatcmtjf2ED54OUii/Z5dJ6N2dm21kWYzd4uaaQNAJPT ulY780NaH9XhEBDaJ/qbZcJj+tQCHuD/h3GRHkya45y/dx/2FFaY/pMMciU4ThpqjgQK 6kzcqcjByWMLce6v1K/zZN7vF+LZFw4HhXIPU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0i/uXwkbPPOfec00RkLEHxlIAoNgAqKBV4qtX8MBkRk=; b=L/aQvDrfe5NYMJubszDp5bTkR8A4q+iJ9hYjpAdPoYE9EPyFwCBce4lVAFUaFROWu3 r4MoYKl8ehqBqENT+HjywyKzlErqlwazxd208BpV+G6tPIaEP3BTI3Ezbvr8/5XQ1hnL zr2vAKgAU2MWqi7pPui4cGsKahRhHCC9IModaQYsy0v9tcAFb/ZQik1GiokrNf6IVO22 aiOOc/epGziczqaoWHiCxox7C32J9C9qqjO6XgIu5pwDgFs9Gk/SYGwYS9k3/2dxAiZl 2/A3oYMWYxCJLnrd7W+gujeVJDanmymL1nlbSDZoeu/5I6zx572dtpHI6OBMsNwyseLD WjIg== X-Gm-Message-State: ALoCoQmTqHOuff90TrJ4TRNPnaIyv4gijuuLNdUYbeDEs5k6SoHQzZcOeR8AhzxaeRWOdB0kfgqfmEBFpWCZhUdIglQP7WJibApIQFdaY7JFfflpUV0Mr+ZGCoJhFML84tuCMopyUwKLmJ/72VefCaaZ6MGPUkkmkbVDlcaNKwpFsR763JiI2iaEx4fLkQwdj/VKLt3c3YWs MIME-Version: 1.0 X-Received: by 10.224.103.129 with SMTP id k1mr184180671qao.77.1389053379408; Mon, 06 Jan 2014 16:09:39 -0800 (PST) Received: by 10.229.92.132 with HTTP; Mon, 6 Jan 2014 16:09:39 -0800 (PST) In-Reply-To: References: <52AE9A65.1010700@oracle.com> Date: Mon, 6 Jan 2014 16:09:39 -0800 Message-ID: From: Ryan Troll To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=047d7b66f74b417ad204ef56319a Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 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, 07 Jan 2014 00:09:50 -0000 --047d7b66f74b417ad204ef56319a Content-Type: text/plain; charset=UTF-8 > > > MAJOR: > > * Removing the GS2-header (which was done in revision -11) also removed > the ability for the client to specify an authorization identity. If the > lack of an authorization identity is acceptable (and I suspect it is not > for some), then the document needs to state these mechanisms do not support > authz-id. The loss of the authz-id is a problem for us. Last year we discussed the use case with the list, came to the conclusion that what our use case needed was access to the authz-id; and agreed that we'd pull it from the GS2-header. Now that the GS2-header is gone, it would be beneficial to provide a standard, but optional, way for clients to provide the authz-id to the service. This would ensure compatibility across services which require the authz-id; while not requiring it for *all* SASL-OAuth clients. The original proposal had been to define a reserved keyword ("user") which could be part of the initial client response. Should this be re-added? -R --047d7b66f74b417ad204ef56319a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

MAJOR:

* Removing the GS2-header (which was done in revision -11) also removed the= ability for the client to specify an authorization identity. =C2=A0If the = lack of an authorization identity is acceptable (and I suspect it is not fo= r some), then the document needs to state these mechanisms do not support a= uthz-id.


The loss of the authz-id is a problem fo= r us. =C2=A0Last year we discussed the use case with the list, came to the = conclusion that what our use case needed was access to the authz-id; and ag= reed that we'd pull it from the GS2-header.

Now that the GS2-header is gone, it would be beneficial= to provide a standard, but optional, way for clients to provide the authz-= id to the service. =C2=A0This would ensure compatibility across services wh= ich require the authz-id; while not requiring it for *all* SASL-OAuth clien= ts.

The original proposal had been to define a reserved key= word ("user") which could be part of the initial client response.= =C2=A0Should this be re-added?

-R
=C2= =A0
--047d7b66f74b417ad204ef56319a-- From wmills@yahoo-inc.com Mon Jan 6 16:24: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 19BF91AE281 for ; Mon, 6 Jan 2014 16:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.22 X-Spam-Level: X-Spam-Status: No, score=-14.22 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 89OWakNeoi0e for ; Mon, 6 Jan 2014 16:24:13 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3665F1ADAEA for ; Mon, 6 Jan 2014 16:24:13 -0800 (PST) Received: from GQ1-EX10-CAHT11.y.corp.yahoo.com (gq1-ex10-caht11.corp.gq1.yahoo.com [10.87.93.110]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s070NpRQ059127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Jan 2014 16:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1389054232; bh=zFi5vWrJjlMtevbqhb0gHKyIyRO93uCsDy30U9nXHUU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=F3r/XDOlTZ81UoWdhXP/YfMgJg1tRjz2g+DXt25WN5wroJ1/SjhPNTEcDnzOBU28w I6orRivfiL2G876FUR9jzvLALG3+G8P8EESfe6ehxKMlcuR+JtvSEfB3VV9G7cXH57 waVPPaL0NWFJbbaCNw/inQnJngXYFjY5sjYwGSHA= Received: from omp1020.mail.ne1.yahoo.com (98.138.89.164) by GQ1-EX10-CAHT11.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 6 Jan 2014 16:23:50 -0800 Received: (qmail 65687 invoked by uid 1000); 7 Jan 2014 00:23:49 -0000 Received: (qmail 69942 invoked by uid 60001); 7 Jan 2014 00:23:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1389054229; bh=2Uc/VUjK4lfAxDduL37PvrPzWEK5NcVXNdhZYhmY84k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D5sRvxNVIpkerNpvpNMYHJxHSjrUK15PAqaUDr/aGd3vEHlSMTzGvE75RgKXadxQjDnNc/mo/mvSar1VAq8a34yiGBORq7DI9eKNS0Kuyc+ZAGqgoIFYRYulmyFSp8x9b60e2/iUhVjwDquRYwDPdVuSFOilGzVaxdGOU6wKUUw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MgoDO4s9hO9Oi0vjbnYEmzn7L+rXMGlAK/qz4/eoCszHee+C/kxqzAMv7cEEgmQKsBR5T8VSFCOTnWflGUblApWNps2vqMRJIFIDk/l3/DfU1MJaESQisW7tbi8ugY4sV58e+aKdFAfH+aR+90ovRkyF1/xP78w2Y6g0t+2W9sE=; X-YMail-OSG: VeTbLYEVM1nMToP3L4k712yxPS3AP9kn.r6DthIorScT2lD Zb6nLl7neYek9c9RTYTWa2Yaup60iedTAwf8uhxHjP8QxMVT1jkVi3dnfF6i WgUunPD3syPLblBlF7ygoQwuVbrkmIQbfsVT1VxLZU62tDIrhsHxEnbTDon9 YTaEcP8nues1K4bImZwsEkE8MwO5twYiAMKj6BxD4QQmXCC1n4mNRTF.xIqN nvbBsGBrY0Pi05yOq.32FTl5pnJOSvBUB7YwSvGxlARU9JQKuX4tYuQytb5j eAqt7N7gQ2kVAVCghCWvTmAt1 Received: from [209.131.62.115] by web125601.mail.ne1.yahoo.com via HTTP; Mon, 06 Jan 2014 16:23:49 PST X-Rocket-MIMEInfo: 002.001, Tm93IHRoYXQgaXQncyBub3QgZHVwbGljYXRpbmcgdGhlIGdzMiBzdHVmZiBpdCBtYWtlcyBzb21lIHNlbnNlLsKgIEl0IGNhbiBiZSBlYXNpbHkgYWRkZWQgYmFjay4KCgpBbnkgb2JqZWN0aW9uIHRvIGFkZGluZyB0aGUgInVzZXIiIGZpZWxkIGJhY2sgaW4_CgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGxzCiJQYXJhbm9pZCIgWWFob28hCgoKCgoKT24gTW9uZGF5LCBKYW51YXJ5IDYsIDIwMTQgNDoxMCBQTSwgUnlhbiBUcm9sbCA8cnRyb2xsQGcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <52AE9A65.1010700@oracle.com> Message-ID: <1389054229.19390.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Mon, 6 Jan 2014 16:23:49 -0800 From: Bill Mills To: Ryan Troll , "Matt Miller (mamille2)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-174937204-1389054229=:19390" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 054231002 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 00:24:15 -0000 ---1981468715-174937204-1389054229=:19390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Now that it's not duplicating the gs2 stuff it makes some sense.=A0 It can = be easily added back.=0A=0A=0AAny objection to adding the "user" field back= in?=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------=0AWilliam= J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Monday, January 6, 2014 4= :10 PM, Ryan Troll wrote:=0A =0A=0A>MAJOR:=0A>=0A>* R= emoving the GS2-header (which was done in revision -11) also removed the ab= ility for the client to specify an authorization identity. =A0If the lack o= f an authorization identity is acceptable (and I suspect it is not for some= ), then the document needs to state these mechanisms do not support authz-i= d.=0A=0A=0AThe loss of the authz-id is a problem for us. =A0Last year we di= scussed the use case with the list, came to the conclusion that what our us= e case needed was access to the authz-id; and agreed that we'd pull it from= the GS2-header.=0A=0ANow that the GS2-header is gone, it would be benefici= al to provide a standard, but optional, way for clients to provide the auth= z-id to the service. =A0This would ensure compatibility across services whi= ch require the authz-id; while not requiring it for *all* SASL-OAuth client= s.=0A=0AThe original proposal had been to define a reserved keyword ("user"= ) which could be part of the initial client response. =A0Should this be re-= added?=0A=0A=0A-R=0A=A0=0A=0A______________________________________________= _=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/li= stinfo/kitten ---1981468715-174937204-1389054229=:19390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Now that = it's not duplicating the gs2 stuff it makes some sense.  It can be eas= ily added back.

A= ny objection to adding the "user" field back in?
 = ;
-bill


--------------------------------
William J= . Mills
"Paranoid" Yahoo!



On Monday, January 6, 2014 4:10 PM, Ryan Troll <rtrol= l@googlers.com> wrote:

=0AMAJOR:
=0A=
=0A* Removing the GS2-header (which was done in revision= -11) also removed the ability for the client to specify an authorization i= dentity.  If the lack of an authorization identity is acceptable (and = I suspect it is not for some), then the document needs to state these mecha= nisms do not support authz-id.
=0A


The loss of the authz-id is a problem f= or us.  Last year we discussed the use case with the list, came to the= conclusion that what our use case needed was access to the authz-id; and a= greed that we'd pull it from the GS2-header.
=0A

Now that the GS2-header is gone, it would be beneficial to pro= vide a standard, but optional, way for clients to provide the authz-id to t= he service.  This would ensure compatibility across services which req= uire the authz-id; while not requiring it for *all* SASL-OAuth clients.=0A

The original proposal had been to d= efine a reserved keyword ("user") which could be part of the initial client= response.  Should this be re-added?

=
-R
 
=0A

______________________________= _________________
Kitten mailing list
<= a shape=3D"rect" ymailto=3D"mailto:Kitten@ietf.org" href=3D"mailto:Kitten@i= etf.org">Kitten@ietf.org
https://www.i= etf.org/mailman/listinfo/kitten


=
---1981468715-174937204-1389054229=:19390-- From wmills@yahoo-inc.com Mon Jan 6 16:25:50 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 153B41ADAEA for ; Mon, 6 Jan 2014 16:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 m3RxX7wbKrzP for ; Mon, 6 Jan 2014 16:25:47 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 29AA21AE387 for ; Mon, 6 Jan 2014 16:25:47 -0800 (PST) Received: from GQ1-EX10-CAHT01.y.corp.yahoo.com (gq1-ex10-caht01.corp.gq1.yahoo.com [10.73.118.80]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s070P9Bm059737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Jan 2014 16:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1389054310; bh=Cwx+V2UTbWVqGGQax9MDFnXCfql2AO/BOBRcIThhzB0=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=vnWgHvw4HTpQefZoPctSMYqH9qA1ih0gBRyI0r7udLs2I8y3hqy9u+Ax/HtqP3LFm hyLAQJbeHk3D4JV3xbVXzu5s3LgB66qFpaTIFFyerMWpkj9MOYIxeTyKp7A7Jc7T2B FLBN5gP5pCs0AYu3/yFXmG2EoEXazmqECYDAfycw= Received: from omp1021.mail.ne1.yahoo.com (98.138.89.165) by GQ1-EX10-CAHT01.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 6 Jan 2014 16:25:09 -0800 Received: (qmail 58952 invoked by uid 1000); 7 Jan 2014 00:25:08 -0000 Received: (qmail 33728 invoked by uid 60001); 7 Jan 2014 00:25:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1389054308; bh=YE/Ui88/S0mlgzDiMG9XwsqeKMjAzC/J72gaubAoLao=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WDuLlTi7BI2/jAW/ZXdSv6hefcdKaz7TU6In4CunlquEe6dADVrd+SC5enVUhh2QqFHeoqg1o0RRag1+eNVRyQnlNcV5g3HwMzlYVoC6rpXlAifb0TcmFAMwsWBYA+SlIoq9BkXDOBlB9frxsEXY43D9N+fHslICfYWk9r4HgCc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AQX5LKaJbSaDXS78BrIa+MxqX+ClQz/F7ZNUPHIxbOk92mOjpVqJf+iGHkyKM/A7Txo3IwKv0+UH6ntGrEwN4TbiKW339XvWpN7wMV6kqTIaK5I4MWRLceFMcUvg8jIKiJdqZDYTEbn8oduLbrS9wDXSkscUmm+h8bx9TosFz+U=; X-YMail-OSG: 17z7r9QVM1kD1Yf8VrKMDgBgtCs2ScvSuqS7iIir9aZ6jml GLCduXRgNSEHba5AHwQbF3fWTbqMQwTQmDeKl_wwA9jW43Wdb3hjUYOpFVa2 XAKlPugBo3Ld3.32Ci4_xz8OoswNrWC3j0d6rGqOsa8wUG3AGXRXwkYK9Ezk KwdZLkIwLi3ZCnLPyINXlguh3o5vALAIqeBuc_bAbEHWbp_9vo94MLAiqtHE prmqtHfx0P8OcvKyY9Qzfkkmb36vo6atwjGfGesVcgXrvGspAR2Lgcxoy7Yx qn5hev8IwAZXZDBu6xjLLMmIQ Received: from [209.131.62.115] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 06 Jan 2014 16:25:08 PST X-Rocket-MIMEInfo: 002.001, VGhhdCBzYWlkLCB5b3VyIGV4dGFudCBpbXBsZW1lbnRhdGlvbiBtaWdodCBhcmd1ZSBmb3IgbGVhdmluZyB0aGUgR1MyIGhlYWRlciBpbiB0aGVyZS4uLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCgpPbiAsIEJpbGwgTWlsbHMgPHdtaWxsc0B5YWhvby1pbmMuY29tPiB3cm90ZToKIApOb3cgdGhhdCBpdCdzIG5vdCBkdXBsaWNhdGluZyB0aGUgZ3MyIHN0dWZmIGl0IG1ha2VzIHNvbWUgc2Vuc2UuwqABMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <52AE9A65.1010700@oracle.com> <1389054229.19390.YahooMailNeo@web125601.mail.ne1.yahoo.com> Message-ID: <1389054308.10730.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 6 Jan 2014 16:25:08 -0800 From: Bill Mills To: Ryan Troll , "Matt Miller (mamille2)" In-Reply-To: <1389054229.19390.YahooMailNeo@web125601.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-956567121-1389054308=:10730" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 054310000 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 00:25:50 -0000 ---685807438-956567121-1389054308=:10730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That said, your extant implementation might argue for leaving the GS2 heade= r in there...=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A------------------------------= --=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn , Bill Mills = wrote:=0A =0ANow that it's not duplicating the gs2 s= tuff it makes some sense.=A0 It can be easily added back.=0A=0A=0AAny objec= tion to adding the "user" field back in?=0A=0A=A0=0A-bill=0A=0A=0A=0A------= --------------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A= =0A=0A=0AOn Monday, January 6, 2014 4:10 PM, Ryan Troll wrote:=0A =0A=0A>MAJOR:=0A>=0A>* Removing the GS2-header (which was done= in revision -11) also removed the ability for the client to specify an aut= horization identity. =A0If the lack of an authorization identity is accepta= ble (and I suspect it is not for some), then the document needs to state th= ese mechanisms do not support authz-id.=0A=0A=0AThe loss of the authz-id is= a problem for us. =A0Last year we discussed the use case with the list, ca= me to the conclusion that what our use case needed was access to the authz-= id; and agreed that we'd pull it from the GS2-header.=0A=0ANow that the GS2= -header is gone, it would be beneficial to provide a standard, but optional= , way for clients to provide the authz-id to the service. =A0This would ens= ure compatibility across services which require the authz-id; while not req= uiring it for *all* SASL-OAuth clients.=0A=0AThe original proposal had been= to define a reserved keyword ("user") which could be part of the initial c= lient response. =A0Should this be re-added?=0A=0A=0A-R=0A=A0=0A=0A_________= ______________________________________=0AKitten mailing list=0AKitten@ietf.= org=0Ahttps://www.ietf.org/mailman/listinfo/kitten ---685807438-956567121-1389054308=:10730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That said= , your extant implementation might argue for leaving the GS2 header in ther= e...

 
-bill


=
--------------------------------
William J. Mills
"Paranoid" Yahoo!<= br>



On , Bill Mill= s <wmills@yahoo-inc.com> wrote:
Now that it's not duplicating the gs2 s= tuff it makes some sense.  It can be easily added back.

Any ob= jection to adding the "user" field back in?
=
 
-bill


--------------------------------
William J. Mi= lls
"Paranoid" Yahoo!



On Monday,= January 6, 2014 4:10 PM, Ryan Troll <rtroll@googlers.com> wrote:

=0AMAJOR:
=0A<= br clear=3D"none">=0A* Removing the GS2-header (which was done in revision = -11) also removed the ability for the client to specify an authorization id= entity.  If the lack of an authorization identity is acceptable (and I= suspect it is not for some), then the document needs to state these mechan= isms do not support authz-id.
=0A

=

The loss of the authz-id is a problem fo= r us.  Last year we discussed the use case with the list, came to the = conclusion that what our use case needed was access to the authz-id; and ag= reed that we'd pull it from the GS2-header.
=0A

Now that the GS2-header is gone, it would be beneficial to prov= ide a standard, but optional, way for clients to provide the authz-id to th= e service.  This would ensure compatibility across services which requ= ire the authz-id; while not requiring it for *all* SASL-OAuth clients.=0A

The original proposal had been to de= fine a reserved keyword ("user") which could be part of the initial client = response.  Should this be re-added?

<= div>-R
 
=0A

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


=


---685807438-956567121-1389054308=:10730-- From shawn.emery@oracle.com Tue Jan 7 10:17: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 C63101AE103 for ; Tue, 7 Jan 2014 10:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 GP6Efh_UfsAj for ; Tue, 7 Jan 2014 10:17:29 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C82991AE104 for ; Tue, 7 Jan 2014 10:17:28 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s07IHIAe022661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Jan 2014 18:17:19 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s07IHHjt011139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jan 2014 18:17:18 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s07IHHNt000541 for ; Tue, 7 Jan 2014 18:17:17 GMT Received: from [10.159.114.14] (/10.159.114.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Jan 2014 10:17:17 -0800 Message-ID: <52CC4504.2080107@oracle.com> Date: Tue, 07 Jan 2014 11:18:44 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20131203 Thunderbird/17.0.6 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: ucsinet21.oracle.com [156.151.31.93] Subject: [kitten] IETF 89 - 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: Tue, 07 Jan 2014 18:17:31 -0000 Please provide any agenda items for a possible London session. Please submit these topics to the list or co-chairs no later than 1/14. Shawn. -- kitten co-chair From ghudson@mit.edu Tue Jan 7 11:54:34 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 AED711AE156 for ; Tue, 7 Jan 2014 11:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 Wz7x34ddKfGG for ; Tue, 7 Jan 2014 11:54:33 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2C71ADF98 for ; Tue, 7 Jan 2014 11:54:33 -0800 (PST) X-AuditID: 12074425-f79906d000000cf9-b0-52cc5b70c881 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id E0.26.03321.07B5CC25; Tue, 7 Jan 2014 14:54:24 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s07JsNrV004674; Tue, 7 Jan 2014 14:54:23 -0500 Received: from [18.101.8.147] (vpn-18-101-8-147.mit.edu [18.101.8.147]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s07JsLnZ001967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jan 2014 14:54:22 -0500 Message-ID: <52CC5B6D.5050502@mit.edu> Date: Tue, 07 Jan 2014 14:54:21 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Peck, Michael A" , "kitten@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrFsQfSbIYHsTl8XRzatYLE7fes7s wOSxZMlPJo+3DVfZA5iiuGxSUnMyy1KL9O0SuDLObWtnLpjLXzH74j6WBsZlPF2MnBwSAiYS b680sUHYYhIX7q0Hsrk4hARmM0mc7r3AAuFsYJSY/38CO4RzmElieu8qpi5GDg5eATWJdU2G IN0sAqoS+98cYQax2QSUJQ6e/cYCYosKhEnc/b+WEcTmFRCUODnzCQtIq4iAj8TDVa4gYWEB X4mOK5eZQGwhAW2Jq1smgB3EKaAjcXnOeTCbWUBPYsf1X6wQtrxE89bZzBMYBWYhmToLSdks JGULGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBIUpu4vqDsYJh5QOMQpw MCrx8N5QOxMkxJpYVlyZe4hRkoNJSZQ3IgooxJeUn1KZkVicEV9UmpNafIhRgoNZSYRXPAwo x5uSWFmVWpQPk5LmYFES573FYR8kJJCeWJKanZpakFoEk5Xh4FCS4M0CGSpYlJqeWpGWmVOC kGbi4AQZzgM0vBKkhre4IDG3ODMdIn+KUVFKnNcIJCEAksgozYPrhaWRV4ziQK8I8yaDVPEA UxBc9yugwUxAg0PjToEMLklESEk1MLZcDnFrMPAIyvxgemrb38PnQuorPryu17DRi67YO4s3 /vfs9x+fK/xQlXKYlpXi+YLztLVijnf87bD6edPbll+cNKNWoPnk/SMbPjEuz7Qx/Hh/3bNJ p/hYSvpc2pZe2DrxRzf3nr2FXhcCRCo5WF/L/q7WdVRR8vuRzDvdScvpENOzySsn71BiKc5I NNRiLipOBADSn3DV/gIAAA== Subject: Re: [kitten] Moving forward with draft-ietf-kitten-aes-cts-hmac-sha2 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, 07 Jan 2014 19:54:34 -0000 On 01/06/2014 03:26 PM, Peck, Michael A wrote: > A consensus call decided on CBC mode with PKCS7 padding, but immediately > afterwards Paul Miller from Microsoft stated that CBC with PKCS7 padding > could cause compatibility problems. Based on that feedback, I suggest > we go with CTS mode – are there any objections? I think we are only likely to get consensus if we use CTS mode, yes. > Some have indicated interest in sticking with the RFC 3961/3962 > confounder approach. Yes. I would summarize the advantages and disadvantages as follows: + eliminates most of the short input special casing + allows more code reuse with existing RFC 3962 implementations + disguises the state of a compromised PRNG (if the enctype implementation code is not also compromised) - less consistent with SP 800-38A addendum - slightly slower I believe that the first and second advantages outweigh the disadvantages. > I'd like to suggest some options to choose from: I am strongly opposed to defining multiple new enctypes for explicit-IV vs. confounder, or a single enctype which tries to do both. Doing that would have basically all of the disadvantages and none of the advantages. I don't think explicit-IV vs. confounder is a "policy" decision in any reasonable sense. So I favor option 3. Within that option, I would favor a confounder over explicit-IV, but I would rather do explicit-IV than both. > Define the cipherstate to be the next-to-last ciphertext block of the previous message (like in RFC 3961/3962). I am in favor of this change because it allows more code reuse. If we were designing from scratch, I would suggest using the encrypted confounder as the cipherstate. (Realistically, almost nothing uses cipherstate, so while we need a story for it that works as well as RFC 3961/3962, we don't necessarily need to nitpick the fine cryptographic advantages of one approach over another.) From cantor.2@osu.edu Tue Jan 7 12:00: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 3B5071AE1F1 for ; Tue, 7 Jan 2014 12:00:30 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 2onhwqKPeC2n for ; Tue, 7 Jan 2014 12:00:28 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id CD9081AE19F for ; Tue, 7 Jan 2014 12:00:26 -0800 (PST) Received: from mail108-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 7 Jan 2014 20:00:17 +0000 Received: from mail108-va3 (localhost [127.0.0.1]) by mail108-va3-R.bigfish.com (Postfix) with ESMTP id 9BEA01601AA; Tue, 7 Jan 2014 20:00:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.210; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf03; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h1b1cn1b1bi1155h) Received-SPF: pass (mail108-va3: domain of osu.edu designates 164.107.81.210 as permitted sender) client-ip=164.107.81.210; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf03 ; cio-krc-pf03 ; Received: from mail108-va3 (localhost.localdomain [127.0.0.1]) by mail108-va3 (MessageSwitch) id 1389124815394606_19295; Tue, 7 Jan 2014 20:00:15 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.248]) by mail108-va3.bigfish.com (Postfix) with ESMTP id E2F544C004E; Tue, 7 Jan 2014 20:00:14 +0000 (UTC) Received: from cio-krc-pf03 (164.107.81.210) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 7 Jan 2014 20:00:14 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf03 (Postfix) with ESMTPS id 168DBC005F; Tue, 7 Jan 2014 15:00:14 -0500 (EST) 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; Tue, 7 Jan 2014 15:00:11 -0500 From: "Cantor, Scott" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] IETF 89 - Agenda Items Thread-Index: AQHPC9S4LLIJe/HP/kmtIc8afCvujJp5rnaA Date: Tue, 7 Jan 2014 20:00:10 +0000 Message-ID: References: <52CC4504.2080107@oracle.com> In-Reply-To: <52CC4504.2080107@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C6298B874F5C5458601BEBFDE61CB1C@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [kitten] IETF 89 - 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: Tue, 07 Jan 2014 20:00:30 -0000 On 1/7/14, 1:18 PM, "Shawn M Emery" wrote: > >Please provide any agenda items for a possible London session. Please >submit these topics to the list or co-chairs no later than 1/14. Not sure it's an agenda item, but I need some assistance moving saml-ec to last call. I'll have a new draft up this week that replaces the last draft reference now that eap-naming is done. -- Scott From kaduk@mit.edu Tue Jan 7 19:45: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 E3D9F1AE2B6 for ; Tue, 7 Jan 2014 19:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 1utMVayiCCiO for ; Tue, 7 Jan 2014 19:45:10 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0F1AE2B5 for ; Tue, 7 Jan 2014 19:45:10 -0800 (PST) X-AuditID: 12074425-f79906d000000cf9-48-52ccc9bc7389 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FE.49.03321.CB9CCC25; Tue, 7 Jan 2014 22:45:00 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s083ixY4026448; Tue, 7 Jan 2014 22:45:00 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s083iv4n032375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jan 2014 22:44:59 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s083ivqm004491; Tue, 7 Jan 2014 22:44:57 -0500 (EST) Date: Tue, 7 Jan 2014 22:44:57 -0500 (EST) From: Benjamin Kaduk To: Shawn M Emery In-Reply-To: Message-ID: References: <52CC4504.2080107@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrrvn5Jkgg9UN1hZHN69iseh7fYjd gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mr4cWslW8ETloq7azqYGxgfMncxcnJICJhI 7Fz8nQ3CFpO4cG89mC0kMJtJ4nSzVRcjF5C9gVGi8cwudgjnIJPE4hOn2CGq6iXa+tvBOlgE tCSerekAi7MJqEjMfLMRLC4CFL/R0MEEYjMLqEt8O/OGEcQWFtCRmHzjJFgNp4CexJXL68F6 eQUcJWa/+soMMd9b4uu9GWD1okD1q/dPYYGoEZQ4OfMJC8RMS4lzf66zTWAUnIUkNQtJagEj 0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdC73czBK91JTSTYzgQHVR3cE44ZDSIUYBDkYlHt4b ameChFgTy4orcw8xSnIwKYnyGh4DCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhFToClONNSays Si3Kh0lJc7AoifPe4rAPEhJITyxJzU5NLUgtgsnKcHAoSfC+AhkqWJSanlqRlplTgpBm4uAE Gc4DNFzzBMjw4oLE3OLMdIj8KUZFKXFeSZCEAEgiozQPrheWSF4xigO9Isz7B2QFDzAJwXW/ AhrMBDQ4NO4UyOCSRISUVAPjSY145n9aCW2nXh178nKy7VwX9XsXi7pOHTOc2x6StHBLEsML IaMH4ne3dZ26bi7gujE8LVb3lcS7O8Ef+H2mLbt6I3yZ8ioR/V87cs/u1xVcaip3xlj4tVLv u5v+tYtdY12KHPfkzd962Yqdw6uVY96kVXL3fW8cSq2qVUqdGePKxHH0yP7lSizFGYmGWsxF xYkAbH8Rc/8CAAA= Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 89 - 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: Wed, 08 Jan 2014 03:45:12 -0000 On Tue, 7 Jan 2014, Cantor, Scott wrote: > On 1/7/14, 1:18 PM, "Shawn M Emery" wrote: > >> >> Please provide any agenda items for a possible London session. Please >> submit these topics to the list or co-chairs no later than 1/14. > > Not sure it's an agenda item, but I need some assistance moving saml-ec to > last call. I'll have a new draft up this week that replaces the last draft > reference now that eap-naming is done. I also plan to move forward with my gss-loop document, but it's unclear that we'd need to talk about it in person as an agenda item. -Ben From internet-drafts@ietf.org Mon Jan 13 08:20: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 3832F1ADF78; Mon, 13 Jan 2014 08:20:05 -0800 (PST) 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 pW4kzWMsoXBh; Mon, 13 Jan 2014 08:20:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B84E41AC4A7; Mon, 13 Jan 2014 08:20:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113162002.5427.54760.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 08:20:02 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-11.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, 13 Jan 2014 16:20:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Authors : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-11.txt Pages : 38 Date : 2014-01-13 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-11 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/ From cantor.2@osu.edu Mon Jan 13 08:22:03 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 6E3101ADFDD for ; Mon, 13 Jan 2014 08:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 e1Q3_IqahTw8 for ; Mon, 13 Jan 2014 08:22:01 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8804D1AC4A7 for ; Mon, 13 Jan 2014 08:22:01 -0800 (PST) Received: from mail20-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 13 Jan 2014 16:21:50 +0000 Received: from mail20-tx2 (localhost [127.0.0.1]) by mail20-tx2-R.bigfish.com (Postfix) with ESMTP id 44E8AA015F for ; Mon, 13 Jan 2014 16:21:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.210; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf03; RD:none; EFVD:NLI X-SpamScore: -12 X-BigFish: VPS-12(zzbb2dI98dI9371I936eI1432Icf41nzz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h1b1cn1b1bi1155h) Received-SPF: pass (mail20-tx2: domain of osu.edu designates 164.107.81.210 as permitted sender) client-ip=164.107.81.210; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf03 ; cio-krc-pf03 ; Received: from mail20-tx2 (localhost.localdomain [127.0.0.1]) by mail20-tx2 (MessageSwitch) id 1389630108211563_24698; Mon, 13 Jan 2014 16:21:48 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.225]) by mail20-tx2.bigfish.com (Postfix) with ESMTP id 0FFF8380061 for ; Mon, 13 Jan 2014 16:21:48 +0000 (UTC) Received: from cio-krc-pf03 (164.107.81.210) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 13 Jan 2014 16:21:47 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf03 (Postfix) with ESMTPS id CE70CC004A for ; Mon, 13 Jan 2014 11:21:46 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.03.0174.001; Mon, 13 Jan 2014 11:21:46 -0500 From: "Cantor, Scott" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-11.txt Thread-Index: AQHPEHtPOE6jF1EZO0CuwyR3BFTSoJqC1iOA Date: Mon, 13 Jan 2014 16:21:46 +0000 Message-ID: References: <20140113162002.5427.54760.idtracker@ietfa.amsl.com> In-Reply-To: <20140113162002.5427.54760.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.69] Content-Type: text/plain; charset="us-ascii" Content-ID: <168BD6903BFEA84BA8340F463C0842D9@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-11.txt 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, 13 Jan 2014 16:22:03 -0000 This draft should be ready for WGLC. -- Scott On 1/13/14, 11:20 AM, "internet-drafts@ietf.org" wrote: > >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 : SAML Enhanced Client SASL and GSS-API Mechanisms > Authors : Scott Cantor > Simon Josefsson > Filename : draft-ietf-kitten-sasl-saml-ec-11.txt > Pages : 38 > Date : 2014-01-13 From kaduk@mit.edu Tue Jan 14 13:55: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 8E8361AE2AC for ; Tue, 14 Jan 2014 13:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 g9X0naBbSDIm for ; Tue, 14 Jan 2014 13:55:23 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id F361C1AE230 for ; Tue, 14 Jan 2014 13:55:22 -0800 (PST) X-AuditID: 1209190c-f794a6d000000c27-39-52d5b23fc8c1 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.1D.03111.F32B5D25; Tue, 14 Jan 2014 16:55:11 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s0ELtA2b005991 for ; Tue, 14 Jan 2014 16:55:11 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s0ELt9bi026663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Jan 2014 16:55:10 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s0ELt9Vx011721; Tue, 14 Jan 2014 16:55:09 -0500 (EST) Date: Tue, 14 Jan 2014 16:55:08 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUixCmqrGu/6WqQwbFX0hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqnjD9gKnopWzPzr08B4VrCLkZNDQsBEYu2PPWwQtpjEhXvr gWwuDiGB2UwSlzo6WCGc44wS++e+ZoZwbjBJfF7yGqqsgVHi6LTdLF2MHBwsAtoSjx/qg4xi E1CRmPlmI9hYEQFhid1b3zGD2MICARLHjr4Ci/MKOEpsb7/BCmKLCuhIrN4/hQUiLihxcuYT MJtZwFLi3J/rbBMY+WYhSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11AvN7NELzWl dBMjOJgkeXYwvjmodIhRgINRiYc3IOpqkBBrYllxZe4hRkkOJiVR3hNrgUJ8SfkplRmJxRnx RaU5qcWHGCU4mJVEeOXrgXK8KYmVValF+TApaQ4WJXHemxz2QUIC6YklqdmpqQWpRTBZGQ4O JQnehI1AjYJFqempFWmZOSUIaSYOTpDhPEDDu0BqeIsLEnOLM9Mh8qcYFaXEeetBEgIgiYzS PLheWLS/YhQHekWYNx2kigeYKOC6XwENZgIaHFwBNrgkESEl1cA4kyFAg3Oq2IOpXic2z353 NGmHe13Ay9hyDva/K1f/2G3BbGyu+LSQdfu/3lQby44ZRl4G37e6LHvyQffxa9YD3YW6cxU2 LHsmrzgpOMz2y1H1pLy0bga+zm+cx8LtJLeu/dETauWt2vDw8vxDK5JenwyYbK+x7vbpL4Eu yYFLblR/nPBuWZGlEktxRqKhFnNRcSIAELP8CtECAAA= Subject: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 14 Jan 2014 21:55:24 -0000 I made some minor edits to the body text and trimmed down the sample code to be more consistent with Greg's suggestions. I think Greg wants the sample code trimmed even further (i.e., to not have anything in the bodies of the {send,receive}_token functions, and possibly not have them at all, but I prefer to be more concrete. Is it reasonable to adopt this document as a working-group draft at this time? I am becoming more convinced that we should have Java sample code as well as C, but due to some computer issues I don't have a java development environment available at the moment. My Java is also quite rusty, so if someone else wants to chip in, that would be great. Finally, the C sample code has a comment (in two places, actually): /* It is safe to call gss_release_buffer twice on the same buffer. */ This could potentially be misleading, as I believe our conclusion was that 2743/2744 do not explicitly require this to be safe. However, we believe that it is safe in all known implementations, and that an implementation where it was not safe would be very difficult to use correctly. Is it reasonable to leave this comment in place under the reasoning that it is describing the assumptions made by the sample code (as opposed to describing the behavior mandated by the specification)? Thanks, Ben ---------- Forwarded message ---------- Date: Tue, 14 Jan 2014 13:27:45 -0800 From: internet-drafts@ietf.org To: Benjamin Kaduk , Benjamin Kaduk Subject: New Version Notification for draft-kaduk-kitten-gss-loop-02.txt A new version of I-D, draft-kaduk-kitten-gss-loop-02.txt has been successfully submitted by Benjamin Kaduk and posted to the IETF repository. Name: draft-kaduk-kitten-gss-loop Revision: 02 Title: Structure of the GSS Negotiation Loop Document date: 2014-01-14 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-kaduk-kitten-gss-loop-02.txt Status: https://datatracker.ietf.org/doc/draft-kaduk-kitten-gss-loop/ Htmlized: http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-kaduk-kitten-gss-loop-02 Abstract: This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. 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. The IETF Secretariat From ghudson@mit.edu Fri Jan 17 13:07:07 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 0D1781ACCDF for ; Fri, 17 Jan 2014 13:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 Ll0vg-cnDxfX for ; Fri, 17 Jan 2014 13:07:05 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 779101AC863 for ; Fri, 17 Jan 2014 13:07:04 -0800 (PST) X-AuditID: 1209190d-f79776d000000ce9-1b-52d99b6cac41 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D2.99.03305.C6B99D25; Fri, 17 Jan 2014 16:06:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s0HL6ku1031712; Fri, 17 Jan 2014 16:06:46 -0500 Received: from [18.101.8.203] (vpn-18-101-8-203.mit.edu [18.101.8.203]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s0HL6iUd016881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 16:06:45 -0500 Message-ID: <52D99B63.3040005@mit.edu> Date: Fri, 17 Jan 2014 16:06:43 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: 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+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrpsz+2aQwa7vohZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqsVO9gLHglVvDrQx9TA2M3fxcjJISFgIvGsZTY7hC0mceHe ejYQW0hgNpPEtJP5XYxcQPZGRomrz5oZIZwjTBK7XjwH6+AVUJOYOX8rmM0ioCoxdd1rsG42 AWWJg2e/sYDYogJhEnf/r2WEqBeUODnzCVhcRMBY4u7PG2C2sECsxP2+HqjNjhITX31nArE5 BZwkOj83MEJcJymxbdExsF3MAjoS7/oeMEPY8hLb385hnsAoOAvJillIymYhKVvAyLyKUTYl t0o3NzEzpzg1Wbc4OTEvL7VI10gvN7NELzWldBMjKFg5JXl3ML47qHSIUYCDUYmHV0L8RpAQ a2JZcWXuIUZJDiYlUV7lyTeDhPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwvm4HyvGmJFZWpRbl w6SkOViUxHlvctgHCQmkJ5akZqemFqQWwWRlODiUJHjXzQJqFCxKTU+tSMvMKUFIM3Fwggzn ARreCVLDW1yQmFucmQ6RP8WoKCXOKwKSEABJZJTmwfXCkskrRnGgV4R554NU8QATEVz3K6DB TECDRWLBBpckIqSkGhitNTruqPdmrOTbwNb+u5afaQuzkj7D9tW/KrZzVB/a2TT3Zqp7XPAb 7rw5dwL2HnDsbXL+Vn74/17T9x/XX+6ftz+i5WvQZ78G1fUaZZ17y19d37nZ6+LBaUKllV1v 8y+K6ycxZzy7trStNnWBinzGhnQ27xCxKb92Ln8x4VdkWH+Irsixm4+VWIozEg21mIuKEwF8 JELNAQMAAA== Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 17 Jan 2014 21:07:07 -0000 On 01/14/2014 04:55 PM, Benjamin Kaduk wrote: > I made some minor edits to the body text and trimmed down the sample > code to be more consistent with Greg's suggestions. I think Greg wants > the sample code trimmed even further (i.e., to not have anything in the > bodies of the {send,receive}_token functions, and possibly not have them > at all, but I prefer to be more concrete. My reasoning is that we cannot be concrete in a way which will be useful to very many applications. Currently your stub send_token() and receive_token() functions accept fd arguments, for instance, while a typical caller would have some more complicated connection state object. On a similar note, typical callers probably won't want to use warnx(). > Is it reasonable to adopt this document as a working-group draft at this > time? I think it is reasonable. To recap, the goal here is to reduce the amount of verbiage that protocol standards (AFS, LDAP, etc.) must use to describe how implementors should use GSSAPI, by giving them something they can refer to. > I am becoming more convinced that we should have Java sample code as > well as C I think that would be a fine thing, but shouldn't block the draft from progressing. > Finally, the C sample code has a comment (in two places, actually): > /* It is safe to call gss_release_buffer twice on the same buffer. */ > This could potentially be misleading, as I believe our conclusion was > that 2743/2744 do not explicitly require this to be safe. However, we > believe that it is safe in all known implementations, and that an > implementation where it was not safe would be very difficult to use > correctly. Is it reasonable to leave this comment in place under the > reasoning that it is describing the assumptions made by the sample code > (as opposed to describing the behavior mandated by the specification)? I think it's reasonable to retroactively standardize this behavior of gss_release_buffer, if it's a property of every implementation we're aware of. But if we're not going to do so (because gss-loop isn't a normative document and we're not prepared to issue a 2744 update), then I don't think it's appropriate for the sample code in gss-loop to be making that assumption. Unfortunately, I don't know of a nice elegant way to restructure the code so that the assumption isn't necessary. From mrex@sap.com Fri Jan 17 17:01: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 55B9C1AD66B for ; Fri, 17 Jan 2014 17:01:26 -0800 (PST) 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, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 1RemV2iTEVfU for ; Fri, 17 Jan 2014 17:01:25 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F38891ACCDF for ; Fri, 17 Jan 2014 17:01:24 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0I11Bw7014188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Jan 2014 02:01:11 +0100 (MET) In-Reply-To: <52D99B63.3040005@mit.edu> To: Greg Hudson Date: Sat, 18 Jan 2014 02:01:11 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 01:01:26 -0000 Greg Hudson wrote: > >> Finally, the C sample code has a comment (in two places, actually): >> /* It is safe to call gss_release_buffer twice on the same buffer. */ >> This could potentially be misleading, as I believe our conclusion was >> that 2743/2744 do not explicitly require this to be safe. However, we >> believe that it is safe in all known implementations, and that an >> implementation where it was not safe would be very difficult to use >> correctly. Is it reasonable to leave this comment in place under the >> reasoning that it is describing the assumptions made by the sample code >> (as opposed to describing the behavior mandated by the specification)? > > I think it's reasonable to retroactively standardize this behavior of > gss_release_buffer, if it's a property of every implementation we're > aware of. I hadn't notice this strange comment about gss_release_buffer() before, and I'm voilently opposed, please remove that misleading comment. None of the GSS-API calls makes any kind of promise that calling it twice would be safe. Actually, if you look at how the C-Bindings were designed, just the opposite has to be assumed. The convention to pass the pointers (and gss_buffer_desc) by reference to the release function, so that the function could zero out the references/pointers to resources that were allocated by the library appears specifically designed to make it less likely that a program will crash when calling a function twice -- _provided_ that it passes the _original_ reference to the release function (which can then be zeroed), rather than a mere copy of it (which could not possibly protect from being called again with other non-zero copies of the original). The only thing that a release function can be expected to recognize and handle safely is being called with an already zero-ed handle or already-zeroed value pointer in gss_buffer_desc. -Martin From nico@cryptonector.com Fri Jan 17 17:18:33 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 8E87D1ACCDF for ; Fri, 17 Jan 2014 17:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 s0dqqZv-AcC2 for ; Fri, 17 Jan 2014 17:18:32 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id B37771ACC86 for ; Fri, 17 Jan 2014 17:18:32 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id E72DD264058 for ; Fri, 17 Jan 2014 17:18:19 -0800 (PST) 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=BEBOZSdS0hu3WrSXKvNT yaO3QUg=; b=QhEdKyPNW0SzqqjNiRaIjYwZA2lQNAprVSkchRwPqQY14scimutl qYoGI+cpXq1JIuQCeRNkTMyRPxbFYrBlApwHB5kH+km0vHXlxV30yf9v3ezkfEoo PZuycq6JkeHzyilXeK4eVxUWAKgPj/ITIduiKGOFwuIaXHrXDNvok9M= 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-a88.g.dreamhost.com (Postfix) with ESMTPSA id 92BE6264057 for ; Fri, 17 Jan 2014 17:18:19 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hr1so1436978wib.2 for ; Fri, 17 Jan 2014 17:18:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kSu1PLKyC7escw/A5PhbzDccTf7ForZCYutHFU3yN+4=; b=iUxEFb4UuUfWmq/lo5F9KaDz+ZBkIgYrATMsho+KQfZInmfOIDvET/4sigqZt1sKSG shzN/7mxm0/dhfBdpx41F7ReB6MXAPH01dBy7fDCxa7nhJiDIzmfwbbRN9U/DKO3qmJ7 whDC6NQNDbEzH9fdQ8HLHvJtlIjk5OqTMM5kRAObSLjje8ZsZtV9VlE19lqjEkBZ5Qto Ur2cEvbkmnilyCzG5cOdr5AKltZOo08J1Owr201T/l0NzSqIO87KKtQN/oTYQrjhSMKS VAbi+aQ+rd/0j3erCobRtAFdWvRghTqQoGKoqOEJpXanEXhIBIOg0WrmILm8bHD9xR09 asJg== MIME-Version: 1.0 X-Received: by 10.180.85.138 with SMTP id h10mr867975wiz.5.1390007897856; Fri, 17 Jan 2014 17:18:17 -0800 (PST) Received: by 10.217.108.132 with HTTP; Fri, 17 Jan 2014 17:18:17 -0800 (PST) In-Reply-To: <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> References: <52D99B63.3040005@mit.edu> <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> Date: Fri, 17 Jan 2014 19:18:17 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 18 Jan 2014 01:18:33 -0000 Martin, The C bindings release/delete functions generally take a pointer to a variable that holds the thing being released precisely so they can set that variable to the appropriate GSS_C_NO_* value. Now, I realize that RFC2744 isn't the model of completeness -- it evidently doesn't say this one really important thing (from a quick skim before running off to dinner). I don't really care that it doesn't say that (if indeed it doesn't). It should have, as it's very clearly the intended behavior (otherwise why on earth take that pointer instead of just the value to be released/deleted?) and in fact the behavior that the implementations I'm familiar with have. An update should say it. I'd be OK with a note that there might be implementations that don't do this. Nico -- From eagle@eyrie.org Fri Jan 17 17:40: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 86D1B1AC4A3 for ; Fri, 17 Jan 2014 17:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 WsDjXYGHj4x4 for ; Fri, 17 Jan 2014 17:40:13 -0800 (PST) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 07BE71A1F74 for ; Fri, 17 Jan 2014 17:40:13 -0800 (PST) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 96CB434118D; Fri, 17 Jan 2014 17:40:00 -0800 (PST) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 714B9341184; Fri, 17 Jan 2014 17:39:59 -0800 (PST) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 55D6D2F808; Fri, 17 Jan 2014 17:39:58 -0800 (PST) From: Russ Allbery To: Nico Williams In-Reply-To: (Nico Williams's message of "Fri, 17 Jan 2014 19:18:17 -0600") Organization: The Eyrie References: <52D99B63.3040005@mit.edu> <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Fri, 17 Jan 2014 17:39:58 -0800 Message-ID: <8761pikqz5.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 18 Jan 2014 01:40:14 -0000 Nico Williams writes: > The C bindings release/delete functions generally take a pointer to a > variable that holds the thing being released precisely so they can set > that variable to the appropriate GSS_C_NO_* value. I think Martin's point is that the following is not safe: gss_buffer_desc buf1, buf2; gss_OID oid; gss_name_t name; OM_uint32 major, minor; /* ... */ major = gss_display_name(&minor, name, &buf1, &oid); buf2 = buf1; gss_release_buffer(&minor, &buf1); gss_release_buffer(&minor, &buf2); Similar sorts of code work with other GSS-API objects. It doesn't really matter whether the variable type is actually a struct or a pointer; either way, once you start making copies, double frees are still a risk. Now, obviously, you generally should avoid doing that sort of thing in GSS-API code precisely because it's not safe. But saying that it's permissible to pass the same buffer to gss_release_buffer multiple times implies that this sort of thing is safe, and I'm pretty sure it isn't. -- Russ Allbery (eagle@eyrie.org) From ghudson@mit.edu Fri Jan 17 19:29:03 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 EACE41AD83F for ; Fri, 17 Jan 2014 19:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 fSBn0a6ajJU1 for ; Fri, 17 Jan 2014 19:29:02 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 357111A1F3F for ; Fri, 17 Jan 2014 19:29:02 -0800 (PST) X-AuditID: 1209190d-f79776d000000ce9-19-52d9f4f10ac7 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id CE.B6.03305.1F4F9D25; Fri, 17 Jan 2014 22:28:49 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s0I3Sgwf028481; Fri, 17 Jan 2014 22:28:43 -0500 Received: from [18.101.8.203] (vpn-18-101-8-203.mit.edu [18.101.8.203]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s0I3SdOS030485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 22:28:42 -0500 Message-ID: <52D9F4E7.6050205@mit.edu> Date: Fri, 17 Jan 2014 22:28:39 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mrex@sap.com References: <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> In-Reply-To: <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hRV1v345WaQQV8br8XRzatYLHp/72B2 YPJYsuQnk8eUz1sZA5iiuGxSUnMyy1KL9O0SuDJWvlzCWPCdveLpvOnsDYzb2boYOTkkBEwk Ln/qgbLFJC7cWw9kc3EICcxmknj/5h4LhLORUWL17InMEM4RJom/C7ewgLTwCqhJNB29ANTC wcEioCpxea4QSJhNQFni4NlvYCWiAmESd/+vZYQoF5Q4OfMJWFxEQEBi4YoH7CA2s4CxxKWe 9awgtrBArMT9PoiLhASsJRo+LAXr5RSwkTi4rgnqUkmJbYuOQfXqSLzre8AMYctLbH87h3kC o9AsJOtmISmbhaRsASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjODAluTd wfjuoNIhRgEORiUe3gefbgYJsSaWFVfmHmKU5GBSEuX1fwwU4kvKT6nMSCzOiC8qzUktPsQo wcGsJML7uh0ox5uSWFmVWpQPk5LmYFES573JYR8kJJCeWJKanZpakFoEk5Xh4FCS4JUARrCQ YFFqempFWmZOCUKaiYMTZDgP0HCpzyDDiwsSc4sz0yHypxgVpcR5n4MkBEASGaV5cL2wxPOK URzoFWHexyBVPMCkBdf9CmgwE9BgkViwwSWJCCmpBkb/V3zMr048mr7z9NfaiMLXU09brdww LXLX7IYTntsfnm7uTbcSq576/UnYdF6RydNX60RpCKjWFjoF71AK0Z7Ezho0Ny547lWh5udR IRo1l/bG5Ty2r337X9Rx8clTIh+vOx8ocIq02dPwgmtHleXPTdp7Hkw/9GxjycQpK09vtSxV lZNYrhetxFKckWioxVxUnAgARUuvGBcDAAA= Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 18 Jan 2014 03:29:04 -0000 On 01/17/2014 08:01 PM, Martin Rex wrote: >>> /* It is safe to call gss_release_buffer twice on the same buffer. */ > I hadn't notice this strange comment about gss_release_buffer() before, > and I'm voilently opposed, please remove that misleading comment. The comment in the draft is trying to say that it's okay to call gss_release_buffer twice with the same reference to a gss_buffer_desc structure, trusting that the first call will put the structure into a state where the second call is a no-op. Unfortunately, RFC 2744 does not appear to guarantee this; 5.26 only requires that the length is set to 0 after the storage is freed (implementations are merely "encouraged" to zero the pointer field), and does not guarantee that a second call won't double-free the storage. If it is okay for the sample code to rely on this behavior, in spite of RFC 2744 not specifying that it is okay, then perhaps the comment should be clarified or removed to avoid confusing people like it did Martin. From nico@cryptonector.com Fri Jan 17 22:18: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 2C7A31ADE72 for ; Fri, 17 Jan 2014 22:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 tk0-tk7jAT4u for ; Fri, 17 Jan 2014 22:18:53 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0601ADEA1 for ; Fri, 17 Jan 2014 22:18:53 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 6BA761B4059 for ; Fri, 17 Jan 2014 22:18:40 -0800 (PST) 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=FBHTfudduiowdOC8dc7e ddhGVow=; b=fTANU6DwSvnIXmHVnw/gLLD1lUxY4MiNav7H+oMXORYkj+9hZf4B Ermx7pPxBpaBsWYrVtnw1ejfZOt/+aRvvk6VtuK9RQzFr2wzFqNs9Vk6B4nFwDpy iD3PTwgjHGHZMFawNUT2Rw6+gq8+/TyZgxGsPzhcgtlqvwEsWFw9BiU= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id EB0671B4058 for ; Fri, 17 Jan 2014 22:18:39 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id d13so1532053wiw.13 for ; Fri, 17 Jan 2014 22:18:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JQLvm9oQSJeznJEVuacGx4iHC8O1RM+pO8spH03NZLE=; b=W56tax7SdBRqWOkI/NATfK7wfYqaNuusxqTjgOyESPUT0NAtnmv1oXK8OIkIGM1W8x dJwwijW7I0GDAXEOXc1qPB5IDY1+2FruFwIVhV8PrgwAfmOvXY+IjXr+KuaKyIEDrg56 qNszVcUTKTSeg/1zo8KQZQheqhTfE5PmCseawejAakDwa22bHCjP2TA4dB/y4K0/T9yh SrO4b9YCMYRcCfkinSOqixkthAJsLMmveI3JidEEV4U7meOhLxRnvEMDOsu/WRpx0EoV gTQGcLJXQHeCQ+LbY07q2AYkVsZkn5EsgL7Ipuv2IiVc04vdxu1ZfxsCbBZMEKL9six1 0obw== MIME-Version: 1.0 X-Received: by 10.180.104.72 with SMTP id gc8mr1558661wib.5.1390025918259; Fri, 17 Jan 2014 22:18:38 -0800 (PST) Received: by 10.217.108.132 with HTTP; Fri, 17 Jan 2014 22:18:38 -0800 (PST) In-Reply-To: <8761pikqz5.fsf@windlord.stanford.edu> References: <52D99B63.3040005@mit.edu> <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> <8761pikqz5.fsf@windlord.stanford.edu> Date: Sat, 18 Jan 2014 00:18:38 -0600 Message-ID: From: Nico Williams To: Russ Allbery Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 18 Jan 2014 06:18:54 -0000 On Fri, Jan 17, 2014 at 7:39 PM, Russ Allbery wrote: > Nico Williams writes: > >> The C bindings release/delete functions generally take a pointer to a >> variable that holds the thing being released precisely so they can set >> that variable to the appropriate GSS_C_NO_* value. > > I think Martin's point is that the following is not safe: > > gss_buffer_desc buf1, buf2; > gss_OID oid; > gss_name_t name; > OM_uint32 major, minor; > > /* ... */ > > major = gss_display_name(&minor, name, &buf1, &oid); > buf2 = buf1; > gss_release_buffer(&minor, &buf1); > gss_release_buffer(&minor, &buf2); I'm not sure that that's what he meant, but if that's what he meant then that's fine with me. No matter what sort of type gss_buffer_desc might be (a struct here, but suppose it was an int or a pointer), and considering the side-effects of gss_release_buffer(), that could not possibly be safe. But I think Martin meant that this is not supposed to be safe: gss_buffer_desc buf; gss_OID oid; gss_name_t name; OM_uint32 major, minor; /* ... */ major = gss_display_name(&minor, name, &buf, &oid); gss_release_buffer(&minor, &buf); /* sets buf to {0, NULL} */ gss_release_buffer(&minor, &buf); /* releasing {0, NULL} is safe, like free(NULL) */ > Similar sorts of code work with other GSS-API objects. It doesn't really > matter whether the variable type is actually a struct or a pointer; either > way, once you start making copies, double frees are still a risk. Right, the type could be an integer, a pointer, a struct -- it doesn't matter. Of course, an implementation could protect against double-release in some cases. But they aren't and shouldn't be required to. What I'm saying is that the design of the C bindings' release/delete functions is meant to set the variable whose pointer is passed in to the zero/null/empty value. No other interpretation is possible. Why ever bother taking a pointer to a variable instead of the value otherwise? Oh, and see the text in RFC2744, section 3.9.2: The minor_status parameter will always be set by a GSS-API routine, even if it returns a calling error or one of the generic API errors indicated above as fatal, although most other output parameters may remain unset in such cases. However, output parameters that are expected to return pointers to storage allocated by a routine must always be set by the routine, even in the event of an error, although in such cases the GSS-API routine may elect to set the returned parameter value to NULL to indicate that no storage was actually allocated. Any length field associated with such pointers (as in a gss_buffer_desc structure) should also be set to zero in such cases. That only leaves the question of whether gss_release_buffer()'s gss_buffer_t argument is an input/output parameter (it clearly has to at least be an input parameter, but also clearly no actual output other than {0, NULL} is intended!). > Now, obviously, you generally should avoid doing that sort of thing in > GSS-API code precisely because it's not safe. But saying that it's Or with just about *any* API. You shouldn't close(2) the same fildes twice, for example, nor free(3) the same pointer twice, nor munmap(2) the same address twice, and so on. > permissible to pass the same buffer to gss_release_buffer multiple times > implies that this sort of thing is safe, and I'm pretty sure it isn't. This is clearly intended to be safe: gss_buffer_desc buf; gss_OID oid; gss_name_t name; OM_uint32 major, minor; /* ... */ major = gss_display_name(&minor, name, &buf, &oid); gss_release_buffer(&minor, &buf); /* sets buf to {0, NULL} */ gss_release_buffer(&minor, &buf); /* releasing {0, NULL} is safe, like free(NULL) */ Nico -- From nico@cryptonector.com Fri Jan 17 22:23:01 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 A7D7A1ADEA1 for ; Fri, 17 Jan 2014 22:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 CWb5wkIQp3cb for ; Fri, 17 Jan 2014 22:23:00 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBF71ADE72 for ; Fri, 17 Jan 2014 22:23:00 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id EE8B9674060 for ; Fri, 17 Jan 2014 22:22:47 -0800 (PST) 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=MgjO69tuJgBKVfCRjlf8 7HPbaaI=; b=dPUHMRt90c3C5XS46giUEEZyUUhGoC39q7MYiGpMsj02WR+1/vIu S5DnupETSP82I9ljAVUtOpffTXWHiJg+fIAosj2Vm1PSggYI4IreJbsdMutv4WIe 5d69pJnaDm0rLyyryLsFyvIBnnwfj2edpHoogWV3lVcEec/gpkvtEjc= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 9CF0C674058 for ; Fri, 17 Jan 2014 22:22:47 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id u57so5379928wes.29 for ; Fri, 17 Jan 2014 22:22:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wpSC+1gYBjLwV5K45WUmPYjJwwSIdg0nxpHsdjEzmGk=; b=A+TFNw9Zczr1Bx6fZm+TFALq5X/AGUk8DorJJSBNrUsWa75ZfsG1zSGW0KfO/une4M yxKCIv+FeEZE5AZZCLoaDbLboT8RP93izAuOGHTw8FadGDv01uW2WO8Wid7DCDvtQvnZ o5cJPBpyc9MTiSW4+4/56Fl0zkVhNRcz3YHBTWNyuF3dOZPymfuVxQYp1ui+QpRBnMO2 xryFT3isze/lfE1H4fOzTadoAQKQJgG+zdWK+xOD21Ib0TH8xKSeJ/IWn09jFvEkPitO o3txTn8YBgYmzQo6IcOFR1n52HIXOgaEUNZo7l80nL8B6RF/Cj3vLD6h8FYOiLbbS445 Y1uQ== MIME-Version: 1.0 X-Received: by 10.194.187.101 with SMTP id fr5mr34469wjc.76.1390026166275; Fri, 17 Jan 2014 22:22:46 -0800 (PST) Received: by 10.217.108.132 with HTTP; Fri, 17 Jan 2014 22:22:46 -0800 (PST) In-Reply-To: <52D9F4E7.6050205@mit.edu> References: <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> <52D9F4E7.6050205@mit.edu> Date: Sat, 18 Jan 2014 00:22:46 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 18 Jan 2014 06:23:01 -0000 On Fri, Jan 17, 2014 at 9:28 PM, Greg Hudson wrote: > On 01/17/2014 08:01 PM, Martin Rex wrote: >>>> /* It is safe to call gss_release_buffer twice on the same buffer. */ > >> I hadn't notice this strange comment about gss_release_buffer() before, >> and I'm voilently opposed, please remove that misleading comment. > > The comment in the draft is trying to say that it's okay to call > gss_release_buffer twice with the same reference to a gss_buffer_desc > structure, trusting that the first call will put the structure into a > state where the second call is a no-op. Unfortunately, RFC 2744 does > not appear to guarantee this; 5.26 only requires that the length is set > to 0 after the storage is freed (implementations are merely "encouraged" > to zero the pointer field), and does not guarantee that a second call > won't double-free the storage. RFC2744, section 5.26 requires nothing. It doesn't say "MUST", and so on (because RFC2744 doesn't reference RFC2119, of course). It doesn't say that the value field will not be set. Section 3.9.2 seems to indicate that the value field ought to be set, but only if the buffer is an output buffer. > If it is okay for the sample code to rely on this behavior, in spite of > RFC 2744 not specifying that it is okay, then perhaps the comment should > be clarified or removed to avoid confusing people like it did Martin. I would just note that RFC2744 can be interpreted as permitting gss_release_buffer() implementations to set the length field but not the value field. But I'd rather just say that RFC2744 just has a glaring omission... because that's what it is. Nico -- From jhutz@cmu.edu Fri Jan 17 23:41: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 BB2B51A1F72 for ; Fri, 17 Jan 2014 23:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 pQ-fuIPAOYe6 for ; Fri, 17 Jan 2014 23:40:58 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) by ietfa.amsl.com (Postfix) with ESMTP id 723541A1F56 for ; Fri, 17 Jan 2014 23:40:58 -0800 (PST) Received: from [192.168.202.142] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s0I7ehCi005461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jan 2014 02:40:44 -0500 (EST) Message-ID: <1390030843.9269.17.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Sat, 18 Jan 2014 02:40:43 -0500 In-Reply-To: <9509_1390026173_s0I6Mqd1009628_CAK3OfOj-gHJ5gwA6RnKMomYEuuMUkge4MVKEquqfCXT86buNMQ@mail.gmail.com> References: <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> <52D9F4E7.6050205@mit.edu> <9509_1390026173_s0I6Mqd1009628_CAK3OfOj-gHJ5gwA6RnKMomYEuuMUkge4MVKEquqfCXT86buNMQ@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Cc: jhutz@cmu.edu Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 18 Jan 2014 07:41:01 -0000 On Sat, 2014-01-18 at 00:22 -0600, Nico Williams wrote: > RFC2744, section 5.26 requires nothing. It doesn't say "MUST", and so > on (because RFC2744 doesn't reference RFC2119, of course). No, it pretty clearly says "the routine will zero the length field...". The text is descriptive in its phrasing, because the whole document is written more like API documentation for callers than a standard for implementors. However, it is in fact the latter, and so a statement about what a routine _will_ do is pretty clearly prescriptive in intent. Similarly, it's pretty clear that releasing a buffer with NULL value is required to be safe, per the last sentence in that same paragraph. > It doesn't > say that the value field will not be set. No. It fairly clearly leaves that up to the implementor. > Section 3.9.2 seems to > indicate that the value field ought to be set, but only if the buffer > is an output buffer. Section 3.9.2 requires that the value be set for an output parameter that is "expected to return pointers to storage allocated by a routine". That's sane; it means, for example, that after you call a GSS-API routine that has a buffer output, it is always safe to call gss_release_buffer on that buffer, whether or not the routine succeeded, and whether or not it actually allocated any storage. However, section 3.9.2 has nothing to say about the buffer descriptor passed to gss_release_buffer, even if we consider that to be an output buffer. Why? Because the purpose of gss_release_buffer is to free storage, not to allocate it. More particularly, the buffer parameter to this routine is not used to return a pointer to allocated storage; it is used to pass in a pointer to storage to be freed, possibly with the side-effect that the pointer is set to NULL, but certainly not that it is set to point to allocated storage! Perhaps more directly to the point, 3.9.2 is part of a section describing general calling conventions, while the text in 5.26 pertains specifically to gss_release_buffer _and_ has something specific to say about the pointer (namely, that implementations are "encouraged" to set it to NULL. This, I thikn, has about the same strength that naive readers assign to "SHOULD"). > > If it is okay for the sample code to rely on this behavior, in spite of > > RFC 2744 not specifying that it is okay, then perhaps the comment should > > be clarified or removed to avoid confusing people like it did Martin. > > I would just note that RFC2744 can be interpreted as permitting > gss_release_buffer() implementations to set the length field but not > the value field. But I'd rather just say that RFC2744 just has a > glaring omission... because that's what it is. Except I wouldn't call it an omission, in that it appears quite deliberate. Why say that implementations are "encouraged" to set the pointer to NULL, rather than either making it required or saying nothing at all? Perhaps to avoid rendering some existing implementation(s) noncompliant? The reality is that people tend to copy and paste example code, often without really understanding it. To some extent, that's the point -- we want people to be able to get this right _without_ investing months or years becoming expert enough to work out all of the possible cases. In light of that, I think such example code needs to be of the highest quality, which certainly means it should not make unfounded assumptions about the interface it purports to document. -- Jeff From ghudson@mit.edu Sat Jan 18 10:26:03 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 A2E151ADF88 for ; Sat, 18 Jan 2014 10:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 sq3TvFQ0Y3yi for ; Sat, 18 Jan 2014 10:26:01 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id C49DA1ADF6B for ; Sat, 18 Jan 2014 10:26:00 -0800 (PST) X-AuditID: 1209190e-f79ee6d000000c40-82-52dac72b8911 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id FA.39.03136.B27CAD25; Sat, 18 Jan 2014 13:25:47 -0500 (EST) 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 s0IIPkDD008199 for ; Sat, 18 Jan 2014 13:25:47 -0500 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s0IIPkAw006107 for ; Sat, 18 Jan 2014 13:25:46 -0500 From: Greg Hudson To: kitten@ietf.org References: Date: Sat, 18 Jan 2014 13:25:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUixCmqrat9/FaQwcJnahZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtvTIgXPZSum3NvG2MA4W6qLkZNDQsBEomPmLzYIW0ziwr31 YLaQwGwmiemr2bsYuYDs44wSG/8cY4JwOpgkDrQdBatiE1CWOHj2GwuILSIgLLF76ztmEFtY wFPi6LX7TBCTIiTeP3nJCGKzCKhKLL63GqyGV8BQ4uypeSwQtqDEyZlPwGxmAS2JG/9eMk1g 5J2FJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2M4JCR5NvB+PWg 0iFGAQ5GJR7eB59uBgmxJpYVV+YeYpTkYFIS5VVacitIiC8pP6UyI7E4I76oNCe1+BCjBAez kghv8AagHG9KYmVValE+TEqag0VJnPcmh32QkEB6YklqdmpqQWoRTFaGg0NJgvfkUaBGwaLU 9NSKtMycEoQ0EwcnyHAeoOEfj4AMLy5IzC3OTIfIn2JUlBLn1QRpFgBJZJTmwfXCYvoVozjQ K8K8BSBVPMB0ANf9CmgwE9BgkdibIINLEhFSUg2M6Q/DSzvfFdfWc/i7m8XPmh7FYa2xMcvz askUnuV3zZUaE7pftJ9OzQ7QrD+5RSZurrlkg03eWy1rAb4rJou+df6/J3zd9kC1hJbV12ed 97ey3H68wkLA6ZpNdvX8S5fWXOtnkt1gqxFTbbCKz0HuwxVHhoRLmey73wdare79JZx468CT V/pKLMUZiYZazEXFiQCFFN3vxAIAAA== Subject: Re: [kitten] krb5 gss_pseudo_random implementation/spec variance 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, 18 Jan 2014 18:26:03 -0000 Nico wrote: > I think we should submit an I-D with a) the update to the original, b) > test vectors. I'm not volunteering to submit a revised I-D, but here are some test vectors from the MIT implementation. I used input string lengths of 0 and 61 bytes, and an output length of 44 bytes. 61 bytes of input is just enough to produce a partial second MD5 or SHA1 hash block with the four-byte counter prefix, and 44 bytes of output requires two full and one partial RFC 3961 PRF output for all existing enctypes. All keys were randomly generated. Enctype: des-cbc-crc Key: E607FE9DABB57AE0 Input: (empty string) Output: 803C4121379FC4B87CE413B67707C4632EBED2C6D6B7 2A55E878836E35E21600D915D590DED5B6D77BB30A1F Enctype: des-cbc-crc Key: 54758316B6257A75 Input: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 Output: 279E4105F7ADC9BD6EF28ABE31D89B442FE0058388BA 33264ACB5729562DC637950F6BD144B654BE7700B2D6 Enctype: des3-cbc-sha1 Key: 70378A19CD64134580C27C0115D6B34A1CF2FEECEF9886A2 Input: (empty string) Output: 9F8D127C520BB826BFF3E0FE5EF352389C17E0C073D9 AC4A333D644D21BA3EF24F4A886D143F85AC9F6377FB Enctype: des3-cbc-sha1 Key: 3452A167DF1094BA1089E0A20E9E51ABEF1525922558B69E Input: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 Output: 6BF24FABC858F8DD9752E4FCD331BB831F238B5BE190 4EEA42E38F7A60C588F075C5C96A67E7F8B7BD0AECF4 Enctype: rc4-hmac Key: 3BB3AE288C12B3B9D06B208A4151B3B6 Input: (empty string) Output: 9AEA11A3BCF3C53F1F91F5A0BA2132E2501ADF5F3C28 3C8A983AB88757CE865A22132D6100EAD63E9E291AFA Enctype: rc4-hmac Key: 6DB7B33A01BD2B72F7655CB7B3D5FA0B Input: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 Output: CDA9A544869FC84873B692663A82AFDA101C8611498B A46138B01E927C9B95EEC953B562807434037837DDDF Enctype: aes128-cts-hmac-sha1-96 Key: 6C742096EB896230312B73972FA28B5D Input: (empty string) Output: 94208D982FC1BB7778128BDD77904420B45C9DA699F3 117BCE66E39602128EF0296611A6D191A5828530F20F Enctype: aes128-cts-hmac-sha1-96 Key: FA61138C109D834A477D24C7311BE6DA Input: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 Output: 0FAEDF0F842CC834FEE750487E1B622739286B975FE5 B7F45AB053143C75CA0DF5D3D4BBB80F6A616C7C9027 Enctype: aes256-cts-hmac-sha1-96 Key: 08FCDAFD5832611B73BA7B497FEBFF8C954B4B58031CAD9B977C3B8C25192FD6 Input: (empty string) Output: E627EFC14EF5B6D629F830C7109DEA0D3D7D36E8CD57 A1F301C5452494A1928F05AFFBEE3360232209D3BE0D Enctype: aes256-cts-hmac-sha1-96 Key: F5B68B7823D8944F33F41541B4E4D38C9B2934F8D16334A796645B066152B4BE Input: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 Output: 112F2B2D878590653CCC7DE278E9F0AA46FA5A380B62 59F774CB7C134FCD37F61A50FD0D9F89BF8FE1A6B593 Enctype: camellia128-cts-cmac Key: 866E0466A178279A32AC0BDA92B72AEB Input: (empty string) Output: 97FBB354BF341C3A160DCC86A7A910FDA824601DF677 68797BACEEBF5D250AE929DEC9760772084267F50A54 Enctype: camellia128-cts-cmac Key: D4893FD37DA1A211E12DD1E03E0F03B7 Input: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 Output: 1DEE2FF126CA563A2A2326B9DD3F0095013257414C83 FAD4398901013D55F367C82681186B7B2FE62F746BA4 Enctype: camellia256-cts-cmac Key: 203071B1AE77BD3D6FCE70174AF95C225B1CED46B35CF52B6479EFEB47E6B063 Input: (empty string) Output: 9B30020634C10FDA28420CEE7B96B70A90A771CED43A D8346554163E5949CBAE2FB8EF36AFB6B32CE75116A0 Enctype: camellia256-cts-cmac Key: A171AD582C1AFBBAD52ABD622EE6B6A14D19BF95C6914B2BA40FFD99A88EC660 Input: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 Output: A47CBB6E104DCC77E4DB48A7A474B977F2FB6A7A1AB6 52317D50508AE72B7BE2E4E4BA24164E029CBACF786B From nico@cryptonector.com Sat Jan 18 22:07: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 BD5891ADA5D for ; Sat, 18 Jan 2014 22:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 K_gg4upgAIrY for ; Sat, 18 Jan 2014 22:07:13 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0CD1AD9B6 for ; Sat, 18 Jan 2014 22:07:13 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3762C674058 for ; Sat, 18 Jan 2014 22:07:00 -0800 (PST) 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=D48j5Fo+YQMtx3Z2bIB9 uYilj28=; b=eI+tGqfNO1HNBxm6MHQpdafzyt0Vk5RlKlTyo+1n/5wct75WXxnc cb+HVEN2Qafw+ddns2Ie/lrOkRa9P4uG/faOxBGXBH8VlemnkjnOQIEBmUygcZi2 ZBMVs/8Nz8xz8j9dXRyTwuIRlgZ0kZ1DwcjzLVhsGr7LDPNhSPD30FY= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id DFEEF674057 for ; Sat, 18 Jan 2014 22:06:59 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id l18so5793127wgh.17 for ; Sat, 18 Jan 2014 22:06:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HHJ5v1m/0df0qjvYlPUJB+HJKMBHAd7Ks42OIpYFnXE=; b=VVV298K4q9i3GNY17qwcimnE6OdBUoDlOVDv1TWpVuaGjOuHY26xvyLR4wfrU010d5 maz/EvVs8elP0mtXuIyUVEiD++OOrr/FaZpDK1q5eRLS1KdpTJzNPwSG4467kAM3/ReF 0M3UOLzBisWx+n12tnk8XndZNRtKHiq3l1IU6B04hTrR/+yuMjgp65B825cEPM01319I SWlp3KUwErhyfvMln8vmFfzO6YEP5D+u2o0Jxb0BwM9RAG6dIUDwKjGyjPjMsZsvNqc2 r4euBlL1Bs40bU+qT0oF2Jnb3FfeiJQwWOqr6f3eeGgv8mGHF0dvvMTrf/V6h4GKpkJk LCoQ== MIME-Version: 1.0 X-Received: by 10.180.12.238 with SMTP id b14mr4975820wic.42.1390111618256; Sat, 18 Jan 2014 22:06:58 -0800 (PST) Received: by 10.217.108.132 with HTTP; Sat, 18 Jan 2014 22:06:58 -0800 (PST) In-Reply-To: <1390030843.9269.17.camel@destiny.pc.cs.cmu.edu> References: <20140118010111.326F31ABB3@ld9781.wdf.sap.corp> <52D9F4E7.6050205@mit.edu> <9509_1390026173_s0I6Mqd1009628_CAK3OfOj-gHJ5gwA6RnKMomYEuuMUkge4MVKEquqfCXT86buNMQ@mail.gmail.com> <1390030843.9269.17.camel@destiny.pc.cs.cmu.edu> Date: Sun, 19 Jan 2014 00:06:58 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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: Sun, 19 Jan 2014 06:07:15 -0000 I'm an idiot. I missed the "encouraged" part somehow. Nonetheless, it seems clear that the intention is that calling a gss_release/delete_*() function will modify the input/output parameter so that calling it again is safe, so that releasing a zero-length, non-zero valued buffer ought to be safe. The API can output zero-length buffers from gss_unwrap(), so the question comes up of whether such buffers can have non-zero values -- the RFC doesn't say. The other places where the API can output a zero-length token in non-error conditions are gss_init/accept_sec_context() and gss_delete_sec_context, and there the text is not entirely dispositive... but it is highly suggestive that zero-length tokens are empty, and this, together with the general design of gss_release/delete_*() strongly implies that it should be safe to call any of those twice with the same input/output parameter. The only reason to assume that releasing a zero-length/non-zero value buffer is that an implementation might have called malloc(0) in the process of outputting a zero-length buffer from gss_unwrap(), and the malloc() implementation happens to return non-NULL when called with zero as its argument. That's clearly a bug. There should be no reason to release empty buffers. At any rate this is all rather incidental to Ben's I-D and doesn't need to be addressed at this time. If we ever update RFC2744, I would insist on changing that "encouraged" to "MUST" with some text about how earlier versions of the API did not have that requirement, therefore applications SHOULD zero the value in the buffer after releasing it. Nico -- From mrex@sap.com Mon Jan 20 11:32:34 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 75F861A0227 for ; Mon, 20 Jan 2014 11:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 EwcfMXQgIhEg for ; Mon, 20 Jan 2014 11:32:32 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A76B11A0216 for ; Mon, 20 Jan 2014 11:32:31 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0KJWP1h014630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jan 2014 20:32:25 +0100 (MET) In-Reply-To: To: Nico Williams Date: Mon, 20 Jan 2014 20:32:25 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140120193225.529C31ABBC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" , Jeffrey Hutzelman Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 19:32:34 -0000 Nico Williams wrote: > > Nonetheless, it seems clear that the intention is that calling a > gss_release/delete_*() function will modify the input/output parameter > so that calling it again is safe, so that releasing a zero-length, > non-zero valued buffer ought to be safe. In theory yes, but practice may differ. What I'm afraid of is wrapper functions that look like this: OM_uint32 app_wrapper_gss_release_cred(gss_ctx_id_t cred) { OM_uint32 maj_stat; OM_uint32 min_stat; gss_cred_id_t l_cred = cred; maj_stat = gss_release_cred(&min_stat, &l_cred); if ( GSS_S_COMPLETE!=maj_stat ) { app_show_error( maj_stat, min_stat); } return(maj_stat); } And if that app_wrapper_* release function is called twice, then a non-zero copy of the original cred will be passed on the second call, and that may result in the undefined behaviour of double-free(). > > The API can output zero-length buffers from gss_unwrap(), > so the question comes up of whether such buffers can have > non-zero values -- the RFC doesn't say. correct -- gss_unwrap() may return a zero-length output buffer. The length of the buffer must be zero for obvious reasons. The value of the pointer is then irrelevant, and the gssapi mechanism must be able to cope safely with whatever it returns along with a zero length. > > The other places where the API can output a zero-length token in > non-error conditions are gss_init/accept_sec_context() and > gss_delete_sec_context, Nope, neither of these three calls can return a zero-length output token, they either return a token or do not return a token (which means that a gssapi wrapper mechanism that would blindly copy output parameters from underlying implementations and use an implementation specific malloc(0) would be buggy and leak memory for these three functions. > > and there the text is not entirely > dispositive... but it is highly suggestive that zero-length tokens > are empty, and this, together with the general design of > gss_release/delete_*() strongly implies that it should be safe to call > any of those twice with the same input/output parameter. No, NEVER. The only thing that _might_ be safe, when the gssapi mechanism designer didn't mess up, is superfluous release calls with a NULL handle, i.e. calling it once with a handle that gets zeroed, and then calling it again with the zero-ed handle. The big difference here is that the second call is *NOT* with the same handle, but with a handle that was zero-ed by a prior release call. This is why I don't like the current language, that would suggest the wrapper describe above could be safely called as well (which it can not). > > The only reason to assume that releasing a zero-length/non-zero value > buffer is that an implementation might have called malloc(0) in the > process of outputting a zero-length buffer from gss_unwrap() malloc(0) is something that no reasonable gssapi mechanism implementation should ever do. -Martin From jhutz@cmu.edu Mon Jan 20 13:07: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 9FF681A024D for ; Mon, 20 Jan 2014 13:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.535] 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 Ir9tmumsRStc for ; Mon, 20 Jan 2014 13:07:26 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id CB80E1A0215 for ; Mon, 20 Jan 2014 13:07:25 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s0KL7On8021627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 16:07:24 -0500 (EST) Message-ID: <1390252044.31766.134.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Mon, 20 Jan 2014 16:07:24 -0500 In-Reply-To: <17007_1390246359_s0KJWc83017642_20140120193225.529C31ABBC@ld9781.wdf.sap.corp> References: <17007_1390246359_s0KJWc83017642_20140120193225.529C31ABBC@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Cc: jhutz@cmu.edu Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 20 Jan 2014 21:07:28 -0000 On Mon, 2014-01-20 at 20:32 +0100, Martin Rex wrote: > Nico Williams wrote: > > > > Nonetheless, it seems clear that the intention is that calling a > > gss_release/delete_*() function will modify the input/output parameter > > so that calling it again is safe, so that releasing a zero-length, > > non-zero valued buffer ought to be safe. > > In theory yes, but practice may differ. > > What I'm afraid of is wrapper functions that look like this: Well, if an app has such a wrapper, then the _wrapper_ is not safe to call twice. That really has nothing to do with whether gss_release_buffer is safe to call twice, and the spec for the latter pretty clearly says it modifies its output. I don't think it's reasonable to make a decision about what is required of our API on the grounds that some hypothetical person not implementing our API might decide to not implement our API in such a way that they're not compliant with our API. Now, if you're talking about a mechglue, then of course such a thing must be compliant with our API, since it is an implementation of it. But neither requiring release to null the value pointer nor requiring double-release to be safe is incompatible with that, provided the glue is implemented correctly. Your example would not be such a correct implementation, but that doesn't mean one can't exists. > > The API can output zero-length buffers from gss_unwrap(), > > so the question comes up of whether such buffers can have > > non-zero values -- the RFC doesn't say. > > correct -- gss_unwrap() may return a zero-length output buffer. > The length of the buffer must be zero for obvious reasons. > The value of the pointer is then irrelevant, and the gssapi > mechanism must be able to cope safely with whatever it returns > along with a zero length. Right. If the mech returns a buffer with zero length and a non-NULL value pointer, then it must be able to cope with gss_release_buffer being called on that buffer. > > > > > > The other places where the API can output a zero-length token in > > non-error conditions are gss_init/accept_sec_context() and > > gss_delete_sec_context, > > Nope, neither of these three calls can return a zero-length output token, You know, we've discussed that question on several occasions, and I can't remember ever being able to find something in RFC2743 that says that. The C bindings happen to make it impossible to tell the difference between no token and an empty token, which makes using empty tokens impractical, but if you can find text that prohibits them, please do point it out. > > and there the text is not entirely > > dispositive... but it is highly suggestive that zero-length tokens > > are empty, and this, together with the general design of > > gss_release/delete_*() strongly implies that it should be safe to call > > any of those twice with the same input/output parameter. > > No, NEVER. > > The only thing that _might_ be safe, when the gssapi mechanism designer > didn't mess up, is superfluous release calls with a NULL handle, > i.e. calling it once with a handle that gets zeroed, and then calling > it again with the zero-ed handle. The big difference here is that > the second call is *NOT* with the same handle, but with a handle > that was zero-ed by a prior release call. This is why I don't like > the current language, that would suggest the wrapper describe above > could be safely called as well (which it can not). > > > > > > The only reason to assume that releasing a zero-length/non-zero value > > buffer is that an implementation might have called malloc(0) in the > > process of outputting a zero-length buffer from gss_unwrap() > > malloc(0) is something that no reasonable gssapi mechanism > implementation should ever do. I think Nico needs to stop basing statements about how the API should work on guesses as to what an implementation might or might not have done with malloc. You, in turn, have no cause for making pronouncements about how an implementation might work. Let's stick to the actual API, folks, instead of speculation about what might be going on below the abstraction boundary. As it stands, RFC2744 requires that implementations zero the length field of a released buffer, but does not require that they change the pointer to NULL. It requires that it be safe to release any output buffer returned by a GSS-API routine, regardless of whether it has zero or non-zero length or whether the value pointer is NULL or not. It does not require that it be safe to release a buffer that has already been released, whether or not the first release changed the value pointer to NULL. So, for the purpose of the document this thread is about, assuming that it is safe to call gss_release_buffer on an already-released buffer is a bad idea. The code should be structured so as to avoid this. That might mean keeping a flag or something. As for the future, it's been suggested that we might want to change the spec so that it is required that gss_release_buffer set the value pointer to NULL and/or that calling gss_release_buffer more than once on the same buffer(*) be safe. If we were designing this from scratch, I'd say that was a good idea. However, we're not, and making the change now adds relatively little value IMHO, since applications would have to work correctly even with GSS-API library implementations that fail to meet the new requirement. As it stands, I think a better improvement would be to RECOMMEND (but not REQUIRE) that implementations do one or both of these things, and simultaneously remind application authors that they cannot depend on double-release to be safe. (*) That is, the same gss_buffer_desc, not a copy, and without any intervening modifications. -- Jeff From mrex@sap.com Mon Jan 20 17:11:04 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 77B2E1A0002 for ; Mon, 20 Jan 2014 17:11:04 -0800 (PST) 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, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 oArZN2h0UpJx for ; Mon, 20 Jan 2014 17:11:01 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6171A027A for ; Mon, 20 Jan 2014 17:11:00 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0L1Av7P003288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jan 2014 02:10:57 +0100 (MET) In-Reply-To: <1390252044.31766.134.camel@minbar.fac.cs.cmu.edu> To: Jeffrey Hutzelman Date: Tue, 21 Jan 2014 02:10:57 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140121011057.C21EE1ABBD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 01:11:04 -0000 Jeffrey Hutzelman wrote: > On Mon, 2014-01-20 at 20:32 +0100, Martin Rex wrote: > > Nico Williams wrote: > > > > > > Nonetheless, it seems clear that the intention is that calling a > > > gss_release/delete_*() function will modify the input/output parameter > > > so that calling it again is safe, so that releasing a zero-length, > > > non-zero valued buffer ought to be safe. > > > > In theory yes, but practice may differ. > > > > What I'm afraid of is wrapper functions that look like this: > > Well, if an app has such a wrapper, then the _wrapper_ is not safe to > call twice. That really has nothing to do with whether > gss_release_buffer is safe to call twice, and the spec for the latter > pretty clearly says it modifies its output. I disagree. Potentially we're fighting about the difference of "call-by-value" vs. "call-by-reference" in C, and what exactly is the meaning of "same foo" when call-by-reference is used. Does "same same" apply when the value is the same. or only when both value and reference/address are the same? With that in mind, a comment like > > /* It is safe to call gss_release_buffer twice on the same buffer. */ is ambiguous and wrong. Discounting empty buffers, calling gss_release_buffer with the same buffer (=same value) more than once is very very probably unsafe. And the fact that gss_release_buffer() is supposed to *CHANGE* the buffer (struct) value should make it clear that the concept of "same buffer" is somewhat unnatural to the GSS-API C-Bindings. What should be safe is calling gss_release_buffer() with an empty buffer. So the important guidance would be to *ALWAYS* create gss_buffer_desc structures initialized with {0, 0} in C. The notion that gss_unwrap() could return a zero-length token is also somewhat flawed. gss_unwrap() returns a message (=app data) if anything. There are no such things as zero-length tokens anywhere throughout GSS-API. And a gssapi mechanism should definitely not rely on the application caller to call gss_release_buffer() on a zero-length message returned from gss_unwrap(). The only sane representation of an empty buffer _output_ value from a gssapi mech is {0, 0}, i.e. be conservative in what you send (=give out). > > > > The API can output zero-length buffers from gss_unwrap(), > > > so the question comes up of whether such buffers can have > > > non-zero values -- the RFC doesn't say. > > > > correct -- gss_unwrap() may return a zero-length output buffer. > > The length of the buffer must be zero for obvious reasons. > > The value of the pointer is then irrelevant, and the gssapi > > mechanism must be able to cope safely with whatever it returns > > along with a zero length. > > Right. If the mech returns a buffer with zero length and a non-NULL > value pointer, then it must be able to cope with gss_release_buffer > being called on that buffer. > > > > > > > > > > > > The other places where the API can output a zero-length token in > > > non-error conditions are gss_init/accept_sec_context() and > > > gss_delete_sec_context, > > > > Nope, neither of these three calls can return a zero-length output token, > > You know, we've discussed that question on several occasions, and I > can't remember ever being able to find something in RFC2743 that says > that. The C bindings happen to make it impossible to tell the > difference between no token and an empty token, which makes using empty > tokens impractical, but if you can find text that prohibits them, please > do point it out. As mentioned above, the GSS-API does not have the concept of zero-length _tokens_. Either there is a token, or there is no token. The reason is simple: you can not securely convey a zero-length token over an insecure communication channel. This is why gss_get_mic() and gss_wrap() must produce non-zero tokens even for zero-length messages. -Martin From jhutz@cmu.edu Tue Jan 21 07:56: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 30A3A1A03D5 for ; Tue, 21 Jan 2014 07:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 RPjRWz4cooGd for ; Tue, 21 Jan 2014 07:56:51 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3EB1A0394 for ; Tue, 21 Jan 2014 07:56:51 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s0LFun7I026532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jan 2014 10:56:50 -0500 (EST) Message-ID: <1390319809.31766.158.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: mrex@sap.com Date: Tue, 21 Jan 2014 10:56:49 -0500 In-Reply-To: <17375_1390266669_s0L1B8NX017524_20140121011057.C21EE1ABBD@ld9781.wdf.sap.corp> References: <17375_1390266669_s0L1B8NX017524_20140121011057.C21EE1ABBD@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 21 Jan 2014 15:56:54 -0000 On Tue, 2014-01-21 at 02:10 +0100, Martin Rex wrote: > Jeffrey Hutzelman wrote: > > On Mon, 2014-01-20 at 20:32 +0100, Martin Rex wrote: > > > Nico Williams wrote: > > > > > > > > Nonetheless, it seems clear that the intention is that calling a > > > > gss_release/delete_*() function will modify the input/output parameter > > > > so that calling it again is safe, so that releasing a zero-length, > > > > non-zero valued buffer ought to be safe. > > > > > > In theory yes, but practice may differ. > > > > > > What I'm afraid of is wrapper functions that look like this: > > > > Well, if an app has such a wrapper, then the _wrapper_ is not safe to > > call twice. That really has nothing to do with whether > > gss_release_buffer is safe to call twice, and the spec for the latter > > pretty clearly says it modifies its output. > > I disagree. > > Potentially we're fighting about the difference of > "call-by-value" vs. "call-by-reference" in C, and what exactly > is the meaning of "same foo" when call-by-reference is used. No, we're arguing over the difference between equal and eq. > Does "same same" apply when the value is the same. or only when both > value and reference/address are the same? Neither. Both my previous message and the comment, and in fact most of the discussion, are about what happens when you call gss_release_buffer on the same gss_buffer_desc structure. Not two separate gss_buffer_desc structures that start out with the same contents (i.e. are equal but not eq). Not one gss_buffer_desc where after the first call you change it to look like what it did before that call. gss_release_buffer operates on the gss_buffer_desc. It frees the memory referenced by that structure, and zeroes the length in that structure, and maybe changes the pointer in that structure to be NULL. Calling it twice with pointers to two different objects is not the same as calling it twice on the same object. > With that in mind, a comment like > > > > > /* It is safe to call gss_release_buffer twice on the same buffer. */ > > is ambiguous and wrong. It's not ambiguous, unless you willfully misinterpret it. It _is_ wrong, which is what started this discussion. I think we've beat this issue into the ground. I think we have something resembling consensus that the example code should avoid double-releasing, even though what it _actually does_ happens to be safe with current major GSS implementations. Therefore, we should stop arguing about it. That leaves open the question of what, if any, changes should be made to the spec. There are some on which I suspect there is mostly agreement, and one which seems to be controversial. Nico seems to believe it should be explicitly safe to call gss_release_buffer() on a gss_buffer_desc that has already been released. I think I agree. But we must be clear here -- we are talking about two calls with _pointers to the same structure_, not calls with pointers to different structures that started out with the same value. In other words, we want to make the example code's assumption safe. > What should be safe is calling gss_release_buffer() with an empty > buffer. So the important guidance would be to *ALWAYS* create > gss_buffer_desc structures initialized with {0, 0} in C. The spec doesn't say this is safe. In fact, the only sorts of buffers for which gss_release_buffer is defined are those returned as outputs from other GSS-API routines. It is not explicitly safe to use it on empty buffers, and it is clearly not safe to use it on buffers where the value is memory allocated by the caller or by some other library. I agree that the spec should be amened to require gss_release_buffer() to work on empty buffers. > The notion that gss_unwrap() could return a zero-length token is > also somewhat flawed. gss_unwrap() returns a message (=app data) > if anything. There are no such things as zero-length tokens anywhere > throughout GSS-API. Find me something in the spec that says that. It is not axiomatic that app protocols do not contain empty messages. > And a gssapi mechanism should definitely not > rely on the application caller to call gss_release_buffer() on a > zero-length message returned from gss_unwrap(). Agreed. > The only sane > representation of an empty buffer _output_ value from a gssapi mech > is {0, 0}, i.e. be conservative in what you send (=give out). Also agreed, though in fact I believe the spec is pretty clear that if the length is 0 you cannot rely on the pointer to be NULL; it might be garbage instead. However, you _can_ rely on gss_release_buffer to work. > > > > The other places where the API can output a zero-length token in > > > > non-error conditions are gss_init/accept_sec_context() and > > > > gss_delete_sec_context, > > > > > > Nope, neither of these three calls can return a zero-length output token, > > > > You know, we've discussed that question on several occasions, and I > > can't remember ever being able to find something in RFC2743 that says > > that. The C bindings happen to make it impossible to tell the > > difference between no token and an empty token, which makes using empty > > tokens impractical, but if you can find text that prohibits them, please > > do point it out. > > As mentioned above, the GSS-API does not have the concept of > zero-length _tokens_. You keep saying that. I asked you to point to _text in the spec_ that says that. Your assertion in email does not carry the same weight as text in a published standards-track RFC. > Either there is a token, or there is no token. > The reason is simple: you can not securely convey a zero-length token > over an insecure communication channel. Um, yes I can? Every app protocol I've seen conveys GSS-API tokens as a length followed by that many bytes. A length of 0, followed by 0 bytes, certainly conveys an empty token. Apps certainly cannot rely on tokens to be self-describing, since they are in fact opaque. -- Jeff From mrex@sap.com Tue Jan 21 10:10: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 C616C1A0150 for ; Tue, 21 Jan 2014 10:10:55 -0800 (PST) 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, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 vlBMSI7qbJrS for ; Tue, 21 Jan 2014 10:10:53 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8D71A00C8 for ; Tue, 21 Jan 2014 10:10:53 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0LIAnrf017330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jan 2014 19:10:49 +0100 (MET) In-Reply-To: <1390319809.31766.158.camel@minbar.fac.cs.cmu.edu> To: Jeffrey Hutzelman Date: Tue, 21 Jan 2014 19:10:49 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140121181049.AD63C1ABBC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 18:10:56 -0000 Jeffrey Hutzelman wrote: > > With that in mind, a comment like > > > > > > > > /* It is safe to call gss_release_buffer twice on the same buffer. */ > > > > is ambiguous and wrong. > > It's not ambiguous, unless you willfully misinterpret it. > It _is_ wrong, which is what started this discussion. > > > I think we've beat this issue into the ground. > I think we have something resembling consensus that the example code > should avoid double-releasing, even though what it _actually does_ > happens to be safe with current major GSS implementations. Therefore, > we should stop arguing about it. OK. > > That leaves open the question of what, if any, changes should be made to > the spec. There are some on which I suspect there is mostly agreement, > and one which seems to be controversial. Nico seems to believe it > should be explicitly safe to call gss_release_buffer() on a > gss_buffer_desc that has already been released. I think I agree. But > we must be clear here -- we are talking about two calls with _pointers > to the same structure_, not calls with pointers to different structures > that started out with the same value. In other words, we want to make > the example code's assumption safe. There is an explicit notion of an empty buffer in the C-Bindings Header file: GSS_C_EMPTY_BUFFER IMHO, it would be difficult for a gssapi mechanism to argue to be compliant to rfc2744 when breaking on a gss_release_buffer() call that is passed an empty buffer, because the semantics of a gss_buffer_desc with {0, 0} contents is well-defined in the GSS-API C-Bindings. http://tools.ietf.org/html/rfc2744#page-6 3.2. String and similar data Many of the GSS-API routines take arguments and return values that describe contiguous octet-strings. All such data is passed between the GSS-API and the caller using the gss_buffer_t data type. This data type is a pointer to a buffer descriptor, which consists of a length field that contains the total number of bytes in the datum, and a value field which contains a pointer to the actual datum: typedef struct gss_buffer_desc_struct { size_t length; void *value; } gss_buffer_desc, *gss_buffer_t; Storage for data returned to the application by a GSS-API routine using the gss_buffer_t conventions is allocated by the GSS-API routine. The application may free this storage by invoking the gss_release_buffer routine. Allocation of the gss_buffer_desc object is always the responsibility of the application; unused gss_buffer_desc objects may be initialized to the value GSS_C_EMPTY_BUFFER. -Martin From kaduk@mit.edu Tue Jan 21 12:34: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 D24431A0241 for ; Tue, 21 Jan 2014 12:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, 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 gQNMsxYPEVfr for ; Tue, 21 Jan 2014 12:34:24 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 909621A0221 for ; Tue, 21 Jan 2014 12:34:24 -0800 (PST) X-AuditID: 1209190f-f790b6d000000c3a-c6-52ded9d04a6a 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id AE.E5.03130.0D9DED25; Tue, 21 Jan 2014 15:34:24 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s0LKYNIE001288 for ; Tue, 21 Jan 2014 15:34:23 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s0LKYLKC012615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Jan 2014 15:34:23 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s0LKYLu6008205; Tue, 21 Jan 2014 15:34:21 -0500 (EST) Date: Tue, 21 Jan 2014 15:34:21 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <1390319809.31766.158.camel@minbar.fac.cs.cmu.edu> Message-ID: References: <17375_1390266669_s0L1B8NX017524_20140121011057.C21EE1ABBD@ld9781.wdf.sap.corp> <1390319809.31766.158.camel@minbar.fac.cs.cmu.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrHvh5r0gg4XrOCyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGenCguOSVfMbvrC2MD4QbSLkZNDQsBEYtu5bywQtpjEhXvr 2boYuTiEBGYzSRycfxbKOc4oMWXxO3YI5waTxOmWLiYIp4FRYu+lf+wg/SwC2hL7709nBLHZ BFQkZr7ZyAZiiwgIS+ze+o4ZxBYWiJW439cDFucUsJc49+gKWJxXwFGi/9h9VoihfYwSSzf1 soIkRAV0JFbvn8ICUSQocXLmEzCbWcBS4t/aX6wTGAVmIUnNQpJawMi0ilE2JbdKNzcxM6c4 NVm3ODkxLy+1SNdELzezRC81pXQTIzgAJfl3MH47qHSIUYCDUYmHN2DXvSAh1sSy4srcQ4yS HExKoryVN4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgNdwDleFMSK6tSi/JhUtIcLErivDc5 7IOEBNITS1KzU1MLUotgsjIcHEoSvD9AhgoWpaanVqRl5pQgpJk4OEGG8wANvwlSw1tckJhb nJkOkT/FqCglzssCjHEhAZBERmkeXC8sQbxiFAd6RZhXCKSKB5hc4LpfAQ1mAhocvQVscEki QkqqgXHuud/ar21vT/XclXHwUHZm/umpW+KmSnj/4BO22vpHZzJ3wy6zubYP+lVPBSVGvbQS rhXjPehW9eOs5g6mR3N1mRe8/dDD/PPWpO4rFW3N1S9Pd6bmLnVbO09R/N/mZXEpHkd+Pohx /7bnttnXy1zCrKYK235GqUelyC9TqKorllQ5emrJ9Q1KLMUZiYZazEXFiQAthvcZ6wIAAA== Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd) 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, 21 Jan 2014 20:34:27 -0000 Sorry for the long silence from me; I was doing a lot of non-computer things over the weekend and didn't really catch up all the way. I think we've basically found agreement, more inline. On Tue, 21 Jan 2014, Jeffrey Hutzelman wrote: > On Tue, 2014-01-21 at 02:10 +0100, Martin Rex wrote: >> Jeffrey Hutzelman wrote: >>> On Mon, 2014-01-20 at 20:32 +0100, Martin Rex wrote: >>>> Nico Williams wrote: >>>>> >> With that in mind, a comment like >> >>> >>> /* It is safe to call gss_release_buffer twice on the same buffer. */ >> >> is ambiguous and wrong. > > It's not ambiguous, unless you willfully misinterpret it. > It _is_ wrong, which is what started this discussion. By the spec it is wrong, yes... > I think we've beat this issue into the ground. > I think we have something resembling consensus that the example code > should avoid double-releasing, even though what it _actually does_ > happens to be safe with current major GSS implementations. Therefore, > we should stop arguing about it. ...even though it is safe in all known implementations. So, I agree that we should stop arguing about it. >> What should be safe is calling gss_release_buffer() with an empty >> buffer. So the important guidance would be to *ALWAYS* create >> gss_buffer_desc structures initialized with {0, 0} in C. > > The spec doesn't say this is safe. In fact, the only sorts of buffers > for which gss_release_buffer is defined are those returned as outputs > from other GSS-API routines. It is not explicitly safe to use it on > empty buffers, and it is clearly not safe to use it on buffers where the > value is memory allocated by the caller or by some other library. I had previously had the impression that Martin conveyed in his reply, namely that GSS_C_EMPTY_BUFFER was special and was required to be handled correctly by gss_release_buffer(); however, a quick search through rfc 2744 does not find anything to support such a claim, so I cannot make it. As such, I think that the easiest way forward for the sample code is to set the buffer to GSS_C_EMPTY_BUFFER after releasing it and check for NULL-ness before releasing it... > I agree that the spec should be amened to require gss_release_buffer() > to work on empty buffers. ... which is a pretty silly thing for application code to have to do, so I agree with this proposal as well. > >> The only sane >> representation of an empty buffer _output_ value from a gssapi mech >> is {0, 0}, i.e. be conservative in what you send (=give out). > > Also agreed, though in fact I believe the spec is pretty clear that if > the length is 0 you cannot rely on the pointer to be NULL; it might be > garbage instead. However, you _can_ rely on gss_release_buffer to > work. I agree. (As a side note, though 0 is a perfectly fine null pointer constant in C99, it is probably nicer to always spell it NULL.) In summary: (1) the sample code in -02 is wrong (2) the sample code in -02 is safe with all known implementations (3) It would be nice to update 2743/2744 to (a) require that gss_release_buffer(GSS_C_EMPTY_BUFFER) is safe, and (b) have gss_release_buffer() set the buffer to GSS_C_EMPTY_BUFFER on output (instead of just setting the length to 0). This is probably out of scope for draft-kaduk-kitten-gss-loop. (4) There is ongoing disagreement about empty tokens, zero-length tokens, absent tokens, and whether applications (are allowed to) use them. -Ben From bnordgren@fs.fed.us Wed Jan 29 11:01:57 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 89FB91A02B6 for ; Wed, 29 Jan 2014 11:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 bhVUuVL3zdl6 for ; Wed, 29 Jan 2014 11:01:52 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id CD1A91A0240 for ; Wed, 29 Jan 2014 11:01:51 -0800 (PST) Received: from mail101-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 29 Jan 2014 19:01:48 +0000 Received: from mail101-tx2 (localhost [127.0.0.1]) by mail101-tx2-R.bigfish.com (Postfix) with ESMTP id 751CC4A0282 for ; Wed, 29 Jan 2014 19:01:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.11; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:error; EFVD:FOP X-SpamScore: 3 X-BigFish: VPS3(zzc85fhdb82hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzz1d7338h17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839h8e2h8e3hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h21a6h2216h22d0h2336h2438h2461h2487h24d7h2516hbe9i1155h) Received-SPF: pass (mail101-tx2: domain of fs.fed.us designates 199.135.140.11 as permitted sender) client-ip=199.135.140.11; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail101-tx2 (localhost.localdomain [127.0.0.1]) by mail101-tx2 (MessageSwitch) id 1391022100893497_26845; Wed, 29 Jan 2014 19:01:40 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.230]) by mail101-tx2.bigfish.com (Postfix) with ESMTP id CAA9580136 for ; Wed, 29 Jan 2014 19:01:40 +0000 (UTC) Received: from mail.usda.gov (199.135.140.11) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 29 Jan 2014 19:01:32 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.84]) by 001FSN2MMR1-001.001f.mgd2.msft.net ([199.135.140.11]) with mapi id 14.03.0174.002; Wed, 29 Jan 2014 19:01:31 +0000 From: "Nordgren, Bryce L -FS" To: "kitten@ietf.org" Thread-Topic: PKCROSS and philosophical tangents... Thread-Index: Ac8dF9EVVIDV+Fq6S8CZNUDcti9KcA== Date: Wed, 29 Jan 2014 19:01:31 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E683B4E@001FSN2MPN1-046.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [170.144.70.233] Content-Type: multipart/alternative; boundary="_000_82E7C9A01FD0764CACDD35D10F5DFB6E683B4E001FSN2MPN1046001_" MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [kitten] PKCROSS and philosophical tangents... 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, 29 Jan 2014 19:01:57 -0000 --_000_82E7C9A01FD0764CACDD35D10F5DFB6E683B4E001FSN2MPN1046001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nico and company. I hope this isn't out of line. I spend quite a lot of time thinking about t= his, as much of my job involves trying to collaborate with others. Tangent #1: What is "authentication"? I would like to propose that authentication is not sharing a secret with a = KDC. In my organization, authentication is a background check by law enforc= ement. Once the paperwork has completed with a successful result, the CIO i= s then instructed to create an account for the authenticated user. Other or= ganizations will have different processes, but the domain admins rarely aut= henticate users themselves. At the very least, HR and the employee's superv= isor does that. In a closed corporate/enterprise environment, this is the whole story. Howe= ver, when you must collaborate with external partners, different authentica= tion methods are introduced. PKCROSS introduces a paradigm where entire foreign domains are authenticate= d by a certificate authority, to varying degrees of rigor. The essential ch= aracteristics of this paradigm are: 1] granular authentication: entire doma= ins are accepted or rejected as an atomic unit; and 2] delegated authentica= tion: the user's identity is only as certain as the policies and procedures= employed to verify that identity prior to giving them an account. In this = situation as with internal users, domain admins will probably not be afford= ed the discretion to choose which foreign domains will be cooperated with. I would like to propose a third type of authentication: a "Sponsored extern= al user". This paradigm assumes a home-user-driven need to cooperate with v= ery specific groups of individuals from other institutions on specific acti= vities. These external users are authenticated to the sponsor by the sponso= r's ongoing observations of their actions during the execution of the proje= ct. Such projects usually occur because the sponsor interacts with the exte= rnal user during the formulation of the project proposal, and there is usua= lly some formal definition of project roles and distribution of money to th= e various participants. Some projects may be informal, and may not involve = funds. However, it is almost certain that prior to sponsoring the external = user, the individuals in question have been authenticated to the sponsor by= some means other than their home domain's credentials. A human web of trus= t may be established, where the sponsor knows the leaders from the foreign = institutions, and these leaders have requested that their support staff or = graduate students be provided access to the project's resources. Characteristics of the "sponsored external user" paradigm are: 1] fine-grai= ned authentication: individuals are accepted or rejected; 2] delegated auth= entication: the "trust anchor" in this case is the sponsor, who may then de= legate the choice of participants to leaders from other institutions; 3] ac= countability and responsibility: the buck stops with the sponsor; 4] human = trust anchor aggregation: if several sponsors affirm several identities fro= m the same foreign realm, confidence in that realm's identity should be hig= h; 5] sponsored external users may or may not come from a foreign realm (e.= g., the home realm may configure a "collaboration realm" to contain all the= untrusted users and hosts as part of a larger effort to manage risk to the= corporate systems.) The bottom line is that cross-realm operation fragments the authentication = process. More tools may be necessary to manage this fragmentation and reduc= e or distribute the administrative burden over the principals in the home r= ealm. To reduce administrative burden, PKCROSS delegates authentication to = a certificate authority and further delegates to the unspecified vetting pr= ocess of the foreign institution. "Sponsored external users" keeps the trus= t anchors closer to home, focuses authentication decisions on a smaller gro= up, and distributes rather than reduces the administrative burden. I think what I would like to see in an RFC or draft is a general discussion= of how to securely set up a collaborative environment using Kerberos, whic= h then dives into specific, standardized technical solutions. I am certain = that PKCROSS will play a large role, but I want to see such a document also= handle the case where the external user does not have a home Kerberos real= m. How does that user get injected into a Kerberized environment in a way t= hat does not imply that any of the large Kerberized organizations are takin= g responsibility for them? Ok, I'd better stop with tangent #1. ;) Thanks for your patience. 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_82E7C9A01FD0764CACDD35D10F5DFB6E683B4E001FSN2MPN1046001_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nico and company.

 

I hope this isn’t out of line. I spend quite a= lot of time thinking about this, as much of my job involves trying to coll= aborate with others.

 

Tangent #1: What is “authentication”?

 

I would like to propose that authentication is not s= haring a secret with a KDC. In my organization, authentication is a backgro= und check by law enforcement. Once the paperwork has completed with a succe= ssful result, the CIO is then instructed to create an account for the authenticated user. Other organizations will = have different processes, but the domain admins rarely authenticate users t= hemselves. At the very least, HR and the employee’s supervisor does t= hat.

 

In a closed corporate/enterprise environment, this i= s the whole story. However, when you must collaborate with external partner= s, different authentication methods are introduced.

 

PKCROSS introduces a paradigm where entire foreign d= omains are authenticated by a certificate authority, to varying degrees of = rigor. The essential characteristics of this paradigm are: 1] granular auth= entication: entire domains are accepted or rejected as an atomic unit; and 2] delegated authentication: the user&#= 8217;s identity is only as certain as the policies and procedures employed = to verify that identity prior to giving them an account. In this situation = as with internal users, domain admins will probably not be afforded the discretion to choose which foreign domai= ns will be cooperated with.

 

I would like to propose a third type of authenticati= on: a “Sponsored external user”. This paradigm assumes a home-u= ser-driven need to cooperate with very specific groups of individuals from = other institutions on specific activities. These external users are authenticated to the sponsor by the sponsor’s ong= oing observations of their actions during the execution of the project. Suc= h projects usually occur because the sponsor interacts with the external us= er during the formulation of the project proposal, and there is usually some formal definition of project roles and= distribution of money to the various participants. Some projects may be in= formal, and may not involve funds. However, it is almost certain that prior= to sponsoring the external user, the individuals in question have been authenticated to the sponsor by some= means other than their home domain’s credentials. A human web of tru= st may be established, where the sponsor knows the leaders from the foreign= institutions, and these leaders have requested that their support staff or graduate students be provided access= to the project’s resources.

 

Characteristics of the “sponsored external use= r” paradigm are: 1] fine-grained authentication: individuals are acce= pted or rejected; 2] delegated authentication: the “trust anchor̶= 1; in this case is the sponsor, who may then delegate the choice of participants to leaders from other institutions; 3] accountabili= ty and responsibility: the buck stops with the sponsor; 4] human trust anch= or aggregation: if several sponsors affirm several identities from the same= foreign realm, confidence in that realm’s identity should be high; 5] sponsored external users may or = may not come from a foreign realm (e.g., the home realm may configure a = 220;collaboration realm” to contain all the untrusted users and hosts= as part of a larger effort to manage risk to the corporate systems.)

 

The bottom line is that cross-realm operation fragme= nts the authentication process. More tools may be necessary to manage this = fragmentation and reduce or distribute the administrative burden over the p= rincipals in the home realm. To reduce administrative burden, PKCROSS delegates authentication to a certificate a= uthority and further delegates to the unspecified vetting process of the fo= reign institution. “Sponsored external users” keeps the trust a= nchors closer to home, focuses authentication decisions on a smaller group, and distributes rather than reduces the admi= nistrative burden.

 

I think what I would like to see in an RFC or draft = is a general discussion of how to securely set up a collaborative environme= nt using Kerberos, which then dives into specific, standardized technical s= olutions. I am certain that PKCROSS will play a large role, but I want to see such a document also handle the = case where the external user does not have a home Kerberos realm. How does = that user get injected into a Kerberized environment in a way that does not= imply that any of the large Kerberized organizations are taking responsibility for them?

 

Ok, I’d better stop with tangent #1. ;) Thanks= for your patience.

 

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_82E7C9A01FD0764CACDD35D10F5DFB6E683B4E001FSN2MPN1046001_-- From nico@cryptonector.com Wed Jan 29 15:56: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 E2ADF1A03D6 for ; Wed, 29 Jan 2014 15:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 DHYTQXPaR8WX for ; Wed, 29 Jan 2014 15:56:42 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5972B1A02F0 for ; Wed, 29 Jan 2014 15:56:42 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 4EA4C2007F118; Wed, 29 Jan 2014 15:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=z0/EMabpQTg97I AX0OI0GmyohqQ=; b=LQ7LZaLMjzVuTdIVUI+hRbXyBGRS+wvCu10220XOqa8fTc 1X8pawSEgQCov/6mVBoAXOFoPANCYfiaHWBwb6xUSI6WbprCnOSKcU8abz2aYnga 0WsycCBlZkXGHPb+Et7b+cRTxdiyibOkAoL5y0KUKLLceMDhwKc39fOfl1tOM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 0AAA12007F106; Wed, 29 Jan 2014 15:56:38 -0800 (PST) Date: Wed, 29 Jan 2014 17:56:38 -0600 From: Nico Williams To: "Nordgren, Bryce L -FS" Message-ID: <20140129235636.GB6916@localhost> References: <82E7C9A01FD0764CACDD35D10F5DFB6E683B4E@001FSN2MPN1-046.001f.mgd2.msft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E683B4E@001FSN2MPN1-046.001f.mgd2.msft.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 29 Jan 2014 23:56:44 -0000 On Wed, Jan 29, 2014 at 07:01:31PM +0000, Nordgren, Bryce L -FS wrote: > I hope this isn't out of line. I spend quite a lot of time thinking > about this, as much of my job involves trying to collaborate with > others. It's not only not out of line, it's very welcomed. > Tangent #1: What is "authentication"? That's a long topic. For the sake of brevity, and to answer your more concrete questions/proposals, I'll not go down this tangent :) > PKCROSS introduces a paradigm where entire foreign domains are > authenticated by a certificate authority, to varying degrees of rigor. A "varying degree of rigor" (I like the phrase) is exactly it. It's already the case in pretty much all distributed authentication systems, including Kerberos w/o PKCROSS, including PKIX, and so on. Grow your world of actual and potential peers large enough and any assumption that "can authenticate" == "someone I can trust" evaporates. > [...] > I would like to propose a third type of authentication: a "Sponsored > external user". This paradigm assumes a home-user-driven need to > [...] This smells to me more like authorization than authentication, but it can be seen either way, and it really depends on what operational details you'd like to have involved. If "sponsorship" means that the sponsor has to provide a KDC-/CA-/IdP-like infrastructure for sponsees, then it's really authentication, but also a pain. If what you have in mind is more like writing down somewhere that a sponsee [whose identity must be possible to establish in roughly the same way every time, perhaps every time after the first] can do this or that, then it's more like authorization, and much easier to manage. Treating this as authorization is much easier, but it does require that you be able to demand repeatability from authentication of the sponsee. You may not care who a peer's IdP/CA/KDC is, as long as it stays the same and the trust path for authenticating the IdP/CA/KDC stays the same. If you can see to this then it's easier to view this as authorization. > 4] human trust anchor aggregation: if several sponsors affirm several > identities from the same foreign realm, confidence in that realm's > identity should be high; You still get this if you treat this as delegated authorization, again, provided that you have a way to authenticate the "several identities'" [presumably] common credential issuer reliably. Nico -- From bnordgren@fs.fed.us Wed Jan 29 21:30:35 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 C65221A0356 for ; Wed, 29 Jan 2014 21:30:35 -0800 (PST) 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 ieSu-334mZrn for ; Wed, 29 Jan 2014 21:30:32 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 473211A0194 for ; Wed, 29 Jan 2014 21:30:31 -0800 (PST) Received: from mail49-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Thu, 30 Jan 2014 05:30:27 +0000 Received: from mail49-ch1 (localhost [127.0.0.1]) by mail49-ch1-R.bigfish.com (Postfix) with ESMTP id 4D81D40218; Thu, 30 Jan 2014 05:30:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.14; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz542I1432Idb82hdc4mzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzz1de098h17326ah8275bh1de097h186068h5eeeKz2fh109h2a8h839h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24d7h2516h1155h) Received-SPF: pass (mail49-ch1: domain of fs.fed.us designates 199.135.140.14 as permitted sender) client-ip=199.135.140.14; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1 (MessageSwitch) id 139105982691393_7323; Thu, 30 Jan 2014 05:30:26 +0000 (UTC) Received: from CH1EHSMHS038.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail49-ch1.bigfish.com (Postfix) with ESMTP id 8434B2004E; Thu, 30 Jan 2014 05:30:05 +0000 (UTC) Received: from mail.usda.gov (199.135.140.14) by CH1EHSMHS038.bigfish.com (10.43.69.247) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 30 Jan 2014 05:30:02 +0000 Received: from 001FSN2MMR1-015.001f.mgd2.msft.net (199.135.140.70) by 001FSN2MMR1-004.001f.mgd2.msft.net (199.135.140.14) with Microsoft SMTP Server (TLS) id 14.3.174.2; Thu, 30 Jan 2014 05:30:01 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.84]) by 001FSN2MMR1-015.001f.mgd2.msft.net ([199.135.140.70]) with mapi id 14.03.0174.002; Thu, 30 Jan 2014 05:30:01 +0000 From: "Nordgren, Bryce L -FS" To: Nico Williams Thread-Topic: [kitten] PKCROSS and philosophical tangents... Thread-Index: Ac8dF9EVVIDV+Fq6S8CZNUDcti9KcAANe5wAAAZh4HA= Date: Thu, 30 Jan 2014 05:30:00 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E683D80@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E683B4E@001FSN2MPN1-046.001f.mgd2.msft.net> <20140129235636.GB6916@localhost> In-Reply-To: <20140129235636.GB6916@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 30 Jan 2014 05:30:36 -0000 New comment --- PKCROSS seems to me to be about providing agility while preserving accurate= identification. It seems that a section on distributed CA schemes may be w= arranted, if only to put the full PKI scheme in context. OTOH: Is it worthw= hile to allow implementers to provide alternative methods of evaluating tru= st in certificates? Omar, 2009 gives an overview that I found helpful. I pu= t some references below which may be useful for the draft. --- Response --- This is another long post, but it can be summed up as "agile is good", "the= whole world is not Kerberos", "let users induct their pals into the Kerber= os universe" and "share the load". The various axioms and corollarys below= are the main points I'd want to see given technical expression. > -----Original Message----- > > Tangent #1: What is "authentication"? > > That's a long topic. For the sake of brevity, and to answer your more > concrete questions/proposals, I'll not go down this tangent :) Sorry for the lengthy post. I need to hammer out a solid conceptual framewo= rk before working out technical issues (which then need to tie back into th= e conceptual framework pretty directly). > > PKCROSS introduces a paradigm where entire foreign domains are > > authenticated by a certificate authority, to varying degrees of rigor. > > A "varying degree of rigor" (I like the phrase) is exactly it. :) > Grow your world of actual and potential peers large enough and any > assumption that "can authenticate" =3D=3D "someone I can trust" evaporate= s. Ahh, axiom #1: Accurate identification does not equal trustworthiness (e.g.= , I've known him all his life; he's still a jerk) > This smells to me more like authorization than authentication, but it can= be > seen either way, and it really depends on what operational details you'd = like > to have involved. If "sponsorship" means that the sponsor has to provide= a > KDC-/CA-/IdP-like infrastructure for sponsees, then it's really authentic= ation, > but also a pain. If what you have in mind is more like writing down > somewhere that a sponsee [whose identity must be possible to establish in > roughly the same way every time, perhaps every time after the first] can = do > this or that, then it's more like authorization, and much easier to manag= e. My conceptual model is an agile, Kerberized, collaborative environment. I e= xpect that some partners may not have Kerberos identities in any realm. (Pe= rhaps they are a contractor working out of their home.) A conceptual mechan= ism is needed to induct these poor wayward souls into the realm of "The Ide= ntified" so that everyone can play in the same sandbox. Those who work for big organizations with Kerberos infrastructure have been= "sponsored" by the organization. This relationship is made explicit by the= fact that their credentials are principals in the mother organization's re= alm. When credentialed individuals sponsor a wayward, non-Kerberized soul, I thi= nk this also needs to be explicit....and of course distinct from the "organ= izationally sponsored users". And since the topic is cross-domain trusts, t= he KDCs need to be able to communicate this distinction to each other. It c= an be simple, like creating principles in a subdomain with a standard name = (contractor_c@WAYWARD.EXAMPLE.COM). Or perhaps using the sponsor's complete= principal ID as the instance (contractor_c/me@EXAMPLE.COM @ EXAMPLE.COM). = Or a combination of both. Or something else. Axiom #2: Can't be authorized until you're authenticated. Corrolary: Authentication involves identifying both you and your sponsor... > You may not care who a peer's IdP/CA/KDC is, as long as it stays the same > and the trust path for authenticating the IdP/CA/KDC stays the same. If = you > can see to this then it's easier to view this as authorization. I'll do you one better. I don't care who a peer's IdP/CA/KDC is ever. I als= o don't care if they don't have one at all. ;) If I tell a cooperator to co= nnect to my system and they can't because a trust path isn't configured rig= ht...well, I want a way to assert to the system that the credentials presen= ted are indeed valid even if they're self-signed (for a small-potatoes KDC)= ...or that new Kerberos credentials should be allocated with me as the spon= sor (for someone who doesn't want to stand up their own KDC). And then I ex= pect the system to get out of the way. :) It's trust path is me. Axiom #3: Users will form collaborations without regard to the compatibilit= y of the partner organizations' infrastructure. Corollary: It should be possible to distribute the extra administrative ove= rhead of technologically ill-conceived collaborations. Corollary: Friends don't make friends learn Kerberos. :) > > 4] human trust anchor aggregation: if several sponsors affirm several > > identities from the same foreign realm, confidence in that realm's > > identity should be high; > > You still get this if you treat this as delegated authorization, again, p= rovided > that you have a way to authenticate the "several identities'" > [presumably] common credential issuer reliably. I brought this up because my spidey senses are tingling. Too early to say f= or sure, but ... well, currently, KDCs act as central points of control ove= r some sphere of influence. It seems that if the peons within that sphere o= f influence start making decisions about who they choose to trust, KDCs cou= ld also act as a concentrator for trust related information...In my world w= e call such things "Decision Support Systems" and we pay big money to devel= op them. There is probably value here...somehow... Bryce Some references : Naranjo, J. A. M., F. Cores, L. G. Casado, and F. Guirado. "Fully Distribut= ed Authentication with Locality Exploitation for the CoDiP2P Peer-to-Peer C= omputing Platform." The Journal of Supercomputing 65, no. 3 (December 5, 20= 12): 1037-1049. doi:10.1007/s11227-012-0842-2. http://www.cs.georgetown.edu= /~clay/classes/spring2013/papers/Fully_distributed_authentication_with_loca= lity_exploitation_for_the_CoDiP2P_peer-to-peer_computing_platform.pdf Omar, Mawloud, Yacine Challal, and Abdelmadjid Bouabdallah. "Reliable and F= ully Distributed Trust Model for Mobile Ad Hoc Networks." Computers & Secur= ity 28, no. 3-4 (May 2009): 199-214. doi:10.1016/j.cose.2008.11.009. http://hal.archives-ouvertes.fr/docs/00/38/90/20/PDF/net-trust-19-02-08.pdf 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 kenh@cmf.nrl.navy.mil Fri Jan 31 09:50: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 D09101A05AA for ; Fri, 31 Jan 2014 09:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.535] 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 Fag20OS1AcCh for ; Fri, 31 Jan 2014 09:50:38 -0800 (PST) Received: from hedwig.cmf.nrl.navy.mil (hedwig.cmf.nrl.navy.mil [IPv6:2001:480:23:c::13]) by ietfa.amsl.com (Postfix) with ESMTP id 3808A1A0583 for ; Fri, 31 Jan 2014 09:50:37 -0800 (PST) Received: from zoolander.cmf.nrl.navy.mil (zoolander.cmf.nrl.navy.mil [134.207.12.40]) (authenticated bits=56) by hedwig.cmf.nrl.navy.mil (8.14.2/8.14.2) with ESMTP id s0VHoV9a010086 for ; Fri, 31 Jan 2014 12:50:33 -0500 Message-Id: <201401311750.s0VHoV9a010086@hedwig.cmf.nrl.navy.mil> From: Ken Hornstein To: "kitten@ietf.org" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E683D80@001FSN2MPN1-046.001f.mgd2.msft.net> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 31 Jan 2014 12:50:32 -0500 X-NRLCMF-Spam-Score: () hits=0 User Authenticated X-NRLCMF-Virus-Scanned: No virus found X-Scanned-By: MIMEDefang 2.68 on 134.207.12.162 Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 31 Jan 2014 17:54:36 -0000 >PKCROSS seems to me to be about providing agility while preserving >accurate identification. It seems that a section on distributed CA >schemes may be warranted, if only to put the full PKI scheme in >context. OTOH: Is it worthwhile to allow implementers to provide >alternative methods of evaluating trust in certificates? Omar, 2009 >gives an overview that I found helpful. I put some references below >which may be useful for the draft. I come from a relatively flexible universe where we do a lot of cross-realm, so I've thought a significant amount of this (also, we have a lot of users who aren't part of our organization). Here are my thoughts: - I personally am not a fan of the term "agile" in this context, because it's too vague (what, exactly, do you mean by that?). - PKCROSS seems to me to want to give you the ability to do regular old Kerberos cross-realm without having to actually set up symmetric cross-realm keys ... and I've done that a lot, and I can testify that it's a huge pain. But it's still Kerberos aside from that. - If you need Kerberos to access your site's resources, then you have two choices: either a) do cross-realm with some place they do have a principal with, or b) give them a principal on your KDC. That's all backended by tedious paperwork and ACL settings, but I think in terms of actual technology that's what your choices are. - In my experience the TECHNICAL issues are relatively straightforward; it's dealing with management that's the challenge. I looked at the papers you posted; they seem interesting, but if the goal is to use one of those systems to get a Kerberos TGT ... well, I'd wonder what the advantage would be compared to one of the existing systems. --Ken From bnordgren@fs.fed.us Fri Jan 31 11:06: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 56C6C1A0286 for ; Fri, 31 Jan 2014 11:06:20 -0800 (PST) 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 yHG68Ae6anwq for ; Fri, 31 Jan 2014 11:06:18 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 90C711A03F5 for ; Fri, 31 Jan 2014 11:06:17 -0800 (PST) Received: from mail219-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 31 Jan 2014 19:06:13 +0000 Received: from mail219-tx2 (localhost [127.0.0.1]) by mail219-tx2-R.bigfish.com (Postfix) with ESMTP id 82E50BC029C; Fri, 31 Jan 2014 19:06:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.16; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzd772hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzzz2fh109h2a8h839h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24d7h2516h1155h) Received-SPF: pass (mail219-tx2: domain of fs.fed.us designates 199.135.140.16 as permitted sender) client-ip=199.135.140.16; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail219-tx2 (localhost.localdomain [127.0.0.1]) by mail219-tx2 (MessageSwitch) id 1391195161141997_23973; Fri, 31 Jan 2014 19:06:01 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.229]) by mail219-tx2.bigfish.com (Postfix) with ESMTP id 14D846005F; Fri, 31 Jan 2014 19:06:01 +0000 (UTC) Received: from mail.usda.gov (199.135.140.16) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 31 Jan 2014 19:05:58 +0000 Received: from 001FSN2MMR1-012.001f.mgd2.msft.net (199.135.140.59) by 001FSN2MMR1-006.001f.mgd2.msft.net (199.135.140.16) with Microsoft SMTP Server (TLS) id 14.3.174.2; Fri, 31 Jan 2014 19:05:57 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.84]) by 001FSN2MMR1-012.001f.mgd2.msft.net ([199.135.140.59]) with mapi id 14.03.0174.002; Fri, 31 Jan 2014 19:05:57 +0000 From: "Nordgren, Bryce L -FS" To: Ken Hornstein , "kitten@ietf.org" Thread-Topic: [kitten] PKCROSS and philosophical tangents... Thread-Index: Ac8dF9EVVIDV+Fq6S8CZNUDcti9KcAANe5wAAAZh4HAAUWokAAAA0odg Date: Fri, 31 Jan 2014 19:05:56 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E684319@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E683D80@001FSN2MPN1-046.001f.mgd2.msft.net> <201401311750.s0VHoV9a010086@hedwig.cmf.nrl.navy.mil> In-Reply-To: <201401311750.s0VHoV9a010086@hedwig.cmf.nrl.navy.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [170.144.68.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 31 Jan 2014 19:06:20 -0000 Good to hear from someone who's done it. I haven't, so I mainly have questi= ons instead of answers. Perhaps I should "briefback" my understanding of th= e motivation of PKCROSS by rephrasing the intro section: Axiom: Successful large-scale Kerberos deployments authorize users to maint= ain their own authentication tokens. (e.g., I can change my own password) Corollary: The lack of the ability for principals (KDC admins) to update th= eir own tokens in a foreign KDC has inhibited the formation of Kerberos fed= erations, and requires manual coordination between admins which is cumberso= me and causes downtime. In this light, I understand PKCROSS to be a means of automatically keying y= our KDC's credentials in a foreign system. However, it is unclear to me how= these credentials get updated when they inevitably expire (or are stolen).= Is that section TBD or am I just dense? I took the draft to say that the i= nitial certificate must stay the same forever or else risk being rejected a= s a MITM attack. I'm willing to be persuaded, but I'm not quite seeing how = the draft addresses the deficiencies it identifies. PKCROSS to initially key your principal, plus a means to subsequently maint= ain the authentication tokens for your principal? Well, that addresses the = problem statement. It's possible that account maintenance could be facilitated with a series o= f recommendations and the corresponding security analyses. Expose your pass= word-changing interface to the wide world and advertise which set of admin = tools (MIT/heimdal/MS) are compatible? Stand up a web app which lets you lo= g in and manage your credentials? Extend the base standard with a "princip= al management" message exchange? Dunno. It's probably important to specify = that sites wishing to support federation SHOULD do certain things, one of w= hich is to ensure that offsite (outside firewall), non-home-realm principal= s have the means to manage their credentials. > I looked at the papers you posted; they seem interesting, but if the goal= is to > use one of those systems to get a Kerberos TGT ... well, I'd wonder what = the > advantage would be compared to one of the existing systems. My purpose in bringing up those papers was not so much to propose a means o= f getting a TGT as to ask about alternative means of trust evaluation for t= he CA which signed the foreign KDCs certificate. Does the standard need to = specify how trust is evaluated? Should it narrow the field to a handful of = identifiable algorithms? Should it start simple but allow for growth? Thanks for your time! 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. From kenh@cmf.nrl.navy.mil Fri Jan 31 11:31: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 455781A0292 for ; Fri, 31 Jan 2014 11:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 m4tHexoQaCIv for ; Fri, 31 Jan 2014 11:31:40 -0800 (PST) Received: from hedwig.cmf.nrl.navy.mil (hedwig.cmf.nrl.navy.mil [IPv6:2001:480:23:c::13]) by ietfa.amsl.com (Postfix) with ESMTP id 4969E1A0286 for ; Fri, 31 Jan 2014 11:31:40 -0800 (PST) Received: from zoolander.cmf.nrl.navy.mil ([IPv6:2001:480:23:c:3e07:54ff:fe7d:3022]) (authenticated bits=56) by hedwig.cmf.nrl.navy.mil (8.14.2/8.14.2) with ESMTP id s0VJVXuB010812; Fri, 31 Jan 2014 14:31:34 -0500 Message-Id: <201401311931.s0VJVXuB010812@hedwig.cmf.nrl.navy.mil> From: Ken Hornstein To: "Nordgren, Bryce L -FS" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E684319@001FSN2MPN1-046.001f.mgd2.msft.net> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 31 Jan 2014 14:31:34 -0500 X-NRLCMF-Spam-Score: () hits=0 User Authenticated X-NRLCMF-Virus-Scanned: No virus found X-Scanned-By: MIMEDefang 2.68 on IPv6:2001:480:23:c::13 Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 31 Jan 2014 19:31:42 -0000 >Axiom: Successful large-scale Kerberos deployments authorize users to >maintain their own authentication tokens. (e.g., I can change my own >password) So, that gets sort of complicated. I'll explain what we did. There are two general levels of access we have to our systems. "Interactive", and "Everything else" (they don't really have these sort of formal names, but that's what it ended up being). "Interactive" is an interactive login. In other words, you login in with Kerberos rlogin/ssh/whatever and get an interactive shell to do stuff (obviously this is all Unix based). "Everything else" is sort of vague, but in general it refers to stuff that doesn't require an interactive login or something that looks like that (consider it things that don't require a Unix user account). This could be things like web pages or filesystem access. We only accept interactive logins from a relatively small number of Kerberos realms (when I say "relatively" I mean "relative to the total number of KDCs we cross realm with"). We control the mapping from a particular foreign-realm principal to local Unix account. That mapping only happens after a formal account process has been completed. That federated group of KDCs all have the same policies, so there's no issue there in terms of someone not meeting your security policies. All of the people in this federation receive funding from the same source, which helped generated a uniform security policy. "Everything else" users have a lot lower access, and generally only get used for a few things. But it's valuable to have that ability. >Corollary: The lack of the ability for principals (KDC admins) >to update their own tokens in a foreign KDC has inhibited the formation >of Kerberos federations, and requires manual coordination between admins >which is cumbersome and causes downtime. When you say "update their own tokens in a foreign KDC", do you mean the cross-realm principals? Because that is not true; we rekey our cross-realm principals on a regular schedule. Okay, it may be cumbersome and require manual admin intervention, but it does not require downtime. And actually, you COULD rekey cross-realm principals automatically with some programming; it's one of those things that's on my list to do. >In this light, I understand PKCROSS to be a means of automatically >keying your KDC's credentials in a foreign system. However, it is >unclear to me how these credentials get updated when they inevitably >expire (or are stolen). Is that section TBD or am I just dense? I >took the draft to say that the initial certificate must stay the same >forever or else risk being rejected as a MITM attack. I'm willing to >be persuaded, but I'm not quite seeing how the draft addresses the >deficiencies it identifies. Assuming we're talking about draft-williams-kitten-krb5-pkcross-02.txt ... as I read it, expiration/stolen principals are dealt with the same way you'd deal with other stolen credentials in Kerberos. Generally tickets expire in a relatively short timeframe, and you'd need to do a new PKCROSS exchange every time you get a new ticket. Same issues you have with Kerberos. >It's possible that account maintenance could be facilitated >with a series of recommendations and the corresponding security >analyses. Expose your password-changing interface to the wide >world and advertise which set of admin tools (MIT/heimdal/MS) are >compatible? Well, we already expose our password changing interface to the world, because otherwise how are users going to change their passwords? >My purpose in bringing up those papers was not so much to propose a >means of getting a TGT as to ask about alternative means of trust >evaluation for the CA which signed the foreign KDCs certificate. Does >the standard need to specify how trust is evaluated? Should it narrow >the field to a handful of identifiable algorithms? Should it start >simple but allow for growth? Hmmm ... my opinion is how trust should be evaluated is out of scope for a document like PKCROSS. That should be done on a site-by-site basis. --Ken From eagle@eyrie.org Fri Jan 31 12:18:22 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 DF06F1A0423 for ; Fri, 31 Jan 2014 12:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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_GlaIb_xyG2 for ; Fri, 31 Jan 2014 12:18:21 -0800 (PST) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 27D3F1A03F5 for ; Fri, 31 Jan 2014 12:18:21 -0800 (PST) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9FD193431A5; Fri, 31 Jan 2014 12:18:17 -0800 (PST) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 218443432D4; Fri, 31 Jan 2014 12:18:16 -0800 (PST) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 538752F4DA; Fri, 31 Jan 2014 12:18:15 -0800 (PST) From: Russ Allbery To: "Nordgren\, Bryce L -FS" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E684319@001FSN2MPN1-046.001f.mgd2.msft.net> (Bryce L. Nordgren's message of "Fri, 31 Jan 2014 19:05:56 +0000") Organization: The Eyrie References: <82E7C9A01FD0764CACDD35D10F5DFB6E683D80@001FSN2MPN1-046.001f.mgd2.msft.net> <201401311750.s0VHoV9a010086@hedwig.cmf.nrl.navy.mil> <82E7C9A01FD0764CACDD35D10F5DFB6E684319@001FSN2MPN1-046.001f.mgd2.msft.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Fri, 31 Jan 2014 12:18:15 -0800 Message-ID: <87bnyrc3co.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 31 Jan 2014 20:18:23 -0000 "Nordgren, Bryce L -FS" writes: > It's possible that account maintenance could be facilitated with a > series of recommendations and the corresponding security > analyses. Expose your password-changing interface to the wide world and > advertise which set of admin tools (MIT/heimdal/MS) are compatible? Password changes are interoperable provided that they're limited to operations that can be performed via the kpasswd protocol (and provided you can deal with the kpasswd protocol, which is rather broken, but usually workable in practice provided everyone understands the required assumptions). You only have to care about the different admin protocols if you need to support operations other than password change. -- Russ Allbery (eagle@eyrie.org) From lukeh@padl.com Fri Jan 31 18:07: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 119A81ACCF4 for ; Fri, 31 Jan 2014 18:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 s338sJ5u21rR for ; Fri, 31 Jan 2014 18:07:07 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 21CD71ACCE3 for ; Fri, 31 Jan 2014 18:07:06 -0800 (PST) Received: by us.padl.com with ESMTP id s1126dG6018264; Fri, 31 Jan 2014 21:06:52 -0500 From: Luke Howard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 1 Feb 2014 13:06:38 +1100 Message-Id: <22979F1F-33E3-4073-88EF-A491965B01B7@padl.com> To: "kitten@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED, AWL, BAYES_00, TVD_SPACED_SUBJECT_WORD3, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.6 Cc: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: [kitten] CredUI 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, 01 Feb 2014 02:07:09 -0000 Announcing a new open source project is pretty off-topic for ietf-kitten = so I'll keep it brief and to a URL: https://github.com/PADL/CredUI On-topic is that it does offer a way (much inspired by the equivalent = SSPI APIs) to do interactive credential acquisition with prompting with = very limited changes to GSS-API. Essentially the changes are: * a new supplementary status code, GSS_S_PROMPTED_NEEDED, indicated the = prompting is needed (this can be combined with other GSS-API error = codes). This can be returned by gss_init_sec_context(). * an API/SPI to acquire a credential given an arbitrary dictionary = (currently we implemented this using gss_set_cred_option(), as that can = output a credential, but a new entry point would be cleaner) * a new, independent, API and plugin abstraction for prompting the user, = generating said dictionary, etc Now, the CredUI implementation above is very OS X-specific, but one = could certainly generalise the interaction with GSS-API (which would = mostly come down to defining a GSS-API dictionary type, accessors, and = well known keys). -- Luke=