From leifj@mnt.se Sun Jun 3 03:38:42 2012 Return-Path: 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 4AFFE21F8650 for ; Sun, 3 Jun 2012 03:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=-0.901, 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 c9Gd+nGxkaUP for ; Sun, 3 Jun 2012 03:38:41 -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 1E31021F864C for ; Sun, 3 Jun 2012 03:38:40 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q53AcYHw002533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 3 Jun 2012 12:38:39 +0200 (CEST) Message-ID: <4FCB3EAA.7090803@mnt.se> Date: Sun, 03 Jun 2012 12:38:34 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <8B77DF99-4E1B-4700-B7ED-A97E26DDEF0F@cardiff.ac.uk> In-Reply-To: <8B77DF99-4E1B-4700-B7ED-A97E26DDEF0F@cardiff.ac.uk> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] New use case draft 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: , X-List-Received-Date: Sun, 03 Jun 2012 10:38:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > As discussed in Paris, this should now be getting pretty close to > being ready to last call, hopefully. So please - any comments, > however big or small, welcome... The chairs are eager to move to WGLC on this and other documents on our charter by or before Vancouver. With one of our core documents on its way to IESG this is the time to roll up our sleeves and finish up! Please review the use-case draft! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/LPqoACgkQ8Jx8FtbMZnc/xQCghelpEhaXIHQTbIFDwjtkXqF4 z7QAn1cgSjF/j0jYiEtt1ftyNZ4b8eZH =TFzg -----END PGP SIGNATURE----- From leifj@mnt.se Sun Jun 3 04:26:33 2012 Return-Path: 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 DD3A021F867F for ; Sun, 3 Jun 2012 04:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=-0.721, 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 uGTes1j5gqRM for ; Sun, 3 Jun 2012 04:26:33 -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 D03B521F867E for ; Sun, 3 Jun 2012 04:26:32 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q53BQRAq012937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 3 Jun 2012 13:26:31 +0200 (CEST) Message-ID: <4FCB49E2.2050607@mnt.se> Date: Sun, 03 Jun 2012 13:26:26 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Meeting in Vancouver 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: , X-List-Received-Date: Sun, 03 Jun 2012 11:26:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've requested a 1.5 hr slot for Vancouver. We expect all document authors to make every effort to get their documents in a state as close to "done" as possible before Vancouver. We intend to use our slot to discuss remaining issues. Please submit your presentation requests asap! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/LSeIACgkQ8Jx8FtbMZncyxgCfcZ4I9tzKcfX4Q79IvRedRerD eEEAnR2KhpBZwmKArKYhn8ys3DBZaX/q =V6mO -----END PGP SIGNATURE----- From alex@um.es Tue Jun 5 03:00:41 2012 Return-Path: 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 0191C21F8646 for ; Tue, 5 Jun 2012 03:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gI2uSRt2byzx for ; Tue, 5 Jun 2012 03:00:40 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 093D321F863F for ; Tue, 5 Jun 2012 03:00:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 40C604BD4B for ; Tue, 5 Jun 2012 12:00:36 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IYFVaHOnYdd8 for ; Tue, 5 Jun 2012 12:00:35 +0200 (CEST) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 0EE834BD47 for ; Tue, 5 Jun 2012 12:00:34 +0200 (CEST) Message-ID: <4FCDD8C2.5070804@um.es> Date: Tue, 05 Jun 2012 12:00:34 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "abfab@ietf.org" References: <4FCDD880.5030303@um.es> In-Reply-To: <4FCDD880.5030303@um.es> X-Forwarded-Message-Id: <4FCDD880.5030303@um.es> Content-Type: multipart/mixed; boundary="------------000904070603030308020902" Subject: [abfab] Fwd: Re: [radext] RADEXT charter 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: , X-List-Received-Date: Tue, 05 Jun 2012 10:00:41 -0000 This is a multi-part message in MIME format. --------------000904070603030308020902 Content-Type: multipart/alternative; boundary="------------050204070606070304060409" --------------050204070606070304060409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Mensaje original -------- Asunto: Re: [radext] RADEXT charter Fecha: Tue, 05 Jun 2012 11:59:28 +0200 De: Alejandro Perez Mendez Para: radext@ietf.org Dear all, we have uploaded a new version of "Support of fragmentation of RADIUS packets" (draft-perez-radext-radius-fragmentation). You can find it at http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-02.txt. Most significant changes are: * New section discussing about the actual chunk size and why they cannot be 4096 bytes-length exactly. Includes a brief description of the mechanism for discovering the amount of data to be reserved for Proxy-State attributes. * State attribute. New section discussing how to deal with State attribute. * Proxies. New section discussing implications when leading with proxies. Comments are welcome. Regards, Alejandro --------------050204070606070304060409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI

-------- Mensaje original --------
Asunto: Re: [radext] RADEXT charter
Fecha: Tue, 05 Jun 2012 11:59:28 +0200
De: Alejandro Perez Mendez <alex@um.es>
Para: radext@ietf.org


Dear all,

we have uploaded a new version of "Support of fragmentation of RADIUS packets" (draft-perez-radext-radius-fragmentation). You can find it at http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-02.txt.

Most significant changes are:
  • New section discussing about the actual chunk size and why they cannot be 4096 bytes-length exactly. Includes a brief description of the mechanism for discovering the amount of data to be reserved for Proxy-State attributes.
  • State attribute. New section discussing how to deal with State attribute.
  • Proxies. New section discussing implications when leading with proxies.
Comments are welcome.

Regards,
Alejandro

--------------050204070606070304060409-- --------------000904070603030308020902 Content-Type: text/plain; charset=UTF-8; name="Parte del mensaje adjunto" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Parte del mensaje adjunto" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmFkZXh0 IG1haWxpbmcgbGlzdApyYWRleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yYWRleHQKCg== --------------000904070603030308020902-- From smith@Cardiff.ac.uk Tue Jun 19 06:54:41 2012 Return-Path: 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 4968521F85AC for ; Tue, 19 Jun 2012 06:54:41 -0700 (PDT) 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_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 MZVIqsaKeYZY for ; Tue, 19 Jun 2012 06:54:40 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0F021F85A4 for ; Tue, 19 Jun 2012 06:54:38 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1SgytA-0005oA-G2; Tue, 19 Jun 2012 14:54:36 +0100 Received: from [86.135.83.38] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SgytA-0002en-Df; Tue, 19 Jun 2012 14:54:36 +0100 From: Rhys Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_2CACB1CB-16D4-4F1D-B047-7EAA416EF88F" Date: Tue, 19 Jun 2012 14:54:30 +0100 Message-Id: To: abfab-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: [abfab] Use cases I-D 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: , X-List-Received-Date: Tue, 19 Jun 2012 13:54:41 -0000 --Apple-Mail=_2CACB1CB-16D4-4F1D-B047-7EAA416EF88F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Klaas, Leif, I think the use cases document is ready to go for WGLC - I've made all = the changes requested at the Paris meeting, completed all the bits that = were still todo, and posted the new version (-03) to the list a few = weeks ago, and haven't had any comments back yet. Best, R. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's education and research network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_2CACB1CB-16D4-4F1D-B047-7EAA416EF88F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Klaas, Leif,

I think the use cases document is ready = to go for WGLC - I've made all the changes requested at the Paris = meeting, completed all the bits that were still todo, and posted the new = version (-03) to the list a few weeks ago, and haven't had any comments = back yet.

