From shawn.emery@oracle.com Tue Aug 2 14:21:03 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2CE5E8008 for ; Tue, 2 Aug 2011 14:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvL89OSGXvLq for ; Tue, 2 Aug 2011 14:21:02 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id C23D85E8007 for ; Tue, 2 Aug 2011 14:21:02 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p72LLA2U023481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 2 Aug 2011 21:21:12 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p72LLAxC023273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Aug 2011 21:21:10 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p72LL542030634 for ; Tue, 2 Aug 2011 16:21:05 -0500 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Aug 2011 14:21:04 -0700 Message-ID: <4E386A35.7080105@oracle.com> Date: Tue, 02 Aug 2011 15:20:53 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.18) Gecko/20110704 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------040604080402050005080706" X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E386A48.0090:SCFMA922111,ss=1,re=-4.000,fgs=0 Subject: [kitten] IETF 81: kitten minutes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:21:03 -0000 This is a multi-part message in MIME format. --------------040604080402050005080706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please review the minutes for the kitten session during IETF 81 and let us know if there are any corrections or omissions: http://www.ietf.org/proceedings/81/minutes/kitten.html Shawn. -- --------------040604080402050005080706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review the minutes for the kitten session during IETF 81 and let us know if there are any corrections or omissions: http://www.ietf.org/proceedings/81/minutes/kitten.html Shawn. -- --------------040604080402050005080706-- From nico@cryptonector.com Sat Aug 13 20:04:19 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4121F85AB for ; Sat, 13 Aug 2011 20:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRVkxHOlKqkT for ; Sat, 13 Aug 2011 20:04:18 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B6E0821F85BB for ; Sat, 13 Aug 2011 20:04:18 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 1C64521DE6F for ; Sat, 13 Aug 2011 20:05:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=HSImUol5OGFGjhnyY13AeagOw55QpVBO/3UAxBSqE0DU 9rBOnLQwly4adP49We4Uy+TkqttDie1qOIuNBRHB32jba59cHap9VTpZ8YSI3L5L Ht9z5M3J/ZPbuzAUumgGO+sTAZOlKpSD/G1iqbJOrzEtZ1Z9pWthG4DEE4dKFOw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=UNH7X8ITSQFa7g/r8Yzmihywjy0=; b=aOrcUxWcJFk huJ3JVeF6HYFBHAaLLRbcJEi5fpdsEJn93/eDihTdLF+LELolVMLa1SAtlaQBpiD hGg3u4/ggPjJ3eP46kEOLn2XOZCgWiH6891ljTJ0P+rbaGd+adAMse2yRbnI4fG/ zMLmby4DSgDPFtJyhbQ0RkRTiTGvf1SU= Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id E531B21DE58 for ; Sat, 13 Aug 2011 20:04:59 -0700 (PDT) Received: by iye1 with SMTP id 1so4827145iye.27 for ; Sat, 13 Aug 2011 20:04:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.248.28 with SMTP id v28mr1061968wfh.66.1313291099235; Sat, 13 Aug 2011 20:04:59 -0700 (PDT) Received: by 10.68.54.10 with HTTP; Sat, 13 Aug 2011 20:04:59 -0700 (PDT) Date: Sat, 13 Aug 2011 22:04:59 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Rcache avoidance X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 03:04:19 -0000 The design for GSS consists of: - a new GSS req_flag named, say, GSS_C_IMPLICIT_CONFIRMATION or GSS_C_RCACHE_AVOIDANCE_OK; - update RFC2743 to indicate that GSS_Unwrap() and GSS_VerifyMIC() MAY include the GSS_S_DUPLICATE_TOKEN supplementary major status code when handling a PROT_READY token from the peer if the local end wants to avoid using an rcache but depends on completing the security context and/or consuming a non-PROT-READY per-msg token from the peer. Additionally the Kerberos mechanism will be updated to state: - how to indicate rcache avoidance by the initiator (see separate thread that I just started on the KRB-WG list); - that acceptors MAY use an rcache to handle PROT_READY tokens when the initiator indicated that rcache avoidance is OK. Question 1: do we want a req_flag by which the initiator could indicate its intention to make use of the PROT_READY state if available? I think it'd be useful to have this. Question 2: do we want a supplementary status code by which to indicate that a per-message token was a PROT_READY token? Nico -- From hartmans@painless-security.com Thu Aug 18 10:38:42 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEEA11E809E for ; Thu, 18 Aug 2011 10:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.898 X-Spam-Level: X-Spam-Status: No, score=-103.898 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWL0iS7xqbsg for ; Thu, 18 Aug 2011 10:38:41 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7221F85EE for ; Thu, 18 Aug 2011 10:38:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7DB4C2016A for ; Thu, 18 Aug 2011 13:42:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 99D0342B7; Thu, 18 Aug 2011 13:39:31 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Thu, 18 Aug 2011 13:39:31 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [kitten] [Leif Johansson] Re: [abfab] EAP naming attribute document X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:38:42 -0000 --=-=-= Consider it an early IETF last call comment that multiple people think we should add a security considerations note about multiple attribute values from different issuers. I bet Nico supports this as well based on conversations we've had. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Thu, 18 Aug 2011 09:21:19 -0400 X-Sieve: CMU Sieve 2.2 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mail.suchdamage.org (Postfix) with ESMTP id 9A157203BA for ; Thu, 18 Aug 2011 09:21:16 -0400 (EDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EDA21F8B01; Thu, 18 Aug 2011 06:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1313673477; bh=2W7wpxaL8O+faaEZO0AXVXkkqB+/CxvO/eGISetPKl8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=aA4Zs0fkigvQ/rmeIgId8I2X3lrMq5IDkhAV3mGJY2BlxPTh7FuCyLYgOoTViz/gA mN4HQDBSkosySLwsdoXf/YTyC+x6E+pBnT5fQOnTdxoe+g/zRxWPDJl43rxAZhg12X YhzQpxpLL3p8XzF+rpm1Y6x/YMdmr7WGz9w7Nojk= X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089921F8AE6 for ; Thu, 18 Aug 2011 06:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHyP7KaNlX1O for ; Thu, 18 Aug 2011 06:17:55 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9321F8ABB for ; Thu, 18 Aug 2011 06:17:55 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p7IDIhSv029108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Aug 2011 15:18:48 +0200 (CEST) Message-ID: <4E4D1133.1000805@mnt.se> Date: Thu, 18 Aug 2011 15:18:43 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: abfab@ietf.org References: <008c01cc5d36$b4da6310$1e8f2930$@nwlink.com> <00a801cc5d6f$8eebc1b0$acc34510$@augustcellars.com> <432EC99B-2F2D-4672-A958-DCB0DBEA7CFD@padl.com> <1EA07D89-B8E7-4CB6-B188-2E0EEA88D2EC@padl.com> In-Reply-To: <1EA07D89-B8E7-4CB6-B188-2E0EEA88D2EC@padl.com> X-Enigmail-Version: 1.1.1 Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond $the web$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: abfab-bounces@ietf.org Errors-To: abfab-bounces@ietf.org X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Aug 18 09:21:19 2011 X-DSPAM-Confidence: 0.9977 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4e4d11cf19271238471012 X-DSPAM-Factors: 27, To*ietf.org, 0.00010, List-Help*request, 0.00010, From*Leif Johansson , 0.00010, List-Post*+On, 0.00034, List-Subscribe*, 0.00250, References*mit.edu>, 0.00250, Received*mail.ietf.org+(mail.ietf.org, 0.00306, Received*(mail.ietf.org, 0.00306, >>+>>, 0.00306, >>+>>, 0.00306, Received* Right you are. > > On 18/08/2011, at 12:49 PM, Sam Hartman wrote: > >>>>>>> "Luke" == Luke Howard writes: >> >>>>> GSS naming extensions does not really support this; I'd say the >>>>> behavior should be undefined until GSS has a story for this. >>>> >>>> So I would expect that current GSS behavior would be to say >>>> randomly return one of them rather than fail. An issue to >>>> potentially raise on kitten. >> >> Luke> GSS naming extensions does support multiple valued attributes. >> >> I don't think it's reasonable to use that support if different values >> come from different issuers. +1 that actually sounds like something that should go into a security considerations text somewhere. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5NETMACgkQ8Jx8FtbMZndjaQCgl/SSTfkWYx04lsI9yyBKffie 32sAn0s9ve4DUn8wM9IyfP2hj8GmBhF6 =7CqP -----END PGP SIGNATURE----- _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab --=-=-=-- From internet-drafts@ietf.org Tue Aug 30 02:31:35 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A9A21F8B7E; Tue, 30 Aug 2011 02:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkQbccpA-Kp8; Tue, 30 Aug 2011 02:31:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435C021F88B6; Tue, 30 Aug 2011 02:31:35 -0700 (PDT) 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: 3.60 Message-ID: <20110830093135.17494.67187.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 02:31:35 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 09:31:35 -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= Generation Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-00.txt Pages : 27 Date : 2011-08-29 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-00.txt From cantor.2@osu.edu Tue Aug 30 19:24:03 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3F21F8D8D for ; Tue, 30 Aug 2011 19:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.242 X-Spam-Level: X-Spam-Status: No, score=-4.242 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32cE4eGOdJhB for ; Tue, 30 Aug 2011 19:24:02 -0700 (PDT) Received: from defang16.it.ohio-state.edu (defang16.it.ohio-state.edu [128.146.216.130]) by ietfa.amsl.com (Postfix) with ESMTP id D0D6721F8D8C for ; Tue, 30 Aug 2011 19:24:00 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p7V2PR99008861 for ; Tue, 30 Aug 2011 22:25:28 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%11]) with mapi; Tue, 30 Aug 2011 22:25:27 -0400 From: "Cantor, Scott" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-00.txt Thread-Index: AQHMZvfSW6EvTnZLrE+5V+1F4K30XpU2PImA Date: Wed, 31 Aug 2011 02:25:23 +0000 Message-ID: In-Reply-To: <20110830093135.17494.67187.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.130 Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 02:24:03 -0000 On 8/30/11 5:31 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 The current status of the document is that it's been slightly revised to reference the latest SAML draft it depends on, and a non-interoperable feature that isn't compatible with the use of channel binding was removed. I also copied relevant text on matching TLS server identity to GSS target name from the GSS SAML draft. Most of the "meat" of this work is really in the SAML profile document it references, including the bulk of the support for channel binding, and the holder of key support. There are a number of open issues I want to work through, probably with Sam's and Simon's help based on past offers of assistance: - per-message tokens, etc, currently not supported, but should be possible with some help, and I need to do some reading of how Kerberos supports this first - SAML naming in GSS and alignment with ABFAB work in this area - conformance material: in OASIS we have explicit conformance text outlining what implementers have to support when there are options involved; this seems to be done more informally throughout the text in I-Ds so I need to work that material in - a possible change to how channel binding is handled The latter is something I realized from reading the OAuth draft. The model I chose was to do CB by having the IdP compare authenticated copies of the CB data supplied by the RP and the client. That only works when you get signed requests from the RP and there's an explicit challenge/request message from the RP. That's why I took out the option for the client to push an unsolicited SAML response to the RP up front. I can see that an alternative model is to just have the client pass authenticated CB material to the IdP, have it embed that in the assertion it issues, and then have the RP just check that against its CB data at the end. That has some advantages, but one thing it doesn't do is prevent the RP (or an attacker) from getting a copy of the message from the IdP, which would include user data. It's normally encrypted, but it doesn't have to be. Doing the CB compare at the IdP prevents anything from reaching the attacker. I think I prefer my way, but I thought I'd mention it. My plan right now is to tackle the work remaining pretty soon, particularly the parts that would impact the OASIS documents. But I really want to do some implementation work before moving any of this towards finality. The basics here are easy and provem, but the CB and HoK work is new to (most) SAML code. -- Scott