Best,
R.
--
Dr Rhys Smith
Identity, Access, and = Middleware Specialist
Cardiff University & Janet - the UK's = education and research network
smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

= --Apple-Mail=_2CACB1CB-16D4-4F1D-B047-7EAA416EF88F-- From klaas@cisco.com Tue Jun 19 06:59:14 2012 Return-Path: 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 EDD1C21F85D8 for ; Tue, 19 Jun 2012 06:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 V11aWtnfVtna for ; Tue, 19 Jun 2012 06:59:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE3F721F85D4 for ; Tue, 19 Jun 2012 06:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1236; q=dns/txt; s=iport; t=1340114354; x=1341323954; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=URUEBzPlP2uacoWBsXT/t2yKvetLptbBqVY1303rZXc=; b=N1IDMTCUySpPXdvTHqGJH7SKZ6pa9UALe0aUj/HwxbroomR15zMP++fC qCqh1ecHLJ4PUykIB/x/ydiazDkv12jB4Fbk0T+6CQtEbFB6mI/mKhOAx kDhKWLiCxfx73HmOERVVcj+42qvyJbRzJCARQw4JUr86h9EfAviV8UYhg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJiE4E+tJXHA/2dsb2JhbAA8CbVUgQeCGAEBAQMBAQEBDwFbCgYLCyEWCAcJAwIBAgEVHxETBgIBARIMh2QFC5kEoD6LQIJtgxsDlSWBEo0FgWaCYoFd X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="90787589" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jun 2012 13:59:13 +0000 Received: from macmini.wierenga.net (rtp-kwiereng-8719.cisco.com [10.116.7.42]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5JDxCh3025633 for ; Tue, 19 Jun 2012 13:59:13 GMT Message-ID: <4FE085B0.7080408@cisco.com> Date: Tue, 19 Jun 2012 15:59:12 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Use cases I-D 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: , X-List-Received-Date: Tue, 19 Jun 2012 13:59:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/19/12 3:54 PM, Rhys Smith wrote: Hi Rhys, > Hi Klaas, Leif, > > I think the use cases document is ready to go for WGLC - I've made > all the changes requested at the Paris meeting, completed all the > bits that were still todo, and posted the new version (-03) to the > list a few weeks ago, and haven't had any comments back yet. That seems reasonable, we can always handle additional comments in WGLC. Klaas > > Best, R. -- Dr Rhys Smith Identity, Access, and Middleware > Specialist Cardiff University & Janet - the UK's education and > research network > > email: smith@cardiff.ac.uk / > rhys.smith@ja.net GPG: 0xDE2F024C > > > > _______________________________________________ abfab mailing list > abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ghbAACgkQH2Wy/p4XeFIgDwCglNVRQ/Wz3tq2+LJVqjB+3pXV xYMAoL9ugHBl8ml/ZKLoA5sf+WqKtStG =VvY1 -----END PGP SIGNATURE----- From klaas@cisco.com Tue Jun 19 07:06:53 2012 Return-Path: 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 1F2F621F8528 for ; Tue, 19 Jun 2012 07:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VBwqXqvnuwe7 for ; Tue, 19 Jun 2012 07:06:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 91DD321F8525 for ; Tue, 19 Jun 2012 07:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=716; q=dns/txt; s=iport; t=1340114809; x=1341324409; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=GaFo9KKd67y8UYE7wFLorkKBY0RWgv5hp8c34eTMkuc=; b=g9Fe0O0BwRheWFqQbFiE+H58TzBM8S4k/gFzJgehlDX0fcaTPZQbCz8J ieWggwFMUo772j12cOn6Mu29PbJA2QB5C5PNJ3pYXbitr31OsKGE+PoWK Oo5T89h8xqF85Y2s9h+Pgle8RF6YHJj5ok9RLM/3wfaPnzxKbPLt8rb9U g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOWG4E+tJXHA/2dsb2JhbABFtVSBB4IxAWU9FhgDAgECAUsNCAEBHodpC5dcgSigPYsvhhkDlSWBEo0FgWaCYg X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="90790768" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jun 2012 14:06:49 +0000 Received: from macmini.wierenga.net (rtp-kwiereng-8719.cisco.com [10.116.7.42]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5JE6mWJ002995 for ; Tue, 19 Jun 2012 14:06:48 GMT Message-ID: <4FE08777.7000802@cisco.com> Date: Tue, 19 Jun 2012 16:06:47 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] WGLC on draft-ietf-abfab-usecases-03 (ending July 4th 2012) 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: , X-List-Received-Date: Tue, 19 Jun 2012 14:06:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The chairs believe that draft-ietf-abfab-usecases-03 is ready for last call and that any remaining issues can be addressed during the WGLC. This is then a WGLC on draft-ietf-abfab-usecases-03 (http://tools.ietf.org/html/draft-ietf-abfab-usecases-03). Please provide comments and/or feedback by July 4th 2012. Cheers, Klaas & Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gh3cACgkQH2Wy/p4XeFKkBQCfUzNJPeaYgPdUAYUtA+gIhjQ/ B/gAn106QiM7NMNPEl07xquSOTWzA12s =eNrL -----END PGP SIGNATURE----- From lukeh@padl.com Tue Jun 19 21:57:28 2012 Return-Path: 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 71AC021F8738 for ; Tue, 19 Jun 2012 21:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 JdS1BYZfwYxB for ; Tue, 19 Jun 2012 21:57:27 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BECD221F8734 for ; Tue, 19 Jun 2012 21:57:25 -0700 (PDT) Received: by us.padl.com with ESMTP id q5K4vJto022482; Wed, 20 Jun 2012 00:57:21 -0400 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_B539B837-932E-41A4-84F1-1AA62725515A" Date: Wed, 20 Jun 2012 14:57:18 +1000 Message-Id: <071458B6-4E6F-476D-A95D-362B7FB5057A@padl.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: Larry Zhu Subject: [abfab] GSS EAP and NegoEx 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: , X-List-Received-Date: Wed, 20 Jun 2012 04:57:28 -0000 --Apple-Mail=_B539B837-932E-41A4-84F1-1AA62725515A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm going to propose the format of a NegoEx metadata exchange for GSS = EAP. NegoEx allows an authentication mechanism to be negotiated using = factors beyond mutually supported mechanisms; it optionally adds a pair = of metadata messages exchange by each negotiable security mechanism (I'm = liberally paraphrasing from draft-zhu-negoex here; read that for the = details). The purpose of the metadata exchange is to allow the initiator to = validate the EAP server's certificate before committing to context = establishment. The format of the metadata tokens is identical to the GSS EAP tokens, = except the outer token type is TOK_TYPE_INITIATOR_META_DATA (0x0603) or = TOK_TYPE_ACCEPTOR_META_DATA (0x0604). GSS_Query_meta_data on the = initiator emits the first; on the acceptor, the latter. Each outer token = contains a set of inner tokens; a convention is that inner token types = with the 0x1000 bit set are reserved for metadata. The following inner tokens are defined: #define ITOK_TYPE_INITIATOR_NAME_MD 0x00001000 /* anonymised = initiator name */ #define ITOK_TYPE_SERVER_SHA256_MD 0x00001001 /* EAP server = certificate hash */ #define ITOK_TYPE_SERVER_SUBJECT_MD 0x00001002 /* EAP server subject = name */ #define ITOK_TYPE_SERVER_CERT_MD 0x00001003 /* EAP server = certificate */ The first, ITOK_TYPE_INITIATOR_NAME_MD, allows the initiator to indicate = its realm to the acceptor. This goes in the clear, but it's the same = data that you see later in an EAP identity request. (Remember that = NegoEx integrity protects the entire exchange.) The initiator only sends = this if it does not have any other means to authenticate the server = (i.e. an existing trust anchor). The acceptor parses the initiator metadata token in = GSS_Exchange_meta_data. If there is no ITOK_TYPE_INITIATOR_NAME_MD, and = no other critical tokens it does not understand, it does nothing. Otherwise, the acceptor begins a EAP exchange with the AAA server = selected for the identity indicated in ITOK_TYPE_INITIATOR_NAME_MD. The = exchange will not complete, obviously, because the acceptor does not = have the initiator's credential; however, if it gets to the point where = the EAP server returns a certificate (EAP-[T]TLS), then that is saved. = The result of the authentication is discarded. This is similar to = wpa_supplicant in "probe" mode. If a certificate was returned, the acceptor may return the SHA-256 = certificate hash (in ITOK_TYPE_SERVER_SHA256_MD) and the subject name = (ITOK_TYPE_SERVER_SUBJECT_MD). It may optionally also return the = certificate (ITOK_TYPE_SERVER_CERT_MD). This doesn't add any round trips to the authentication exchange (if the = initiator uses an optimistic token), but it does allow the initiator to = validate the server before committing to an authentication, perhaps = choosing a different mechanism if preferable. NegoEx implementations = that support surfacing of metadata via UI may display the certificate = hash and allow the user to accept the certificate for this or all = authentications. It does add a number of round trips to the AAA server, = which may impact performance, so the initiator should only request this = if it has no other way to authenticate the server. I have this implemented on GSS/SSPI, although I'm yet to do anything = useful because there's no UI integration yet. -- Luke= --Apple-Mail=_B539B837-932E-41A4-84F1-1AA62725515A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii #define ITOK_TYPE_INITIATOR_NAME_MD     0x00001000 /* = anonymised initiator name */
#define = ITOK_TYPE_SERVER_SHA256_MD      0x00001001 /* EAP server = certificate hash */
#define = ITOK_TYPE_SERVER_SUBJECT_MD     0x00001002 /* EAP server = subject name */
#define ITOK_TYPE_SERVER_CERT_MD       =  0x00001003 /* EAP server certificate = */

The first, = ITOK_TYPE_INITIATOR_NAME_MD, allows the initiator to indicate its realm = to the acceptor. This goes in the clear, but it's the same data that you = see later in an EAP identity request. (Remember that NegoEx integrity = protects the entire exchange.) The initiator only sends this if it does = not have any other means to authenticate the server (i.e. an existing = trust anchor).

The acceptor parses the = initiator metadata token in GSS_Exchange_meta_data. If there is = no ITOK_TYPE_INITIATOR_NAME_MD, and no other critical tokens it = does not understand, it does = nothing.

Otherwise, the acceptor begins a EAP = exchange with the AAA server selected for the identity indicated = in ITOK_TYPE_INITIATOR_NAME_MD. The exchange will not complete, = obviously, because the acceptor does not have the initiator's = credential; however, if it gets to the point where the EAP server = returns a certificate (EAP-[T]TLS), then that is saved. The result of = the authentication is discarded. This is similar to wpa_supplicant in = "probe" mode.

If a certificate was returned, = the acceptor may return the SHA-256 certificate hash = (in ITOK_TYPE_SERVER_SHA256_MD) and the subject name = (ITOK_TYPE_SERVER_SUBJECT_MD). It may optionally also return the = certificate (ITOK_TYPE_SERVER_CERT_MD).

This = doesn't add any round trips to the authentication exchange (if the = initiator uses an optimistic token), but it does allow the initiator to = validate the server before committing to an authentication, perhaps = choosing a different mechanism if preferable. NegoEx implementations = that support surfacing of metadata via UI may display the certificate = hash and allow the user to accept the certificate for this or all = authentications. It does add a number of round trips to the AAA server, = which may impact performance, so the initiator should only request this = if it has no other way to authenticate the = server.

I have this implemented on GSS/SSPI, = although I'm yet to do anything useful because there's no UI integration = yet.

-- Luke= --Apple-Mail=_B539B837-932E-41A4-84F1-1AA62725515A-- From stephen.farrell@cs.tcd.ie Wed Jun 20 10:54:54 2012 Return-Path: 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 481EF21F8724 for ; Wed, 20 Jun 2012 10:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, 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 xNFuN9iGw1yL for ; Wed, 20 Jun 2012 10:54:53 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 29FB621F8732 for ; Wed, 20 Jun 2012 10:54:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DAE7E171483 for ; Wed, 20 Jun 2012 18:54:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1340214891; bh=wEl1b87B4fy+cC2UHwbcjh6h 4Y2RKiYx2R4uE1L0D0k=; b=3U6lmT6f1iPu9+ABEzeyQSfNyjvMkl4bThTkvl6L 8qI9JhMQqsKoUXttIY/VuQ1RwXgOVo0/tbEU4ck4P8TzI4WpfBHVabeC8GZ+F75Y EOrSq/OPx0BosDQYHWhWQlAE4DP5dGrfxOxLQh0MLBGCdRMRJxwsdXAkSVIcXaHh L3O6dEXumPQQMx/OJuPUk0KGKyXVIXuY8aq84ojw4BBQYblxN44ss6rMq3Azw7lL kF+R5L9fbvZ2NHj7BfLh7xOL1E2IUK2jm3UNW+MyP3gLp8EpMlOVk4S6jXht4ZXR icdLDkPySyAw1vqS687uMrG11gPg2YC0wJP7eUyjs6naSA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id R0sUkhiod1j3 for ; Wed, 20 Jun 2012 18:54:51 +0100 (IST) Received: from [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed] (unknown [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6151C171482 for ; Wed, 20 Jun 2012 18:54:51 +0100 (IST) Message-ID: <4FE20E6B.7060007@cs.tcd.ie> Date: Wed, 20 Jun 2012 18:54:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: abfab@ietf.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Wed, 20 Jun 2012 17:54:54 -0000 Hi, Pretty well written document, thanks. I've some questions and a bunch of nits below. I reckon this'll be ok to go to IETF LC, but want to check to see if you'd prefer to shoot out a revised I-D first. If you'd rather do IETF LC with -07, that's fine and you can respond to my questions along with IETF LC comments. I'll wait for a chair to tell me what you prefer. Cheers, S. Questions: (1) 3.4: the abnf in 3.1 has service-specifics which can have 0 or more service-specific values but the AVP here is called "GSS-Acceptor-Service-specific" (i.e. its singular). If >1 service-specific value is part of a name does that mean all of those are put in one AVP (with what separator?) or that multiple AVPs are sent? (I can't recall the RADIUS rules on AVPs right now). (2) Section 6: where are the pseudo-random and truncate functions defined? pseudo-random is presumably from 3961 but exactly which one? (Ah - If its from 4402 as 6.3 says, then please move that one line up to where CRK is defined.) I'm also confused about "truncate(L, T0 || T1 || .. || Tn)", if "||" is catenation and truncate(L,x) returned the left-most L bits of x, then adding more Tn's (on the right) will not have any effect after a while. I'm also not clear about the limits for "n" - are you just meant to iterate "n" until there are more than L bits to input to truncate()? If so, then I think you need to say that. (I reckon I figured it out in the end, but have left the comment as was to show how I got confused;-) (3) 6.2 uses the CRK as both sub-session key and ticket session key. Is that ok? Not asking you put the explanation in the draft, just checking that the WG/authors thought about it. (I don't recall 4121 well enough to be sure without reading it all again.) (4) 7.1 & 7.7 - do you really need IETF review for these? Wouldn't expert review be ok? Just checking. (5) Should there be any warnings about potential timing attacks against implementations of this? There are a lot of error conditions that say you MUST send an error so the timing of that might give something away. Having said that I don't see a case where a secret might leak, though with all the potential EAP methods it'd be hard to know for sure, but I wonder if the WG have thought about that. (If text needs adding it'd be fine to add after IETF LC as well but this isn't quite a nit.) nits ---- - ID-nits has some issues with the references (some are RFCs, some updated), and has (possibly spurious) issues with some example FQDNs and IP addresses. - expand NAS on 1st use - 1.2, does GSS-API "provide" guaranteed delivery? That's confusing, since GSS-API tokens are carried by the application protocol. Maybe s/provides/assumes/? - Is GSS_Pseudo_random MTI? Its a normative reference but 1.3 doesn't make it clear. (Maybe its later?) - section 3, a forward reference to where the policy DB is described might be useful in the 2nd last para before 3.1 - 3.1, "similar to the portion of a [NAI] before the @ symbol" sounds quite vague - why say it that way? (I've seen the phrase "similar" generate discusses before.) - 3.1 (or section 3, generally) could *really* do with some examples and the text is very complicated - if you could find someone to do a pass to try simplify that'd be great. - The text for the RFC editor to delete in 3.4 might be better as part of the iana considerations section - more common to see it there (you can put a ptr in 3.4 and a back-ptr in 7.x saying "don't forget to delete the ptr in 3.4" maybe) - As an alternative to removing the VSA text in 3.4, would that be useful as an appendix in the RFC that says "here's what we used to do before we had an official assignment...you might still see that in the wild" ? - section 4 start: s/The specification/This specification/? (twice in that para maybe) - section 4, 4th para: are the "should"'s here meant to be 2119 language? Seems like not, in which case maybe s/should/can/ (twice)? - section 4 ends on the bad news, might be good to say at the end why that's ok really - p16, be good to give the figure a name, and say that the position column is byte position - section 5: might be nice to say that 06 01 and 06 02 are hex and give the decimal equivalents just in case. - 5.1, this is the first mention of "mechanism family" might be good to introduce that idea earlier? - 5.4.3, typo s/be send/be sent/ - 5.5, the tools page rendering of the reference to "Section 7.10 [RFC3748]" is odd - I think if you said "Section 7.10 of [RFC3748]" it'd look better and generate the right link. - 5.5, typo: s/receivs/receives/ - 5.6.2, CRK could be expanded on 1st use - 5.8, is there a clear list of EAP methods that provide dictionary attack resistance? Could you provide a reference? At least the most commonly expected method would be good to mention. - 5.8 - is the back reference to 3.4 correct in the last para here? - section 6, typo: s/procedur/procedure/ - 6.1, typo: s/providing by/provided by/ - 6.1, what is "HTTP Negotiate" - maybe add an informative reference? - 7.1, You'll get asked (by Barry:-) to specify the precise name of the registry for IANA. - 7.2, 1st para has some text you don't want in the RFC, and some you do - better to indicate what's what. (Same for 7.4) - 7.6, the "implementations MUST be prepared to receive them" is a bit hidden here, was it also stated earlier? Might be a good plan. From leifj@sunet.se Wed Jun 20 11:58:12 2012 Return-Path: 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 8A46A21F8790 for ; Wed, 20 Jun 2012 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 ejvuaynsYQiU for ; Wed, 20 Jun 2012 11:58:12 -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 BBEE221F8667 for ; Wed, 20 Jun 2012 11:58:11 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5KIvvq1007834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jun 2012 20:58:07 +0200 (CEST) Message-ID: <4FE21D34.1040409@sunet.se> Date: Wed, 20 Jun 2012 20:57:56 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <4FE20E6B.7060007@cs.tcd.ie> In-Reply-To: <4FE20E6B.7060007@cs.tcd.ie> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Wed, 20 Jun 2012 18:58:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/20/2012 07:54 PM, Stephen Farrell wrote: > > Hi, > > Pretty well written document, thanks. > > I've some questions and a bunch of nits below. > > I reckon this'll be ok to go to IETF LC, but want to check to see > if you'd prefer to shoot out a revised I-D first. If you'd rather > do IETF LC with -07, that's fine and you can respond to my > questions along with IETF LC comments. > > I'll wait for a chair to tell me what you prefer. Depends on Sams answers to the questions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/iHS8ACgkQ8Jx8FtbMZnccKwCeJ176RuPdrOEYlWFSf3uRMARO nE4An0sKhKzCOlcYOij5T9UIXs/604UG =eyWW -----END PGP SIGNATURE----- From hartmans@painless-security.com Wed Jun 20 12:15:29 2012 Return-Path: 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 ED10F21F8643 for ; Wed, 20 Jun 2012 12:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_81=0.6] 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 3zetvfBhNyCK for ; Wed, 20 Jun 2012 12:15:29 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6A521F87A8 for ; Wed, 20 Jun 2012 12:15:29 -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 EBB212010F; Wed, 20 Jun 2012 15:14:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 02DF941EF; Wed, 20 Jun 2012 15:15:22 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <4FE20E6B.7060007@cs.tcd.ie> Date: Wed, 20 Jun 2012 15:15:21 -0400 In-Reply-To: <4FE20E6B.7060007@cs.tcd.ie> (Stephen Farrell's message of "Wed, 20 Jun 2012 18:54:51 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Wed, 20 Jun 2012 19:15:30 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> (1) 3.4: the abnf in 3.1 has service-specifics which can have Stephen> 0 or more service-specific values but the AVP here is called Stephen> "GSS-Acceptor-Service-specific" (i.e. its singular). If >1 Stephen> service-specific value is part of a name does that mean all of Stephen> those are put in one AVP (with what separator?) or that Stephen> multiple AVPs are sent? (I can't recall the RADIUS rules on Stephen> AVPs right now). Good catch. my preference is to send one AVP with / separator. I.E. send the text string that is input. However this has not been discussed. Stephen> (2) Section 6: where are the pseudo-random and truncate Stephen> functions defined? pseudo-random is presumably from 3961 but Stephen> exactly which one? ( The one for the enctype of the mechanism in question. I.E. if this is eap-aes128, then the GMSK is an aes-128-cts-hmac-sha1-96 key so you use the aes128-cts-hmac-sha1-96 pseudo-random function. Stephen> Ah - If its from 4402 as 6.3 says, then Stephen> please move that one line up to where CRK is defined.) Sounds like we need to specify what pseudo-random and make it clear that this in an internal call to pseudo-random, not the pseudo-random construction from 4402 that is exposed to users. (The construction from 4402 is actually the same with a different constant fed into the PRF so that an application can never get the same pseudo-random output as used for internal key derivation.) Stephen> I'm also confused about "truncate(L, T0 || T1 || .. || Tn)", Stephen> if "||" is catenation and truncate(L,x) returned the left-most Stephen> L bits of x, then adding more Tn's (on the right) will not have Stephen> any effect after a while. Exactly. This construction deals with the fact that a Kerberos PRF may output less bits than you need. So, you'd kind of expect that only the bits that you need count towards the key. The truncation and expansion is not intended to add cryptographic strength; either your PRF is good or you're out of luck. It's simply intended to deal with a potential mismatch between PRF output length and key bits. For aes128, l=128 and only t0 counts towards the key because the prf output length is also 128. So in aes128's case this devolves to a simple call to the prf. Stephen> I'm also not clear about the limits Stephen> for "n" - are you just meant to iterate "n" until there are Stephen> more than L bits to input to truncate()? If so, then I think Stephen> you need to say that. (I reckon I figured it out in the end, Stephen> but have left the comment as was to show how I got confused;-) Right. An explanatory paragraph is needed here. Stephen> (3) 6.2 uses the CRK as both sub-session key and ticket Stephen> session key. Is that ok? Not asking you put the explanation in Stephen> the draft, just checking that the WG/authors thought about it. Stephen> (I don't recall 4121 well enough to be sure without reading it Stephen> all again.) I wrote that text to make sure the context would be well formed in terms of how implementations tend to represent the context and use it for some AD-specific applications. In practice I don't think anything standards-track will use the ticket key if the sub-session key is present. I'm fairly sure this is OK, but I'd appreciate a sanity check from Nico or luke or someone else who has looked at 4121 a lot. Stephen> (4) 7.1 & 7.7 - do you really need IETF review for these? Stephen> Wouldn't expert review be ok? Just checking. 7.1: I argue IETF review is appropriate because I can't see why anyone other than the IETF would use that registry rather than just grabbing their own OID. I'd support making it expert review with a note that we cannot currently think of a reason for allocation other than to an IETF stream document and other allocations are expected to be declined. I.E. there's no harm in using that registry for other things, but why would you want to? 7.7: There are only 32 possible values to be allocated. I'd also be totally fine with expert review with a note that experts are very likely to insist on IETF stream documents. Stephen> (5) Should there be any warnings about potential timing Stephen> attacks against implementations of this? There are a lot of Stephen> error conditions that say you MUST send an error so the Stephen> timing of that might give something away. Having said that I Stephen> don't see a case where a secret might leak, though with all Stephen> the potential EAP methods it'd be hard to know for sure, but I Stephen> wonder if the WG have thought about that. (If text needs Stephen> adding it'd be fine to add after IETF LC as well but this Stephen> isn't quite a nit.) I know I have not thought about this at all. The general public-key timing attacks against say TLS don't seem to apply. For one thing we don't actually create any new requirements for the EAP server. So, failure cases where we require an error to be sent are generally specific to this mechanism or cases where EAP has already failed and generated its own failure. However, review could help here. Stephen> ---- Stephen> - Is GSS_Pseudo_random MTI? Its a normative reference but 1.3 Stephen> doesn't make it clear. (Maybe its later?) I consider it MTI. Stephen> - 3.1, "similar to the portion of a [NAI] before the @ symbol" Stephen> sounds quite vague - why say it that way? (I've seen the Stephen> phrase "similar" generate discusses before.) Because the NAI spec is kind of broken and confuses encoding with format. It's being revised but we don't want to block on that. However, the AAA community was really unhappy when they thought we were going to actually use the NAI spec. Stephen> - As an alternative to removing the VSA text in 3.4, would Stephen> that be useful as an appendix in the RFC that says "here's Stephen> what we used to do before we had an official assignment...you Stephen> might still see that in the wild" ? I like this. Thoughts? Stephen> - section 4, 4th para: are the "should"'s here meant to be Stephen> 2119 language? Seems like not, in which case maybe Stephen> s/should/can/ (twice)? Definitely not as it's a description of an alternative not taken. can seems wrong there to me. Stephen> - 5.8, is there a clear list of EAP methods that provide Stephen> dictionary attack resistance? Could you provide a reference? Stephen> At least the most commonly expected method would be good to Stephen> mention. I don't know what the commonly expected method is. In general people get this by running over a tunnel. Stephen> - 5.8 - is the back reference to 3.4 correct in the last para Stephen> here? It is. Yes, I believe so. Stephen> _______________________________________________ Stephen> abfab mailing list Stephen> abfab@ietf.org Stephen> https://www.ietf.org/mailman/listinfo/abfab From stephen.farrell@cs.tcd.ie Wed Jun 20 14:46:46 2012 Return-Path: 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 0BD4B21F852B for ; Wed, 20 Jun 2012 14:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, 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 aEI+ize+Emr1 for ; Wed, 20 Jun 2012 14:46:42 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6325021F85F8 for ; Wed, 20 Jun 2012 14:46:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A869A171483; Wed, 20 Jun 2012 22:46:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340228798; bh=JrBWCgH1pj+mxO DJdnqXB/GvEphqV9b7Lg5Ihl1FHGw=; b=w459YGYSb37Sj6EoG0I9O3sTf9c+jY LRZDvMsjUuJmnRigGqWKTcRDBV4sdQnVSR3iocOr/CC+au0eAGXsTsvBzcKtynL0 ZjjfWVW4+VCAhPxIMLsEoraQ8+S3trtzmhq/7S3hajlGcBHnShm7wqMID3LqUZXS r/PthHsp41V6eH7rt7OElxrXeqXnr2J8iqzGx0XTltYalbVu8Mzh9FPmLGxvX7fx N1YFPW24Ve582sLjWiTtFA/FVfV4FYvgHeZosDtfTlaC0H3I1kd475Mn7DFC7aCC 4n0/c4G/fyHu9q3RLca3R2Akrg23BB6EKsuECe9ZdGMDAF+WHafwABMA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id PIABVYe2HOBE; Wed, 20 Jun 2012 22:46:38 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.21.43]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A0232171482; Wed, 20 Jun 2012 22:46:38 +0100 (IST) Message-ID: <4FE244BE.6090709@cs.tcd.ie> Date: Wed, 20 Jun 2012 22:46:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4FE20E6B.7060007@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Wed, 20 Jun 2012 21:46:46 -0000 Hi Sam, Just to note that this all looks good to me and proceeding as you indicate seems like a fine plan. Thanks, S On 06/20/2012 08:15 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > > Stephen> (1) 3.4: the abnf in 3.1 has service-specifics which can have > Stephen> 0 or more service-specific values but the AVP here is called > Stephen> "GSS-Acceptor-Service-specific" (i.e. its singular). If >1 > Stephen> service-specific value is part of a name does that mean all of > Stephen> those are put in one AVP (with what separator?) or that > Stephen> multiple AVPs are sent? (I can't recall the RADIUS rules on > Stephen> AVPs right now). > > Good catch. > my preference is to send one AVP with / separator. > I.E. send the text string that is input. > However this has not been discussed. > > Stephen> (2) Section 6: where are the pseudo-random and truncate > Stephen> functions defined? pseudo-random is presumably from 3961 but > Stephen> exactly which one? ( > > > The one for the enctype of the mechanism in question. > I.E. if this is eap-aes128, then the GMSK is an aes-128-cts-hmac-sha1-96 > key so you use the aes128-cts-hmac-sha1-96 pseudo-random function. > > Stephen> Ah - If its from 4402 as 6.3 says, then > Stephen> please move that one line up to where CRK is defined.) > > Sounds like we need to specify what pseudo-random and make it clear that > this in an internal call to pseudo-random, not the pseudo-random > construction from 4402 that is exposed to users. > (The construction from 4402 is actually the same with a different > constant fed into the PRF so that an application can never get the same > pseudo-random output as used for internal key derivation.) > > Stephen> I'm also confused about "truncate(L, T0 || T1 || .. || Tn)", > Stephen> if "||" is catenation and truncate(L,x) returned the left-most > Stephen> L bits of x, then adding more Tn's (on the right) will not have > Stephen> any effect after a while. > > Exactly. > This construction deals with the fact that a Kerberos PRF may output > less bits than you need. So, you'd kind of expect that only the bits > that you need count towards the key. > The truncation and expansion is not intended to add cryptographic > strength; either your PRF is good or you're out of luck. It's simply > intended to deal with a potential mismatch between PRF output length and > key bits. > For aes128, l=128 and only t0 counts towards the key because the prf > output length is also 128. > So in aes128's case this devolves to a simple call to the prf. > > Stephen> I'm also not clear about the limits > Stephen> for "n" - are you just meant to iterate "n" until there are > Stephen> more than L bits to input to truncate()? If so, then I think > Stephen> you need to say that. (I reckon I figured it out in the end, > Stephen> but have left the comment as was to show how I got confused;-) > > Right. > An explanatory paragraph is needed here. > > Stephen> (3) 6.2 uses the CRK as both sub-session key and ticket > Stephen> session key. Is that ok? Not asking you put the explanation in > Stephen> the draft, just checking that the WG/authors thought about it. > Stephen> (I don't recall 4121 well enough to be sure without reading it > Stephen> all again.) > > I wrote that text to make sure the context would be well formed in terms > of how implementations tend to represent the context and use it for some > AD-specific applications. > In practice I don't think anything standards-track will use the ticket > key if the sub-session key is present. > > I'm fairly sure this is OK, but I'd appreciate a sanity check from Nico > or luke or someone else who has looked at 4121 a lot. > > Stephen> (4) 7.1 & 7.7 - do you really need IETF review for these? > Stephen> Wouldn't expert review be ok? Just checking. > > 7.1: I argue IETF review is appropriate because I can't see why anyone > other than the IETF would use that registry rather than just grabbing > their own OID. > I'd support making it expert review with a note that we cannot currently > think of a reason for allocation other than to an IETF stream document > and other allocations are expected to be declined. > I.E. there's no harm in using that registry for other things, but why > would you want to? > > 7.7: There are only 32 possible values to be allocated. > I'd also be totally fine with expert review with a note that experts are > very likely to insist on IETF stream documents. > > > Stephen> (5) Should there be any warnings about potential timing > Stephen> attacks against implementations of this? There are a lot of > Stephen> error conditions that say you MUST send an error so the > Stephen> timing of that might give something away. Having said that I > Stephen> don't see a case where a secret might leak, though with all > Stephen> the potential EAP methods it'd be hard to know for sure, but I > Stephen> wonder if the WG have thought about that. (If text needs > Stephen> adding it'd be fine to add after IETF LC as well but this > Stephen> isn't quite a nit.) > > > I know I have not thought about this at all. > The general public-key timing attacks against say TLS don't seem to > apply. > For one thing we don't actually create any new requirements for the EAP > server. > So, failure cases where we require an error to be sent are generally > specific to this mechanism or cases where EAP has already failed and > generated its own failure. > However, review could help here. > > Stephen> ---- > > Stephen> - Is GSS_Pseudo_random MTI? Its a normative reference but 1.3 > Stephen> doesn't make it clear. (Maybe its later?) > > > I consider it MTI. > > Stephen> - 3.1, "similar to the portion of a [NAI] before the @ symbol" > Stephen> sounds quite vague - why say it that way? (I've seen the > Stephen> phrase "similar" generate discusses before.) > > Because the NAI spec is kind of broken and confuses encoding with > format. > It's being revised but we don't want to block on that. > However, the AAA community was really unhappy when they thought we were > going to actually use the NAI spec. > Stephen> - As an alternative to removing the VSA text in 3.4, would > Stephen> that be useful as an appendix in the RFC that says "here's > Stephen> what we used to do before we had an official assignment...you > Stephen> might still see that in the wild" ? > > I like this. > Thoughts? > > > Stephen> - section 4, 4th para: are the "should"'s here meant to be > Stephen> 2119 language? Seems like not, in which case maybe > Stephen> s/should/can/ (twice)? > Definitely not as it's a description of an alternative not taken. > > can seems wrong there to me. > > Stephen> - 5.8, is there a clear list of EAP methods that provide > Stephen> dictionary attack resistance? Could you provide a reference? > Stephen> At least the most commonly expected method would be good to > Stephen> mention. > > I don't know what the commonly expected method is. > In general people get this by running over a tunnel. > > Stephen> - 5.8 - is the back reference to 3.4 correct in the last para > Stephen> here? > > It is. > > > Yes, I believe so. > > Stephen> _______________________________________________ > Stephen> abfab mailing list > Stephen> abfab@ietf.org > Stephen> https://www.ietf.org/mailman/listinfo/abfab > > From ietf@augustcellars.com Wed Jun 20 15:34:15 2012 Return-Path: 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 6C47F21F86B3 for ; Wed, 20 Jun 2012 15:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_81=0.6, 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 au-5JqX4V6ew for ; Wed, 20 Jun 2012 15:34:14 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F43A21F8667 for ; Wed, 20 Jun 2012 15:34:14 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id EE4102C9F7; Wed, 20 Jun 2012 15:34:13 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Stephen Farrell'" References: <4FE20E6B.7060007@cs.tcd.ie> In-Reply-To: Date: Wed, 20 Jun 2012 15:32:59 -0700 Message-ID: <00c001cd4f34$a5c00150$f14003f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKf0jyN5GqrXjoQIVzZRNyvRhIv6gJDTchClUymIWA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Wed, 20 Jun 2012 22:34:15 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, June 20, 2012 12:15 PM > To: Stephen Farrell > Cc: abfab@ietf.org > Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 > > >>>>> "Stephen" == Stephen Farrell writes: > > > Stephen> (1) 3.4: the abnf in 3.1 has service-specifics which can have > Stephen> 0 or more service-specific values but the AVP here is called > Stephen> "GSS-Acceptor-Service-specific" (i.e. its singular). If >1 > Stephen> service-specific value is part of a name does that mean all of > Stephen> those are put in one AVP (with what separator?) or that > Stephen> multiple AVPs are sent? (I can't recall the RADIUS rules on > Stephen> AVPs right now). > > Good catch. > my preference is to send one AVP with / separator. > I.E. send the text string that is input. > However this has not been discussed. This matches what I would have expected. > > Stephen> (2) Section 6: where are the pseudo-random and truncate > Stephen> functions defined? pseudo-random is presumably from 3961 but > Stephen> exactly which one? ( > > > The one for the enctype of the mechanism in question. > I.E. if this is eap-aes128, then the GMSK is an aes-128-cts-hmac-sha1-96 key > so you use the aes128-cts-hmac-sha1-96 pseudo-random function. > > Stephen> Ah - If its from 4402 as 6.3 says, then > Stephen> please move that one line up to where CRK is defined.) > > Sounds like we need to specify what pseudo-random and make it clear that > this in an internal call to pseudo-random, not the pseudo-random > construction from 4402 that is exposed to users. > (The construction from 4402 is actually the same with a different constant > fed into the PRF so that an application can never get the same pseudo- > random output as used for internal key derivation.) Yes, I would have probably messed that one up. > > Stephen> I'm also confused about "truncate(L, T0 || T1 || .. || Tn)", > Stephen> if "||" is catenation and truncate(L,x) returned the left-most > Stephen> L bits of x, then adding more Tn's (on the right) will not have > Stephen> any effect after a while. > > Exactly. > This construction deals with the fact that a Kerberos PRF may output less bits > than you need. So, you'd kind of expect that only the bits that you need > count towards the key. > The truncation and expansion is not intended to add cryptographic strength; > either your PRF is good or you're out of luck. It's simply intended to deal with > a potential mismatch between PRF output length and key bits. > For aes128, l=128 and only t0 counts towards the key because the prf output > length is also 128. > So in aes128's case this devolves to a simple call to the prf. > > Stephen> I'm also not clear about the limits > Stephen> for "n" - are you just meant to iterate "n" until there are > Stephen> more than L bits to input to truncate()? If so, then I think > Stephen> you need to say that. (I reckon I figured it out in the end, > Stephen> but have left the comment as was to show how I got confused;-) > > Right. > An explanatory paragraph is needed here. > > Stephen> (3) 6.2 uses the CRK as both sub-session key and ticket > Stephen> session key. Is that ok? Not asking you put the explanation in > Stephen> the draft, just checking that the WG/authors thought about it. > Stephen> (I don't recall 4121 well enough to be sure without reading it > Stephen> all again.) > > I wrote that text to make sure the context would be well formed in terms of > how implementations tend to represent the context and use it for some AD- > specific applications. > In practice I don't think anything standards-track will use the ticket key if the > sub-session key is present. > > I'm fairly sure this is OK, but I'd appreciate a sanity check from Nico or luke or > someone else who has looked at 4121 a lot. > > Stephen> (4) 7.1 & 7.7 - do you really need IETF review for these? > Stephen> Wouldn't expert review be ok? Just checking. > > 7.1: I argue IETF review is appropriate because I can't see why anyone other > than the IETF would use that registry rather than just grabbing their own > OID. > I'd support making it expert review with a note that we cannot currently > think of a reason for allocation other than to an IETF stream document and > other allocations are expected to be declined. > I.E. there's no harm in using that registry for other things, but why would you > want to? 7.1 NIT - just noticed that the description of GSS_EAP_NT_EAP_NAME is not in the table > > 7.7: There are only 32 possible values to be allocated. > I'd also be totally fine with expert review with a note that experts are very > likely to insist on IETF stream documents. > > > Stephen> (5) Should there be any warnings about potential timing > Stephen> attacks against implementations of this? There are a lot of > Stephen> error conditions that say you MUST send an error so the > Stephen> timing of that might give something away. Having said that I > Stephen> don't see a case where a secret might leak, though with all > Stephen> the potential EAP methods it'd be hard to know for sure, but I > Stephen> wonder if the WG have thought about that. (If text needs > Stephen> adding it'd be fine to add after IETF LC as well but this > Stephen> isn't quite a nit.) > > > I know I have not thought about this at all. > The general public-key timing attacks against say TLS don't seem to apply. > For one thing we don't actually create any new requirements for the EAP > server. > So, failure cases where we require an error to be sent are generally specific > to this mechanism or cases where EAP has already failed and generated its > own failure. > However, review could help here. > > Stephen> ---- > > Stephen> - Is GSS_Pseudo_random MTI? Its a normative reference but 1.3 > Stephen> doesn't make it clear. (Maybe its later?) > > > I consider it MTI. > > Stephen> - 3.1, "similar to the portion of a [NAI] before the @ symbol" > Stephen> sounds quite vague - why say it that way? (I've seen the > Stephen> phrase "similar" generate discusses before.) > > Because the NAI spec is kind of broken and confuses encoding with format. > It's being revised but we don't want to block on that. > However, the AAA community was really unhappy when they thought we > were going to actually use the NAI spec. > Stephen> - As an alternative to removing the VSA text in 3.4, would > Stephen> that be useful as an appendix in the RFC that says "here's > Stephen> what we used to do before we had an official assignment...you > Stephen> might still see that in the wild" ? > > I like this. > Thoughts? It is not clear to me that all of section 3.4 should be deleted by the RFC editor. Specifically looking at the text starting with "If RADIUS is used as an AAA transport". This text is not reproduced in the registration code below. > > > Stephen> - section 4, 4th para: are the "should"'s here meant to be > Stephen> 2119 language? Seems like not, in which case maybe > Stephen> s/should/can/ (twice)? > Definitely not as it's a description of an alternative not taken. > > can seems wrong there to me. I have been fighting this battle by changing the 2119 slightly to be "When the keys words ... are in upper case ...". I saw this in another standards group and it deals with the casing question. > > Stephen> - 5.8, is there a clear list of EAP methods that provide > Stephen> dictionary attack resistance? Could you provide a reference? > Stephen> At least the most commonly expected method would be good to > Stephen> mention. > > I don't know what the commonly expected method is. > In general people get this by running over a tunnel. > > Stephen> - 5.8 - is the back reference to 3.4 correct in the last para > Stephen> here? > > It is. But only if the text is not deleted per current instructions. Jim > > > Yes, I believe so. > > Stephen> _______________________________________________ > Stephen> abfab mailing list > Stephen> abfab@ietf.org > Stephen> https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Jun 20 16:02:23 2012 Return-Path: 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 B4E5811E80BF for ; Wed, 20 Jun 2012 16:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 rX7PwjNdgILM for ; Wed, 20 Jun 2012 16:02:23 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C0D9B11E80B6 for ; Wed, 20 Jun 2012 16:02:22 -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 8682D2010F; Wed, 20 Jun 2012 19:01:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DEFDA41EF; Wed, 20 Jun 2012 19:02:17 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <4FE20E6B.7060007@cs.tcd.ie> <00c001cd4f34$a5c00150$f14003f0$@augustcellars.com> Date: Wed, 20 Jun 2012 19:02:17 -0400 In-Reply-To: <00c001cd4f34$a5c00150$f14003f0$@augustcellars.com> (Jim Schaad's message of "Wed, 20 Jun 2012 15:32:59 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Wed, 20 Jun 2012 23:02:24 -0000 OK, so based on Jim's comments we definitely need to refine what we propose to delete from 3.4. I'd also appreciate input on registration procedures for 7.1 and 7.7; details of the discussion in my original response to Stephen. From hartmans@painless-security.com Tue Jun 26 08:10:45 2012 Return-Path: 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 1ED9821F8550 for ; Tue, 26 Jun 2012 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 MeP2krAlrhrV for ; Tue, 26 Jun 2012 08:10:44 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 702EC21F84E6 for ; Tue, 26 Jun 2012 08:10:44 -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 107D2201CC; Tue, 26 Jun 2012 11:10:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 749F741EF; Tue, 26 Jun 2012 11:10:25 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <4FE20E6B.7060007@cs.tcd.ie> Date: Tue, 26 Jun 2012 11:10:25 -0400 In-Reply-To: <4FE20E6B.7060007@cs.tcd.ie> (Stephen Farrell's message of "Wed, 20 Jun 2012 18:54:51 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Tue, 26 Jun 2012 15:10:45 -0000 I am uploading 08 as I write. I think this is ready for last call. I believe I've addressed most of your nits and all of your questions. Some nits I leave to the rfc editor. They're better at fixing up references than I'll ever be. Also, while I appreciate your desire to have a title on the figure on page 16, there's already one there. It's just that xml2rfc in its infinite wizdom believes that the title of a texttable goes *at the bottom*. Who am I to question such an august source about the proper formatting of documents? From stephen.farrell@cs.tcd.ie Tue Jun 26 08:15:48 2012 Return-Path: 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 79F0621F85FB for ; Tue, 26 Jun 2012 08:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 aYVJc4wPkvhQ for ; Tue, 26 Jun 2012 08:15:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C7BFD21F85F8 for ; Tue, 26 Jun 2012 08:15:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 16F8F17151B; Tue, 26 Jun 2012 16:15:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340723746; bh=6kCGVgcpkALkpm iCHJeE6dEnMRbjY0Kn3gDvWaTs+DU=; b=GDQbhKXnuM4jhJkB+mjR2omUzGnyDT nykkq8flpcYBbvF9KIVaQuC+rnuYysmWlIr2i4U8yd9cR3KECW33zDn6K00C/aWB OpNN4RWMtqySufOOq3TdI28va79eLcQ54SEvZ73bEx1YkamwD6fXvW990eoBfYZs ihCNDcHFRXHRxD0al5SwFzoRtSiblMfMzs2wJLdssSpAGLw2h2tlybS5gNqCVyT5 WI007iT4AiKuffMvXI55Ftwg/skd7sdmflskKDxxYQGeJzt85PQIETx4ef/qGG8U 1hlXCcn65IiNGEM7dgsTrqRtBGBuL8mQqpBew+mjBOvEDn46MhETXlhg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Ix9fkvDVsOTo; Tue, 26 Jun 2012 16:15:46 +0100 (IST) Received: from [IPv6:2001:770:10:203:8cee:98bb:ac1:26b] (unknown [IPv6:2001:770:10:203:8cee:98bb:ac1:26b]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AE5A5171817; Tue, 26 Jun 2012 16:15:46 +0100 (IST) Message-ID: <4FE9D222.9010303@cs.tcd.ie> Date: Tue, 26 Jun 2012 16:15:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4FE20E6B.7060007@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 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: , X-List-Received-Date: Tue, 26 Jun 2012 15:15:48 -0000 Ack, will start IETF LC when I see -08 (later this pm) S On 06/26/2012 04:10 PM, Sam Hartman wrote: > I am uploading 08 as I write. I think this is ready for last call. > I believe I've addressed most of your nits and all of your questions. > > Some nits I leave to the rfc editor. They're better at fixing up > references than I'll ever be. > Also, while I appreciate your desire to have a title on the figure on > page 16, there's already one there. It's just that xml2rfc in its > infinite wizdom believes that the title of a texttable goes *at the > bottom*. Who am I to question such an august source about the proper > formatting of documents? > > From internet-drafts@ietf.org Tue Jun 26 08:17:25 2012 Return-Path: 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 32B4B21F85C0; Tue, 26 Jun 2012 08:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 WzJyUcu6OFQb; Tue, 26 Jun 2012 08:17:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7451521F85AF; Tue, 26 Jun 2012 08:17:24 -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: 4.21 Message-ID: <20120626151724.14413.96198.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 08:17:24 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-08.txt 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: , X-List-Received-Date: Tue, 26 Jun 2012 15:17:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Pr= otocol Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-08.txt Pages : 41 Date : 2012-06-26 Abstract: This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-08 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-gss-eap-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Jun 26 09:58:33 2012 Return-Path: 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 589F921F856D; Tue, 26 Jun 2012 09:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 VwzPwZU7P1zF; Tue, 26 Jun 2012 09:58:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E221F84E7; Tue, 26 Jun 2012 09:58:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120626165832.6142.66386.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 09:58:32 -0700 Cc: abfab@ietf.org Subject: [abfab] Last Call: (A GSS-API Mechanism for the Extensible Authentication Protocol) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 16:58:33 -0000 The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'A GSS-API Mechanism for the Extensible Authentication Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. The normative reference to the IANA registry [GSS-IANA] might be considered a downref. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap/ballot/ No IPR declarations have been submitted directly on this I-D. From hartmans@mit.edu Tue Jun 26 12:14:51 2012 Return-Path: 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 D4B4611E809F; Tue, 26 Jun 2012 12:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.161 X-Spam-Level: X-Spam-Status: No, score=-104.161 tagged_above=-999 required=5 tests=[AWL=-1.896, 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 03BizKd24iQn; Tue, 26 Jun 2012 12:14:51 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5419811E809C; Tue, 26 Jun 2012 12:14:51 -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 AC551202D8; Tue, 26 Jun 2012 15:14:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C78ED41EF; Tue, 26 Jun 2012 15:14:35 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org References: <20120626165832.6142.66386.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 15:14:35 -0400 In-Reply-To: <20120626165832.6142.66386.idtracker@ietfa.amsl.com> (The IESG's message of "Tue, 26 Jun 2012 09:58:32 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Last Call: (A GSS-API Mechanism for the Extensible Authentication Protocol) to Proposed Standard 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: , X-List-Received-Date: Tue, 26 Jun 2012 19:14:51 -0000 EAP (RFC 3748) has a applicability statement scoped very strictly to network access. This document provides a mechanism that falls well outside that applicability statement and permits the use of EAP for general application authentication. When ABFAB was chartered, there was a charter item to update the EAP applicability statement. I think A number of people in the room at the BOF, including myself, would have objected to the work being chartered had that charter item not been present. I think that work is important because I believe there are a number of important concerns that apply to the use of EAP for authentication beyond network access that need to be documented. Unfortunately, the technical specification has gotten ahead of the applicability statement update. I'm OK with that provided that we're still firmly committed to an applicability statement update. As part of approving this document now, I want to confirm that we have consensus at least within the ABFAB working group and the IESG to do that update. If there is any doubt I'd far prefer that this document be held until the applicability statement catches up. --Sam From jimsch@augustcellars.com Sat Jun 30 12:03:31 2012 Return-Path: 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 5ED9F21F85D0 for ; Sat, 30 Jun 2012 12:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 kt99BMNQQq76 for ; Sat, 30 Jun 2012 12:03:30 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id D52E521F85CD for ; Sat, 30 Jun 2012 12:03:30 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 98CEA38F02; Sat, 30 Jun 2012 12:03:31 -0700 (PDT) From: "Jim Schaad" To: , "Sam Hartman" Date: Sat, 30 Jun 2012 12:02:08 -0700 Message-ID: <029001cd56f2$d9551a80$8bff4f80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1W8p4B7qnBnUgFQsG1/R2R1LEp/Q== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] SAML Draft and SAML 1.0 vs SAML 2.0 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: , X-List-Received-Date: Sat, 30 Jun 2012 19:03:31 -0000 SAML 2.0 is the latest and best version of SAML. Is there/should there be a restriction in the SAML document about using just SAML 2.0 and higher? If a new version of SAML is produced, does there need to be a different set of messages defined or should the current set of messages be sufficient (assuming that the entire protocol world is not radically overhauled). Does any of this need to be put into the document? Jim