From nobody Wed Oct 1 10:26:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F191A1A66 for ; Wed, 1 Oct 2014 10:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmcuzGt5TBtJ for ; Wed, 1 Oct 2014 10:26:01 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C9B1A1A77 for ; Wed, 1 Oct 2014 10:25:56 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-d0-542c39235bb0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 69.20.28565.3293C245; Wed, 1 Oct 2014 13:25:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s91HPshB029566; Wed, 1 Oct 2014 13:25:55 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s91HPqna030989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Oct 2014 13:25:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s91HPquX024325; Wed, 1 Oct 2014 13:25:52 -0400 (EDT) Date: Wed, 1 Oct 2014 13:25:52 -0400 (EDT) From: Benjamin Kaduk To: Richard Feezel In-Reply-To: Message-ID: References: <1409243818.9966.3.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrKtsqRNi8P6YkMXRzatYLLqunWVz YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK+3ehmLdjJVXFtsmYD4xaOLkZODgkBE4kZ 29cxQ9hiEhfurWfrYuTiEBKYzSTxr6uTBcLZwCix+uU3JgjnIJPEuruHWEBahATqJRbemQXW ziKgJXFjw2VWEJtNQEVi5puNbCC2iICaRPvr62D1zALCEuvPzQCrFxZwkpi55BZYDadAoMSX W/8YQWxeAUeJj10f2CHml0o03P0M1isqoCOxev8UFogaQYmTM59AzdSSWD59G8sERsFZSFKz kKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECA5USd4djO8OKh1iFOBg VOLhVUjQDhFiTSwrrsw9xCjJwaQkyltrphMixJeUn1KZkVicEV9UmpNafIhRgoNZSYR3lSZQ jjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgneyOVCjYFFqempFWmZO CUKaiYMTZDgP0HA/kBre4oLE3OLMdIj8KUZdjnWd3/qZhFjy8vNSpcR5N4MUCYAUZZTmwc2B JZhXjOJAbwnz3gSp4gEmJ7hJr4CWMAEtSV6jDbKkJBEhJdXAuFZIz2SzMcuMkqBn8z087cu3 erSHCH1uLJoaw7nX8Z970SqVZV1fr5cxLJvDmaKyaMqG56/Z0j6s3CgbNzXug8Wb6go3acO5 MzOi5Kb+iFllLLdlzl6zfey2ytUVsiInTn3mbIrjcTv+iSujw8AlWvXduU1Pw1Ld7JUbd2UX CF5YXX9k34VGJZbijERDLeai4kQA2UAPMQsDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/i0mP7Kq6Kp_3XhJYqf_UdOzxnvU Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:26:03 -0000 On Mon, 29 Sep 2014, Richard Feezel wrote: > I would like to encourage the group to adopt this document as well. [puts on chair hat] Thanks for speaking up. I think I would like to hear a little bit more support from other WG participants before adopting this as a WG item, though. Does anyone else want to see us pick it up? I think Nico was expressing some opinions on how things like this should be done on IRC, so maybe he would support it? [takes off chair hat] > I plan to do some trial implementation testing and would like to know what > values I can safely use for the Authorization Data fields for CAMMAC and > Authentication Indicators in advance of an official action by this group > and the IANA? The draft-ietf-krb-wg-cammac-10 assigns the ad-type number 96 for AD-CAMMAC. For the AUTHENTICATION-INDICATOR itself (hmm, that should be changed to have an AD- prefix), there is not yet an assigned number, but draft-ietf-kitten-kerberos-iana-registries-03 specifies that negative integer values are for private or local use. You are unlikely to encounter trouble picking a ~random negative 32-bit signed integer and using it for your local implementation, but should expect to change your implementation when an official value is assigned. Does that address your question? -Ben Kaduk From nobody Wed Oct 1 12:28:50 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6FE1A82E2 for ; Wed, 1 Oct 2014 12:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpKH5MF5TDwB for ; Wed, 1 Oct 2014 12:28:47 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FF31A802C for ; Wed, 1 Oct 2014 12:28:47 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i17so1016389qcy.2 for ; Wed, 01 Oct 2014 12:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xGzstiMRk7PGnqYGut4BwJs/HkTeBqBexlUn1+GO49Q=; b=qCKIWVN/hxjwqDHjVw4hwo0mpcP5Rj+eLvQD/6mj5NMWXclhmNX35pIdJthhYAELkY K8NEnpGX3RL1ErKxrrKR0TYrJECYl0ZNyyIwTL+v6VbQ8z/5Yzt0YUahS/urZP2ehzT7 bDvqEVsVAJwvRy3YbeSmAGG0xhFSr+mrOA/iAaWnbq+hgKIfFx3NcwrDyRywGxztoU4z e+VaW8ueZ1JgP1Lxj/bWva7FUyMeC3/RGm9F+Fi3JUI3xOYWgdyRmefNinpZz68Q647/ vRaZ8gVRiHa7KlRutuS1fB5SytVbf7n6qfUXCKpnCLg5h+zSosklms512Sk+1sn/sY51 Sssw== MIME-Version: 1.0 X-Received: by 10.140.95.236 with SMTP id i99mr35316296qge.93.1412191726291; Wed, 01 Oct 2014 12:28:46 -0700 (PDT) Received: by 10.140.106.66 with HTTP; Wed, 1 Oct 2014 12:28:46 -0700 (PDT) In-Reply-To: References: <1409243818.9966.3.camel@redhat.com> Date: Wed, 1 Oct 2014 15:28:46 -0400 Message-ID: From: Richard Feezel To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a11c15a0e33510005046182df Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/V6N_RB7pvu0anu99uAlSzkAE7MQ Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:28:49 -0000 --001a11c15a0e33510005046182df Content-Type: text/plain; charset=UTF-8 On Wed, Oct 1, 2014 at 1:25 PM, Benjamin Kaduk wrote: > On Mon, 29 Sep 2014, Richard Feezel wrote: > > > I would like to encourage the group to adopt this document as well. > > [puts on chair hat] > Thanks for speaking up. I think I would like to hear a little bit more > support from other WG participants before adopting this as a WG item, > though. > > Does anyone else want to see us pick it up? I think Nico was expressing > some opinions on how things like this should be done on IRC, so maybe he > would support it? > [takes off chair hat] > I too would like to hear from other members of the group. > > > I plan to do some trial implementation testing and would like to know > what > > values I can safely use for the Authorization Data fields for CAMMAC and > > Authentication Indicators in advance of an official action by this group > > and the IANA? > > The draft-ietf-krb-wg-cammac-10 assigns the ad-type number 96 for > AD-CAMMAC. > For the AUTHENTICATION-INDICATOR itself (hmm, that should be changed > to have an AD- prefix), there is not yet an assigned number, but > draft-ietf-kitten-kerberos-iana-registries-03 specifies that negative > integer values are for private or local use. You are unlikely to > encounter trouble picking a ~random negative 32-bit signed integer and > using it for your local implementation, but should expect to change your > implementation when an official value is assigned. > > Does that address your question? > Yes, thanks. One related question, would it be appropriate to ask the author of *draft-**jain-kitten-krb-auth-**indicator-01.txt* to include a proposed ad-type value in the next revision? > -Ben Kaduk > -- Richard M Feezel rfeezel@gmail.com --001a11c15a0e33510005046182df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Oct 1, 2014 at 1:25 PM, Benjamin Kaduk <kaduk@mit.edu> w= rote:
On Mon, 29 Sep 2014, Richard Feezel wrote:<= br>
> I would like to encourage the group to adopt this document as well.
[puts on chair hat]
Thanks for speaking up.=C2=A0 I think I would like to hear a little bit mor= e
support from other WG participants before adopting this as a WG item,
though.

Does anyone else want to see us pick it up?=C2=A0 I think Nico was expressi= ng
some opinions on how things like this should be done on IRC, so maybe he would support it?
[takes off chair hat]
I too would like to hear from ot= her members of the group.=C2=A0

> I plan to do some trial implementation testing and would like to know = what
> values I can safely use for the Authorization Data fields for CAMMAC a= nd
> Authentication Indicators in advance of an official action by this gro= up
> and the IANA?

The draft-ietf-krb-wg-cammac-10 assigns the ad-type number 96 for AD-CAMMAC.
For the AUTHENTICATION-INDICATOR itself (hmm, that should be changed
to have an AD- prefix), there is not yet an assigned number, but
draft-ietf-kitten-kerberos-iana-registries-03 specifies that negative
integer values are for private or local use.=C2=A0 You are unlikely to
encounter trouble picking a ~random negative 32-bit signed integer and
using it for your local implementation, but should expect to change your implementation when an official value is assigned.

Does that address your question?
Yes, thanks.=C2=A0 On= e related question, would it be appropriate to ask the author of=C2=A0=C2= =A0draft-j= ain-kitten-krb-auth-indicator-01.txt<= /font>=C2=A0to include a proposed ad-type value in the next revision?
=C2=A0
-Ben Kaduk
--
Richard M Feezel
rfeezel@gmail.com
--001a11c15a0e33510005046182df-- From nobody Wed Oct 1 12:33:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB56B1A86E2 for ; Wed, 1 Oct 2014 12:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWSCxeiHvHK4 for ; Wed, 1 Oct 2014 12:33:32 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id A478E1A86F6 for ; Wed, 1 Oct 2014 12:33:32 -0700 (PDT) X-AuditID: 12074422-f79436d000000c21-06-542c570bd2bf Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 7B.0F.03105.B075C245; Wed, 1 Oct 2014 15:33:31 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s91JXVNk031356; Wed, 1 Oct 2014 15:33:31 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s91JXTKa000636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Oct 2014 15:33:30 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s91JXTte010409; Wed, 1 Oct 2014 15:33:29 -0400 (EDT) Date: Wed, 1 Oct 2014 15:33:29 -0400 (EDT) From: Benjamin Kaduk To: Richard Feezel In-Reply-To: Message-ID: References: <1409243818.9966.3.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrcsdrhNi8LfX2uLo5lUsFl3XzrI5 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBlrJy5iKjjHXHHp22zmBsYvTF2MnBwSAiYS 52euZISwxSQu3FvP1sXIxSEkMJtJ4sTCq4wQzgZGiX8HG6Gcg0wSG9ZtZAZpERKol3g5sROs nUVAS6Lv6SqwsWwCKhIz32xkA7FFBNQk2l9fZwGxmQWEJdafmwHWKyzgJDFzyS2wGk6BQIme 3yeAajg4eAUcJea0ZEDs+sAo0dn7jB2kRlRAR2L1/ilgc3gFBCVOznwCNVNLYvn0bSwTGAVn IUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQTIyhU2V2UdjD+PKh0 iFGAg1GJh1cxQTtEiDWxrLgy9xCjJAeTkiivUZhOiBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3kwfoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgSvMshQwaLU9NSK tMycEoQ0EwcnyHAeoOFWIDW8xQWJucWZ6RD5U4zGHC1Nb3uZONZ1futnEmLJy89LlRLnTQ8F KhUAKc0ozYObBks3rxjFgZ4ThhjIA0xVcPNeAa1iAlqVvEYbZFVJIkJKqoGRW/n403mHrviH xKVu9JmwnMVTu1jPp2vTPxHW/8LRsm3a+/23Nd3sOBh7J6foNosR694aKd8jNx1uXvnY0iGp w/7UKW7fMSXTaK8pJzdyab651xf66M7SzPXybop3I9RVOioKrixc9XXSz1LtEmOd6p/nlkto C7qsdjrKrBZ/WydW/lfxA2UlluKMREMt5qLiRAAG/bhrEgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Rif96KkABONvxPLUdeSOWgtYgF8 Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:33:34 -0000 On Wed, 1 Oct 2014, Richard Feezel wrote: > Yes, thanks. One related question, would it be appropriate to ask the > author of *draft-**jain-kitten-krb-auth-**indicator-01.txt* to include a > proposed ad-type value in the next revision? The authors would need to obtain one from the current registrar for them, who reads this mailing list. I'm not entirely sure what criteria are required for the issuance of a number at this point, though. -Ben From nobody Wed Oct 1 12:38:52 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2AD1A874A for ; Wed, 1 Oct 2014 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHOq7rxHdPuY for ; Wed, 1 Oct 2014 12:38:49 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166D91A8706 for ; Wed, 1 Oct 2014 12:38:49 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-2e-542c5847c74c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7A.42.23365.7485C245; Wed, 1 Oct 2014 15:38:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s91Jcg4a032048; Wed, 1 Oct 2014 15:38:42 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s91JceaO002664; Wed, 1 Oct 2014 15:38:41 -0400 From: Tom Yu To: Benjamin Kaduk References: <1409243818.9966.3.camel@redhat.com> Date: Wed, 01 Oct 2014 15:38:40 -0400 In-Reply-To: (Benjamin Kaduk's message of "Wed, 1 Oct 2014 15:33:29 -0400") Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqreseoRNi0HrPxuLo5lUsFl3XzrI5 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBnnGw+xFTSzVvyY18PUwNjG0sXIySEhYCJx 78FdRghbTOLCvfVsXYxcHEICs5kktp/fxwqSEBLYwCixeaYiROI1o8S6rilgHWwC0hLHL+9i ArFFBJQkFp9tYQOxmQUsJbZuWQhmCws4Scxccgtq6jomiesT7oE1swioSmzfu4AdJMEp0Mwo MW/hHbAOXgFdiUdTOsFW8whwSqzvf8YIEReUODnzCQvEBi2JG/9eMk1gFJiFJDULSWoBI9Mq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2M4KCU5N/B+O2g0iFGAQ5GJR7eiiTt ECHWxLLiytxDjJIcTEqivEZhOiFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgzfYByvCmJlVWp RfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvBPCgRoFi1LTUyvSMnNKENJMHJwg w3mAhi8AqeEtLkjMLc5Mh8ifYjTmaGl628vEsa7zWz+TEEtefl6qlDhvOUipAEhpRmke3DRY YnnFKA70nDBvAUgVDzApwc17BbSKCWhV8hptkFUliQgpqQbGrviuhJ1xB9QanqnU7GjVYd++ pPJ8SolK3PP/H69+m3/O0sOk7UL1gVOfQjd7CO+0ehXZedj+cs2SF5Osvp/kfGywN0Ev5Fno 56xgDoOn8U/vv9WWyZ968anlUxPnmxlq55NO1m7VFN0ifF3S9Ou695uFRI8WPigoPzKf0zbq s3nqb4Oe++J8SizFGYmGWsxFxYkAMsfg9gcDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mUH287TgIuBIOHds2J0sL_cCYXI Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:38:50 -0000 Benjamin Kaduk writes: > On Wed, 1 Oct 2014, Richard Feezel wrote: > >> Yes, thanks. One related question, would it be appropriate to ask the >> author of *draft-**jain-kitten-krb-auth-**indicator-01.txt* to include a >> proposed ad-type value in the next revision? > > The authors would need to obtain one from the current registrar for them, > who reads this mailing list. I'm not entirely sure what criteria are > required for the issuance of a number at this point, though. I think it would be best for the working group to adopt the draft as a WG draft before making any provisional number assignments. From nobody Wed Oct 1 17:08:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D271A8856 for ; Wed, 1 Oct 2014 17:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, THIS_AD=0.086] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLI4nCxUvniW for ; Wed, 1 Oct 2014 17:08:45 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C49CC1A8841 for ; Wed, 1 Oct 2014 17:08:45 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 8B0402F406A; Wed, 1 Oct 2014 17:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=DNo9AoHM0zPZSc Ei3X3TYVOhbDg=; b=jlTJ95HXTv4owb8e9Kcw5uQkQ2tb+6RjTEQoJhFDYseFTb fv2G5WU9l7vSeAoI3Fl4rPgeCasUA/S+yW5wpeqJ6JiHbHURShmAazoMbTUZGveP jx26mm1/NRMrcPjFTihpD3aWJkdttqFTfdyv9NJQI/SpYf+MmjtFr/kpm5/R8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 3CF422F4060; Wed, 1 Oct 2014 17:08:45 -0700 (PDT) Date: Wed, 1 Oct 2014 19:08:29 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20141002000828.GB12143@localhost> References: <1409243818.9966.3.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409243818.9966.3.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tk_O8xVVxtwMIE64-xiGQ-svyhw Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 00:08:46 -0000 IMO the WG should adopt this I-D. Registrations for the LoA registry suitable for use with this AD would be nice. Nico -- From nobody Thu Oct 2 09:13:51 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A898D1A87B0 for ; Thu, 2 Oct 2014 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.687 X-Spam-Level: X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwP6DJSltxNo for ; Thu, 2 Oct 2014 09:13:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0FB1A8760 for ; Thu, 2 Oct 2014 09:13:35 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s92GDXY7012948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Oct 2014 12:13:33 -0400 Received: from willson.usersys.redhat.com (ovpn-113-127.phx2.redhat.com [10.3.113.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s92GDWd0021475 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Oct 2014 12:13:33 -0400 Date: Thu, 2 Oct 2014 12:13:31 -0400 From: Simo Sorce To: Benjamin Kaduk Message-ID: <20141002121331.71cc8f3d@willson.usersys.redhat.com> In-Reply-To: References: <1409243818.9966.3.camel@redhat.com> Organization: Red Hat, Inc MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/P_-XMqyds48ElxWFlpjNp7yqJkE Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:13:47 -0000 On Wed, 1 Oct 2014 13:25:52 -0400 (EDT) Benjamin Kaduk wrote: > Does anyone else want to see us pick it up? I do! Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Oct 2 16:40:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422031ACF9C for ; Thu, 2 Oct 2014 16:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PetM0T9va5z1 for ; Thu, 2 Oct 2014 16:40:15 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id ACF031A87DE for ; Thu, 2 Oct 2014 16:40:15 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 2FBDA59805F for ; Thu, 2 Oct 2014 16:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=dDC23m6WHrcGCd/YqOj6w0vdCwM=; b=RocM14SE4I6 buQFtB1vnO13mEn/E3kKdTCsga7XsGnq5y6H8hmhMBYcYf86Mau41/tmnXDeBRPA +HQOQUzGRSDs+3srkTn5cFOpEou+iEmE5dl2lqLbvXfFEAFCkbqvJJwPMcjrKaYJ JnUq8XefU7vN08GO6imf0p46W51RiqPM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 0C6FF598058 for ; Thu, 2 Oct 2014 16:40:14 -0700 (PDT) Date: Thu, 2 Oct 2014 18:40:14 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141002234012.GD412@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/beFJATlVHc1ht6jVLALja4RQZ3o Subject: [kitten] New enctypes for just RFC4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 23:40:16 -0000 We have bulk data GSS apps that could use faster enctypes. We've discussed and rejected [as unsafe for use with long-term secret keys] modern AEAD cipher modes for Kerberos. Maybe we could have RFC4121-only enctypes? We could extend RFC3961 to support AEAD enctypes not to be used in Kerberos *except* as a sub-key in AP-REPs (EncAPRepPart). Or we could have a completely new entype framework (very close to RFC3961 perhaps) with distinct enctype number namespace and a new negotiation extension for RFC4121. Extending RFC3961 seems like a simpler way to go. My preference is to extend RFC3961 but declare some enctypes to be only for use in RFC4121 per-message tokens, KRB-{SAFE,PRIV,CRED}, and similar applications, and not for use in any other RFC4120 PDUs. Possible enctypes would include: - {AES, Camellia} x {GCM, OCB, Poly1305} - {Salsa20, Chacha} x {Poly1305} AES-OCB with AES-NI is particularly appealing. The need to not encrypt more than 2^48 blocks (4PB) probably argues for synchronous re-keying (derive new keys for a per-msg token with the Nth block, for some N <= 2^48). I'm curious about WG participants' reactions. Nico -- From nobody Thu Oct 2 18:04:50 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D031ACFBC for ; Thu, 2 Oct 2014 18:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okloNKFcXscV for ; Thu, 2 Oct 2014 18:04:46 -0700 (PDT) Received: from mail.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9641ACFB7 for ; Thu, 2 Oct 2014 18:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1412298284; x=1412903084; q=dns/txt; h=DomainKey-Signature:Received:VBR-Info:Message-ID: Date:From:Organization:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:OpenPGP:Content-Type; bh=xI6oMn+uBjt6dIli lyJAoo8tFthWeA1bmhRQc5Zsx8k=; b=Da901ms5zO1t8+6A4DQR/yqMC57JrrwB R/+GjwONJmu9d7vyJRDjEssCkyYrXewLjK50Tm4JOlWfzJENNKUZ0JYpHXcsPMhv nIyo6qCIaB1o54ADXvb31b6PMaNS4Oe+IAS745akLWtoGPs4vbvlO893vN5Ioj4O JSLKWjuPLss= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=lIdOmgGfpjGMoOMzPzmVQnk22EQKgb2SqHeo3Y5+p0/30NvHrxkci3KKrokw HXvsedCXP5aPe9/dKItNcuQhsGSlK8ND3Y8Nz3c6ONgE9TdUcqKQYczZR XIw7erzX32LLeiuti1zLPlDGpSCrtcZjFNciIWcDQeodwvVOq5O+Xg=; X-MDAV-Result: clean X-MDAV-Processed: mail.secure-endpoints.com, Thu, 02 Oct 2014 21:04:44 -0400 X-Spam-Processed: mail.secure-endpoints.com, Thu, 02 Oct 2014 21:04:43 -0400 Received: from [172.16.16.54] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.0.3) with ESMTP id md50000739129.msg for ; Thu, 02 Oct 2014 21:04:42 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-Authenticated-Sender: jaltman@secure-endpoints.com X-HashCash: 1:22:141003:md50000739129::jvxGUZJn0qHUTseM:0000LyZe X-Return-Path: prvs=13533d26ac=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <542DF624.8070108@secure-endpoints.com> Date: Thu, 02 Oct 2014 21:04:36 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Nico Williams , kitten@ietf.org References: <20141002234012.GD412@localhost> In-Reply-To: <20141002234012.GD412@localhost> OpenPGP: id=92B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050504090207050502040105" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VkZtrEBxK1VNwhHKgZ0SMCov8Wc Subject: Re: [kitten] New enctypes for just RFC4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:04:48 -0000 This is a cryptographically signed message in MIME format. --------------ms050504090207050502040105 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 3961 was split from Kerberos so the framework could be used by application protocols other than Kerberos. I believe that includes the ability to define enctypes within the framework that are not applicable for use with Kerberos itself. Jeffrey Altman On 10/2/2014 7:40 PM, Nico Williams wrote: >=20 > We have bulk data GSS apps that could use faster enctypes. >=20 > We've discussed and rejected [as unsafe for use with long-term secret > keys] modern AEAD cipher modes for Kerberos. >=20 > Maybe we could have RFC4121-only enctypes? >=20 > We could extend RFC3961 to support AEAD enctypes not to be used in > Kerberos *except* as a sub-key in AP-REPs (EncAPRepPart). Or we could > have a completely new entype framework (very close to RFC3961 perhaps) > with distinct enctype number namespace and a new negotiation extension > for RFC4121. >=20 > Extending RFC3961 seems like a simpler way to go. >=20 > My preference is to extend RFC3961 but declare some enctypes to be only= > for use in RFC4121 per-message tokens, KRB-{SAFE,PRIV,CRED}, and simila= r > applications, and not for use in any other RFC4120 PDUs. >=20 > Possible enctypes would include: >=20 > - {AES, Camellia} x {GCM, OCB, Poly1305} > - {Salsa20, Chacha} x {Poly1305} >=20 > AES-OCB with AES-NI is particularly appealing. The need to not encrypt= > more than 2^48 blocks (4PB) probably argues for synchronous re-keying > (derive new keys for a per-msg token with the Nth block, for some N <=3D= > 2^48). >=20 > I'm curious about WG participants' reactions. >=20 > Nico >=20 --------------ms050504090207050502040105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhA5 oFEXaG88XscBgkTPSsu4MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtcVgrUA+Zl527P0yx xfkiLZzymUZLAwif9amX6c79OHd17CN5Hg3TIRXi0exjq/z/K2eftbSfj3XatgllPtlmCktq i4daJTVLifx5G7qbcYjQgKpex/8FA3gfvJJNgMef5OwOTE1HqMJsp5CAquFjw/ReiXQqduou 1nHhUhX1AXBpaQmYDOQZwrTD41yT7qm22N67vV0viWG9x/1RdFqqtIOIyKR+ojD3IN0wufES gy7hsWgmghh4jkrclmMIXuo+AAtmJHzwzF4hCrSqdwiRXU4aghTjsmehtMT1nFfzDPylaclO p7IY4xeQm/q1cbU3uEqxhy06sYeVbh6zfTDBAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAACPkJV5NIxzjKc+WveaoM8Uc86wX0yLBm1A33z4 rLVXTWPi5kMIJ6kfE+dFWcMdyyOgZ2VcxIwneZ50LcITFv1VOfRkrX32vVChQqs8XGqerIo/ K3epyFEg01qHq/4byolXW6UOvmZb3oHhtHDGS94Vv6Fu6wV7irAdoM18cqzQsxU0nZDMnY5k 0pKJHLTrsC/uKuoWGz8xLLyeayi37ZsXsbGdazqzVMIoLvFTMjaFuoCetEbiFQZvnuHKwdbV YqyCY28Cl8DVRHrInZrz84xqFiGZNSfFRWOougT47VRDA8SVy6pOtDaOmkxcYXlh5Ezo29FB OiA0+tF8qgMmq3QxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEDmgURdobzxexwGCRM9Ky7gwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQxMDAzMDEwNDM2WjAjBgkqhkiG9w0BCQQxFgQUFCl33KhtdEBT8zApqJCjtexXFX4wbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQOaBRF2hvPF7HAYJEz0rLuDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhA5oFEXaG88XscBgkTPSsu4MA0GCSqGSIb3DQEBAQUABIIB AA5+FxEqJ9OFP0QzHMAAVz/nbPNXVufD3Lf/wIrUcBX40UiX0YI3uWobUnkzwRWhK4RYcVsA 6SGhDtG59ksmyS9ri4s4SVVgN6qaCVTbZbJx2dHTtqVeD1mjfHjkovnEwLf5Ygb6AH3N98lv nAD0d/aGEIUIkw1ildDx2LS6LI7wn6fJ4XlIxXo1fDkNNsPj45QbNnFgQOf+QE/uBxE56c4n fK1cpTidjbS+aw1x86RXpIjOqkhkUAiHqx7mjSP7KyXgbQkJE26rC+FJ0m5p/Jw+wqNZKMQc XE7yuzVkfTFh+oAeoV1bk5BVWLs9MRfznT2Xb2kfI0gkjJ2x+odRCiQAAAAAAAA= --------------ms050504090207050502040105-- From nobody Thu Oct 2 18:06:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFC31ACFBC for ; Thu, 2 Oct 2014 18:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUHH6CinliYt for ; Thu, 2 Oct 2014 18:06:26 -0700 (PDT) Received: from mail.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2FE1ACFB7 for ; Thu, 2 Oct 2014 18:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1412298385; x=1412903185; q=dns/txt; h=DomainKey-Signature:Received:VBR-Info:Message-ID: Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:OpenPGP:Content-Type; bh=fxpiNUYexKDs1I87 toADWgH2jc6Dq019mkao1B4XXJA=; b=LlFwEOJ3hDAMJIM9GWIdkG60/zfydm4F 40oJ/tQ5BpXeUykovjayikBBsK6kSu3BIpPhynenizaSzl1nloSnlnI4k8Oxameu lnWhUuIyVCDwDKioAXZlXIHfi0R63rA4IlbVEK7IoaHgnMYuv9Dl1UnZVcZFaldV DqRFtkdEASI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=ccxHR1RxAqb3m/eRdaJ8oFfOk38+lYbaPZhmZtgdVPBR+FTVyjYpAw5c3PG8 vvhcr1h0SGrJXJFWbh5OrxUXETmOrsSmH2gUcT9AozgTn3VYnsjOP972T a+eU8x1easjys1auFESns7OAjlsdFgflp2I6KVRa2WcTzJRu2oYqoE=; X-MDAV-Result: clean X-MDAV-Processed: mail.secure-endpoints.com, Thu, 02 Oct 2014 21:06:25 -0400 X-Spam-Processed: mail.secure-endpoints.com, Thu, 02 Oct 2014 21:06:24 -0400 Received: from [172.16.16.54] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.0.3) with ESMTP id md50000739131.msg for ; Thu, 02 Oct 2014 21:06:23 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-Authenticated-Sender: jaltman@secure-endpoints.com X-HashCash: 1:22:141003:md50000739131::WtPR8VNDBkrCBXPF:0000AURa X-Return-Path: prvs=13533d26ac=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <542DF688.4060008@secure-endpoints.com> Date: Thu, 02 Oct 2014 21:06:16 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Nico Williams , Nathaniel McCallum References: <1409243818.9966.3.camel@redhat.com> <20141002000828.GB12143@localhost> In-Reply-To: <20141002000828.GB12143@localhost> OpenPGP: id=92B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010703010009030109050000" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/eO7b5RZAhPH7fEnUPjtZG5g67Wo Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:06:27 -0000 This is a cryptographically signed message in MIME format. --------------ms010703010009030109050000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/1/2014 8:08 PM, Nico Williams wrote: >=20 > IMO the WG should adopt this I-D. +1 > Registrations for the LoA registry suitable for use with this AD would > be nice. +1 --------------ms010703010009030109050000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhA5 oFEXaG88XscBgkTPSsu4MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtcVgrUA+Zl527P0yx xfkiLZzymUZLAwif9amX6c79OHd17CN5Hg3TIRXi0exjq/z/K2eftbSfj3XatgllPtlmCktq i4daJTVLifx5G7qbcYjQgKpex/8FA3gfvJJNgMef5OwOTE1HqMJsp5CAquFjw/ReiXQqduou 1nHhUhX1AXBpaQmYDOQZwrTD41yT7qm22N67vV0viWG9x/1RdFqqtIOIyKR+ojD3IN0wufES gy7hsWgmghh4jkrclmMIXuo+AAtmJHzwzF4hCrSqdwiRXU4aghTjsmehtMT1nFfzDPylaclO p7IY4xeQm/q1cbU3uEqxhy06sYeVbh6zfTDBAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAACPkJV5NIxzjKc+WveaoM8Uc86wX0yLBm1A33z4 rLVXTWPi5kMIJ6kfE+dFWcMdyyOgZ2VcxIwneZ50LcITFv1VOfRkrX32vVChQqs8XGqerIo/ K3epyFEg01qHq/4byolXW6UOvmZb3oHhtHDGS94Vv6Fu6wV7irAdoM18cqzQsxU0nZDMnY5k 0pKJHLTrsC/uKuoWGz8xLLyeayi37ZsXsbGdazqzVMIoLvFTMjaFuoCetEbiFQZvnuHKwdbV YqyCY28Cl8DVRHrInZrz84xqFiGZNSfFRWOougT47VRDA8SVy6pOtDaOmkxcYXlh5Ezo29FB OiA0+tF8qgMmq3QxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEDmgURdobzxexwGCRM9Ky7gwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQxMDAzMDEwNjE2WjAjBgkqhkiG9w0BCQQxFgQU2ozB9PwWF1SBPJZ7cr2MWZhncGIwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQOaBRF2hvPF7HAYJEz0rLuDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhA5oFEXaG88XscBgkTPSsu4MA0GCSqGSIb3DQEBAQUABIIB AKr16uZCndgkndaJjivEahNgfbczRZ1zPqbMOZagQ/rcnd44Y7ktpO3Xdrwe3uL2qBWo/hFQ +kH4UyEkcbBS6/lrd+uR4KNHLe7Ce6hFpkas7dLX28cRYCL5xE+hFZEoQVpSBcL2ks3onBmB EUBaBte95Z98fcnFvWtJAjypMOTIBdLDgnMsq5fq5WVRGrCkfDPVpmJJSnFgcwdDjwYmGiAA j6peXV4lTQc6IwwMZxPZueYiq3XyfcGZbF3fJ7G146i7I7sZG9hx2EMP9vQEwNh9XP8Ju1hN SGMrBEEB3uA+WogYFQeTk5qfqcnqOLIwNkf6B5l7uXk0Mj6SNFsXPeUAAAAAAAA= --------------ms010703010009030109050000-- From nobody Fri Oct 3 08:21:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23CF1A0120 for ; Fri, 3 Oct 2014 08:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKLDec_rCEfg for ; Fri, 3 Oct 2014 08:20:54 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598AF1A0222 for ; Fri, 3 Oct 2014 08:20:54 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-a6-542ebed46cf1 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 97.89.27750.4DEBE245; Fri, 3 Oct 2014 11:20:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s93FKqHc030029; Fri, 3 Oct 2014 11:20:52 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s93FKowq015166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2014 11:20:51 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s93FKnum009265; Fri, 3 Oct 2014 11:20:49 -0400 (EDT) Date: Fri, 3 Oct 2014 11:20:49 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1409243818.9966.3.camel@redhat.com> Message-ID: References: <1409243818.9966.3.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nont1n16Iwe9/jBZHN69isZj7dRar A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJVx/NsZ9oLHohU/ulwaGK8JdjFyckgImEhs ubaUDcIWk7hwbz2QzcUhJDCbSWLi7dnMEM4GRonb619BOQeZJBrnNLOCtAgJ1EtsX74FrJ1F QEti99vjzCA2m4CKxMw3G8HiIgJ6Esv2TWAEsZkFhCXWn5sBViMs4CQxc8ktsBpOAUOJ9y8O soPYvAKOEq07DzF1MXIAzTeQePtDGiQsKqAjsXr/FBaIEkGJkzOfsECM1JJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdTLzSzRS00p3cQIClNOSZ4djG8OKh1i FOBgVOLh/XBDN0SINbGsuDL3EKMkB5OSKC/3Nr0QIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8 C1YC5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHg/7gFqFCxKTU+t SMvMKUFIM3FwggznARouuQ9keHFBYm5xZjpE/hSjopQ47+m9QAkBkERGaR5cLyyNvGIUB3pF mPcBSBUPMAXBdb8CGswENPidvS7I4JJEhJRUA+O0eToHe+xXnljHo3mLob34DetspqWRnpNF CkyKY7bbLJlT+ZszVY6NO0fyw43625M7maTCEu5EHpFdq/Zb71iAxd4pbm4hE/a3/J3MqhZy cktk5t4fa9jOPVU2c+qf9TbXZf/CFxKTHnp47fyy+CrnEr/pfOYVTTvXtMdYfLz7496htGsR Ke5KLMUZiYZazEXFiQAjFyhh/gIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ubMT-It_m7yOUbm3aV7RR5_ZO8A Cc: kitten@ietf.org Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:20:59 -0000 Hi Nathaniel, On Thu, 28 Aug 2014, Nathaniel McCallum wrote: > The purpose of Authentication Indicators is to be able to assert some > positive attributes about the authentication event itself in the ticket. > This should also be usable in the case of S4U2Proxy. > > The draft can be found here: > http://www.ietf.org/id/draft-jain-kitten-krb-auth-indicator-01.txt I think we've seen sufficient interest to justify adopting this as a working group document. Please submit the next revision as draft-ietf-kitten-krb-auth-indicator-00 so that the chairs can approve it as a WG document. As an individual, I have some comments about the text. I think that the name of the authorization data type should have an AD- prefix, that is, be AD-AUTHENTICATION-INDICATOR. In section 3, the ad-data field contains the DER encoding of the ASN.1 type whose definition follows, not the "AD type". This document is not the place to make normative statements about the AD-CAMMAC. So, the last paragraph of section 3 should not say that the AD-CAMMAC element MAY be safely ignored. Similarly, the CAMMAC document already has a mechanism for binding the CAMMAC to the enclosing ticket in the definition of the kdc-verifier. If this document needs to say anything about such a binding, it should probably just say that the KDC MUST include a kdc-verifier in the containing CAMMAC, to provide a binding to the enclosing ticket. The document lists RFCs 4120 and 4121 in the references sections, but does not make citations to those references at any point in the main text. I am not sure that 4121 is necessary unless there is a desire to add, e.g., a GSS name attribute by which the authentication indicator may be accessed. For 4120, on the other hand, I think this document should Update: 4120, and mention that in the abstract and introduction at least. After the definition of the ASN.1 type AUTHENTICATION-INDICATOR, you have "These values are short strings[...]". In specification documents like this, it's usually best to avoid generic pronouns like "these" and include concrete bindings, as in "These UTF8String values are[...]". Also, the ASN.1 definition does not include the EXPLICIT TAGS and similar boilerplate usually found when declaring Kerberos ASN.1 modules. That should be present unless we are trying to stuff this into an existing module (in which case that should be stated). In the abstract, I think it may be worth replacing "indicator of the client's authentication strength" with "indicator of the strengh of the client's authentication". There are a few grammar nits (missing "the"s, mostly). I can point them out out-of-band if you don't want to duplicate time looking for them. Thanks, Ben From nobody Fri Oct 3 09:33:59 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0734C1A1A6F for ; Fri, 3 Oct 2014 09:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l4GijkouYXj for ; Fri, 3 Oct 2014 09:33:47 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A0C1A1A4F for ; Fri, 3 Oct 2014 09:33:42 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-5e-542ecfe5838d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 47.79.28565.5EFCE245; Fri, 3 Oct 2014 12:33:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s93GXeM1025380; Fri, 3 Oct 2014 12:33:41 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s93GXdEW010547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2014 12:33:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s93GXcQl018411; Fri, 3 Oct 2014 12:33:38 -0400 (EDT) Date: Fri, 3 Oct 2014 12:33:38 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141002234012.GD412@localhost> Message-ID: References: <20141002234012.GD412@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrPv0vF6IwZwuTYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY8HELS0GbQMWxXVsYGxhf8HQxcnJICJhI 9F5oY4WwxSQu3FvP1sXIxSEkMJtJ4uSKNihnA6PEhI7T7BDOQSaJ07d+grUICdRLbF62kAnE ZhHQkjj6cjIziM0moCIx881GNhBbREBT4vq8pWA2s4CwxPpzM8BqhAWMJaZc+AZmcwroShxu vswIYvMKOEpcvLwdar6OxKOJ68FqRIHs1funsEDUCEqcnPmEBWKmlsTy6dtYJjAKzkKSmoUk tYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZwqEry7mB8d1DpEKMAB6MS D++HG7ohQqyJZcWVuYcYJTmYlER5j5zVCxHiS8pPqcxILM6ILyrNSS0+xCjBwawkwrtgJVCO NyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCd+45oEbBotT01Iq0zJwS hDQTByfIcB6g4QdBaniLCxJzizPTIfKnGBWlxHnZQRICIImM0jy4XlgqecUoDvSKMO9JkCoe YBqC634FNJgJaPA7e12QwSWJCCmpBsbJxhnsAQ0/z2evZN7M4P354HGpZvWedSEa29ZNlw7s 2HEx84zuzBdGC5oa+PQ2FshqRk1clHLGPULg/V7HjYxrbJm/n/FevvqLwJcLcjrN17/e33v6 gZGM2A+G36eqI0IkIl7kpM9X36Z3jPPea2l55yCHwAXmBv5vHh7yFU75Vflm8k/+2pNKLMUZ iYZazEXFiQAauNjbAAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/KtBw1eZPvp5b8IEkyJ_TNuuX3bA Cc: kitten@ietf.org Subject: Re: [kitten] New enctypes for just RFC4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:33:57 -0000 On Thu, 2 Oct 2014, Nico Williams wrote: > > We have bulk data GSS apps that could use faster enctypes. > > We've discussed and rejected [as unsafe for use with long-term secret > keys] modern AEAD cipher modes for Kerberos. > > Maybe we could have RFC4121-only enctypes? > > We could extend RFC3961 to support AEAD enctypes not to be used in > Kerberos *except* as a sub-key in AP-REPs (EncAPRepPart). Or we could > have a completely new entype framework (very close to RFC3961 perhaps) > with distinct enctype number namespace and a new negotiation extension > for RFC4121. > > Extending RFC3961 seems like a simpler way to go. > > My preference is to extend RFC3961 but declare some enctypes to be only > for use in RFC4121 per-message tokens, KRB-{SAFE,PRIV,CRED}, and similar > applications, and not for use in any other RFC4120 PDUs. > > Possible enctypes would include: > > - {AES, Camellia} x {GCM, OCB, Poly1305} > - {Salsa20, Chacha} x {Poly1305} > > AES-OCB with AES-NI is particularly appealing. The need to not encrypt > more than 2^48 blocks (4PB) probably argues for synchronous re-keying > (derive new keys for a per-msg token with the Nth block, for some N <= > 2^48). > > I'm curious about WG participants' reactions. The thought of having RFC 3961 enctypes specified that are forbidden for use with generic RFC 4120 messages does not inherently make me cringe. I do have some concerns about an "enctype explosion", i.e., doing the full cartesian product spaces you listed above would be way too many for my taste. Partially as a consequence of that, but partially on its own merit, I think we would want to see some (performance) metrics to justify the addition of a new enctype before we would adopt such a proposal. "It seems like a neat idea" is not really a sufficient justification, but "we can get 100% more throughput" probably is. We should probably get feedback from more people before asking you to go off and prototype something and gather metrics, though. -Ben From nobody Fri Oct 3 09:44:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B69F1A0390 for ; Fri, 3 Oct 2014 09:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygaGwRNjOlrp for ; Fri, 3 Oct 2014 09:44:20 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6E80A1A00AD for ; Fri, 3 Oct 2014 09:44:20 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 32EB84012D697; Fri, 3 Oct 2014 09:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=PnPR0u1VKa3wmY d9Kx7zMSkkkEU=; b=fKK69GOebaNPpNDYeb7RLRxoUt1r6kRmB+udlhmMXZm0nF 3KAoiwCeRtcuTs3XmfD0ZQ6crZZioLuGdDX/JGfcS2U0BViQrpPByF5woTdc5yzC mS5e81zxRncr1IcnaFx47rCotIcc4x/jiit6DA4c93o5FePMQALOSoKCbaDGU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id CC3F8400F8A2A; Fri, 3 Oct 2014 09:44:19 -0700 (PDT) Date: Fri, 3 Oct 2014 11:44:19 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141003164417.GA4981@localhost> References: <20141002234012.GD412@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/MNNE1lZ8p2D-TxAk0TqswYdni5s Cc: kitten@ietf.org Subject: Re: [kitten] New enctypes for just RFC4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:44:22 -0000 On Fri, Oct 03, 2014 at 12:33:38PM -0400, Benjamin Kaduk wrote: > The thought of having RFC 3961 enctypes specified that are forbidden for > use with generic RFC 4120 messages does not inherently make me cringe. Good. As Jeff points out, RFC3961 is not just for Kerberos. > I do have some concerns about an "enctype explosion", i.e., doing the full > cartesian product spaces you listed above would be way too many for my > taste. Unlike TLS, there's only two variables for the cartesian product here, so I'm not concerned about this, but I'd be happy to pare down the list. > Partially as a consequence of that, but partially on its own merit, I > think we would want to see some (performance) metrics to justify the > addition of a new enctype before we would adopt such a proposal. "It > seems like a neat idea" is not really a sufficient justification, but "we > can get 100% more throughput" probably is. AES-OCB is much faster than AES-CTS-HMAC-SHA1-96. (This should be obvious, numbers or no.) > We should probably get feedback from more people before asking you to go > off and prototype something and gather metrics, though. Yes, exactly. I don't want to spend a lot of effort on failing. Nico -- From nobody Fri Oct 3 09:57:02 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7FE1A6EEC for ; Fri, 3 Oct 2014 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7OncBUToK_N for ; Fri, 3 Oct 2014 09:56:59 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E806E1A1F70 for ; Fri, 3 Oct 2014 09:56:59 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id C0384360072 for ; Fri, 3 Oct 2014 09:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=jH1D1THAKIq0YQsrlz0jf/G6WSA =; b=cQrlNrJQRBDIdnI6pd4bsYYeeR2XgJr1acb0ougE06XdhoM1OPCb+Vkjnb+ MzbnOw6WXleyKBPlvYc7b1tdytr9Z1CiNIUHV4UyvmpUmvZtuOYa7gzfLnMueIiC VDilIw+GKS+u557YlVHXN3FCa/pCbjtsJG/eLphcvfUbWo38= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 8FD3A36006B for ; Fri, 3 Oct 2014 09:56:59 -0700 (PDT) Date: Fri, 3 Oct 2014 11:56:59 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141003165657.GB4981@localhost> References: <20141002234012.GD412@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002234012.GD412@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Q1FPc2ZCOL23lJ40gXQutQac48U Subject: Re: [kitten] New enctypes for just RFC4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:57:00 -0000 Another possibility would be to create a new framework now and extend RFC3961 to encompass it later. The new framework would share the enctype number namespace with RFC3961, thus making it possible to not have to extend the mechanism's enctype negotiation (and, for example, not have to extend AP-REP). OTOH, it's about time we extended AP-REP. There are a few choices to make here before prototyping if the prototype is to have a chance of not having to get thrown out later: 0) extend RFC3961 or not (if yes, stop here) 1) if not, share the enctype number namespace with RFC3961 so as to permit future extension of RFC3961 to encompass AEAD ciphers, or not (if yes, stop here) 2) if not, we must extend AP-REP. Help me make these decisions :) For now I'm looking to estimate implementation costs, not necessarily to implement. Any choices we make that tend to lower those costs will tend to increase the chances of any implementations materializing. I don't really want to bother with an I-D first, but the high-level design should be settled as soon as possible, if at all possible. Nico -- From nobody Fri Oct 3 12:44:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2920B1A1AEE for ; Fri, 3 Oct 2014 12:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJkBxA--7my6 for ; Fri, 3 Oct 2014 12:44:26 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6561A1A9F for ; Fri, 3 Oct 2014 12:44:26 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 52D3520047D12 for ; Fri, 3 Oct 2014 12:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=f4MYumBg94Y3X/7ZlyyqINY6CFQ =; b=TLPIj4i6/wUULMCLBdmYa0I0AroqAL/2+Qy1l1rzqN/rvuObzR4n0NY2GIZ ew131XaL/dj5Ih1fBPwqY4o5D6Yl/glRz2exF4k9BpyHQrACwNSt5e4UmLZFvCVn XNgC/eEW/vYOPF8aFdvZJGBcuogPPPj8BsPNgdzNq86+wzF8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 1B4C920046912 for ; Fri, 3 Oct 2014 12:44:26 -0700 (PDT) Date: Fri, 3 Oct 2014 14:44:25 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141003194423.GF4981@localhost> References: <20141002234012.GD412@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002234012.GD412@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mEkxOO06fvStNsgthk2puyyFoew Subject: Re: [kitten] New enctypes for just RFC4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:44:27 -0000 An RFC3961 extension for AEAD enctypes would actually be straightforward. AEAD enctypes would: - provide new authenticated_encryption and authenticated_decryption functions and - not provide the old encryption, decryption, get_mic, and verify_mic functions This should suffice to keep Kerberos from using these enctypes, though we'd have to say something about the AS/TGS clients and servers (KDCs) not attempting to negotiate these new enctypes (else they'd fail hard). Nico -- From nobody Fri Oct 3 13:14:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5C81A1B45; Fri, 3 Oct 2014 13:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9A1nMvPxGrR; Fri, 3 Oct 2014 13:14:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F241A1B38; Fri, 3 Oct 2014 13:14:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141003201430.16665.61458.idtracker@ietfa.amsl.com> Date: Fri, 03 Oct 2014 13:14:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zISEguR3iJcfsWUViirkkBMnFQQ Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:14:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-11.txt Pages : 9 Date : 2014-10-03 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. This document updates RFC 4120. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 3 13:24:58 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C431A1B7E for ; Fri, 3 Oct 2014 13:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UOtvvh9cTCn for ; Fri, 3 Oct 2014 13:24:53 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id A1D2C1A1B69 for ; Fri, 3 Oct 2014 13:24:53 -0700 (PDT) X-AuditID: 12074422-f79436d000000c21-a1-542f06144e64 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id F0.44.03105.4160F245; Fri, 3 Oct 2014 16:24:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s93KOqk1004278 for ; Fri, 3 Oct 2014 16:24:52 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s93KOpXW002702 for ; Fri, 3 Oct 2014 16:24:52 -0400 From: Tom Yu To: References: <20141003201430.16665.61458.idtracker@ietfa.amsl.com> Date: Fri, 03 Oct 2014 16:24:51 -0400 In-Reply-To: <20141003201430.16665.61458.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 3 Oct 2014 13:14:30 -0700") Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixCmqrSvKph9i0PSG0eLo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPL7FmvBHt6K5V8WMDYwbubqYuTkkBAwkXh8vZsVwhaTuHBv PVsXIxeHkMBsJom+ZzNZIZxjjBL3j01jh3AamSQ2zrnAAtLCJiAtcfzyLiYQW0RAVGL2lldA cQ4OYQFHiaPTEkHCQkDmjtUnwcpZBFQlJk3cxggyh1Ogn1Hi8bxHjCAJXgFdiZ8fGsHO4BHg lJh75zYzRFxQ4uTMJ2DNzAJaEjf+vWSawMg/C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJ eXmpRbqmermZJXqpKaWbGEFhxu6itIPx50GlQ4wCHIxKPLwfbuiGCLEmlhVX5h5ilORgUhLl fcCkHyLEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhJflkV6IEG9KYmVValE+TEqag0VJnHfTD74Q IYH0xJLU7NTUgtQimKwMB4eSBG84K9BQwaLU9NSKtMycEoQ0EwcnyHAeoOHWIDW8xQWJucWZ 6RD5U4yKUuK8oiAJAZBERmkeXC8sDbxiFAd6RZg3EKSKB5hC4LpfAQ1mAhr8zl4XZHBJIkJK qoFRYFHciqUqK7/+bk9ycb1Up3Il7X6uqeT9zd5X+J2+JB3rkL13iL9OVD58203xkIDpWo4/ NgcfEN9/y+iwmnRSxXaLwgv6fmntAieEOOPaWE3sm0uvhk/J6jLs3i46sefcEYWHEzZ8OP7n 40xhO/tl/Hs1dvxeFptdqnaxZrmI/8sLM89xO/cqsRRnJBpqMRcVJwIAqom9gt4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nJdB9emwCzVYjy-mI7BmyM6ELZE Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:24:56 -0000 This revision fixes some minor nits noted by Ben Kaduk during shepherd writeup. writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Kerberos Authorization Data Container Authenticated by Multiple MACs > Authors : Simo Sorce > Tom Yu > Thomas Hardjono > Filename : draft-ietf-krb-wg-cammac-11.txt > Pages : 9 > Date : 2014-10-03 > > Abstract: > Abstract: This document specifies a Kerberos Authorization Data > container that supersedes AD-KDC-ISSUED. It allows for multiple > Message Authentication Codes (MACs) or signatures to authenticate the > contained Authorization Data elements. This document updates RFC > 4120. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Fri Oct 3 16:57:44 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4C91A89E9 for ; Fri, 3 Oct 2014 16:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg7HqrNidlge for ; Fri, 3 Oct 2014 16:57:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0091.outbound.protection.outlook.com [207.46.100.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA93C1A7D85 for ; Fri, 3 Oct 2014 16:57:40 -0700 (PDT) Received: from BN1PR06MB373.namprd06.prod.outlook.com (10.141.61.11) by BN1PR06MB440.namprd06.prod.outlook.com (10.141.58.24) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 3 Oct 2014 23:57:37 +0000 Received: from BY2PR06CA037.namprd06.prod.outlook.com (10.141.250.155) by BN1PR06MB373.namprd06.prod.outlook.com (10.141.61.11) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Fri, 3 Oct 2014 23:57:36 +0000 Received: from BN1AFFO11FD027.protection.gbl (2a01:111:f400:7c10::183) by BY2PR06CA037.outlook.office365.com (2a01:111:e400:2c60::27) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Fri, 3 Oct 2014 23:57:35 +0000 Received: from mail.usda.gov (199.135.140.19) by BN1AFFO11FD027.mail.protection.outlook.com (10.58.52.87) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Fri, 3 Oct 2014 23:57:34 +0000 Received: from 001FSN2MMR1-015.001f.mgd2.msft.net (199.135.140.70) by 001FSN2MMR1-009.001f.mgd2.msft.net (199.135.140.19) with Microsoft SMTP Server (TLS) id 14.3.195.2; Fri, 3 Oct 2014 23:57:33 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.228]) by 001FSN2MMR1-015.001f.mgd2.msft.net ([199.135.140.70]) with mapi id 14.03.0195.002; Fri, 3 Oct 2014 23:57:32 +0000 From: "Nordgren, Bryce L -FS" To: "kitten@ietf.org" Thread-Topic: Status of draft-ietf-kitten-sasl-saml-ec-11 Thread-Index: Ac/fZVce1AcI3lmCR0eu71GvmSKl1A== Date: Fri, 3 Oct 2014 23:57:32 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7335C5@001FSN2MPN1-045.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.121] Content-Type: multipart/alternative; boundary="_000_82E7C9A01FD0764CACDD35D10F5DFB6E7335C5001FSN2MPN1045001_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:199.135.140.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(199003)(189002)(92726001)(92566001)(69596002)(31966008)(16796002)(19580395003)(512954002)(85306004)(76482002)(19625215002)(86362001)(230783001)(68736004)(15202345003)(6806004)(64706001)(20776003)(2501002)(44976005)(22756005)(71186001)(97736003)(84676001)(33656002)(77096002)(99396003)(81156004)(16236675004)(86146001)(106466001)(74482002)(46102003)(110136001)(87936001)(80022003)(19300405004)(21056001)(2656002)(54356999)(4396001)(55846006)(95666004)(15975445006)(107886001)(84326002)(85852003)(10300001)(66066001)(50986999)(229853001)(2351001)(120916001)(107046002)(80862005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR06MB373; H:mail.usda.gov; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB373; X-Forefront-PRVS: 0353563E2B Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.19 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.19; helo=mail.usda.gov; Authentication-Results: spf=pass (sender IP is 199.135.140.19) smtp.mailfrom=bnordgren@fs.fed.us; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB440; X-OriginatorOrg: fs.fed.us Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lnYo8Jd3BShjcXYuGJzFhCb2BiE Subject: [kitten] Status of draft-ietf-kitten-sasl-saml-ec-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 23:57:43 -0000 --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7335C5001FSN2MPN1045001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seemed there was some good discussion in march, resulting mostly in the nee= d to clarify some aspects? Please don't let it die. :) Bryce This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7335C5001FSN2MPN1045001_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seemed there was some good discussion in march, resu= lting mostly in the need to clarify some aspects?

 

Please don’t let it die. J

 

Bryce





This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you have received this message in er= ror, please notify the sender and delete the email immediately. --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7335C5001FSN2MPN1045001_-- From nobody Fri Oct 3 17:02:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4580F1A8741 for ; Fri, 3 Oct 2014 17:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DYkrevPkQLy for ; Fri, 3 Oct 2014 17:02:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E021A7031 for ; Fri, 3 Oct 2014 17:01:59 -0700 (PDT) Received: from BL2FFO11FD018.protection.gbl (10.173.160.30) by BL2FFO11HUB055.protection.gbl (10.173.161.155) with Microsoft SMTP Server (TLS) id 15.0.1029.15; Sat, 4 Oct 2014 00:01:58 +0000 Received: from cio-krc-pf01.osuad.osu.edu (164.107.81.208) by BL2FFO11FD018.mail.protection.outlook.com (10.173.161.36) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Sat, 4 Oct 2014 00:01:58 +0000 Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-krc-pf01.osuad.osu.edu (Postfix) with ESMTPS id 3DA06A0066; Fri, 3 Oct 2014 20:01:58 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0174.001; Fri, 3 Oct 2014 20:01:57 -0400 From: "Cantor, Scott" To: "Nordgren, Bryce L -FS" , "kitten@ietf.org" Thread-Topic: [kitten] Status of draft-ietf-kitten-sasl-saml-ec-11 Thread-Index: AQHP32ZphYp3qQv33EOSO3oVhhLN9Q== Date: Sat, 4 Oct 2014 00:01:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [65.31.0.111] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.208; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(479174003)(189002)(24454002)(199003)(51704005)(10300001)(92566001)(107046002)(109096001)(6806004)(54356999)(107886001)(120916001)(90282001)(23756003)(21056001)(230783001)(99396003)(88552001)(80022003)(2501002)(75432002)(2656002)(89122001)(50466002)(44976005)(46102003)(85306004)(76482002)(77096002)(19580395003)(106116001)(19580405001)(86362001)(95666004)(92726001)(64706001)(85852003)(50986999)(106466001)(4396001)(66066001)(87936001)(93346002)(31966008)(20776003)(36756003)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB055; H:cio-krc-pf01.osuad.osu.edu; FPR:; MLV:sfv; PTR:cio-krc-pf01.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0354B4BED2 Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.208 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.208; helo=cio-krc-pf01.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.208) smtp.mailfrom=cantor.2@osu.edu; X-OriginatorOrg: osu.edu Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ndp-SiNuPm57DaCzSBG0MVDxi1w Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-saml-ec-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 00:02:02 -0000 On 10/3/14, 7:57 PM, "Nordgren, Bryce L -FS" wrote: >Seemed there was some good discussion in march, resulting mostly in the >need to clarify some aspects? > >=20 >Please don=B9t let it die. It's not dead, just resting. ;-) I've been tied up getting the next version of Shibboleth done this year (which does support the IdP half of this), I hope to complete the review around the holidays and get a new draft done then. -- Scott From nobody Sat Oct 11 04:31:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFCE1A0370 for ; Sat, 11 Oct 2014 04:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNUeqXIDFB3z for ; Sat, 11 Oct 2014 04:30:57 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216A51A035D for ; Sat, 11 Oct 2014 04:30:53 -0700 (PDT) Received: from [79.253.15.72] (helo=[192.168.71.80]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xcusq-0007d6-Po; Sat, 11 Oct 2014 13:30:49 +0200 Message-ID: <543914E8.8070507@lodderstedt.net> Date: Sat, 11 Oct 2014 13:30:48 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UQaEMenwAwBpOgM0SPqDhN9CzVo Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 11:31:01 -0000 Hi all, as one of the proposers (beside Hannes) of the change, I would like to explain the rationale. > -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text: > #1) I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations. Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540. Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed. In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: - multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. - Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user passwords on devices. So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security. Why does this require dynamic registration? Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front? I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall process. That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth. Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients. So I think true interoperability calls for addition of registration as well. Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments. > #2) I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible. Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with the OAuth WG) discuss, which elements are really needed. > #3) I am against recommending scope names at all in any way. I would not include the last sentence of paragraph 5 below and strike the scope names. Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully convinced whether this approach will work. But let's give it a try. kind regards, Torsten. > New text for 3.2.2: > ----------------------- > 3.2.2. Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication. The error > result consists of the following values: > > > status (REQUIRED): The authorization error code. Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL): An OAuth scope which is valid to access the > service. This may be empty which implies that unscoped tokens > are required, or a scope value. If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL): The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user. The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports. The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated. In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function. Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported. Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint. This specification > RECOMMMENDs the use of the following scopes: > > imap: The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3: The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill From nobody Sat Oct 11 12:30:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606AE1A875A for ; Sat, 11 Oct 2014 12:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksrj36LbQcFo for ; Sat, 11 Oct 2014 12:30:23 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C591A8765 for ; Sat, 11 Oct 2014 12:30:23 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9BJUJM8078896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Oct 2014 21:30:20 +0200 (CEST) (envelope-from rick@openfortress.nl) From: Rick van Rein Content-Type: multipart/signed; boundary="Apple-Mail=_7E122DAA-9F1B-40AE-9C68-B6C84A515C55"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Sat, 11 Oct 2014 21:30:16 +0200 To: "kitten@ietf.org" Message-Id: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ltA0FvRvMS-PMLon_cSqYb6WFwE Subject: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 19:30:25 -0000 --Apple-Mail=_7E122DAA-9F1B-40AE-9C68-B6C84A515C55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, I just posted a new I-D that introduces a DH subkey mechanism for = Kerberos. * This enables Forward Secrecy between principals, and breaks the KDC=92s= decryption ability. * An upcoming I-D will use Kerberos5 for mutual auth, and DH for = encryption, of TLS connection. * This work helps to reduce / bypass the need for replay caches. The I-D text on the IETF datatracker: = https://datatracker.ietf.org/doc/draft-vanrein-krb5-kdh/?include_text=3D1 Your expert feedback on this proposal is kindly appreciated. It is available for adoption by Kitten, if so desired. Cheers, Rick van Rein OpenFortress / InternetWide.org --Apple-Mail=_7E122DAA-9F1B-40AE-9C68-B6C84A515C55 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlQ5hUsACgkQFBGpwol1RgZPRgCgmwZIvsiD4WegvdemueSgn6Nz zHQAniZ+8mTd84co+ofhVG1AnbnrY1ar =YLHw -----END PGP SIGNATURE----- --Apple-Mail=_7E122DAA-9F1B-40AE-9C68-B6C84A515C55-- From nobody Sun Oct 12 17:55:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66211A7017; Sun, 12 Oct 2014 17:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6dhz53MVWVZ; Sun, 12 Oct 2014 17:37:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983031A6FAD; Sun, 12 Oct 2014 17:37:36 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9D0bY4X002970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Oct 2014 00:37:35 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9D0bXbF023761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2014 00:37:34 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9D0bXtm023746; Mon, 13 Oct 2014 00:37:33 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Oct 2014 17:37:33 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <54391575.9080707@lodderstedt.net> Date: Sun, 12 Oct 2014 17:37:31 -0700 Message-Id: <11F6D8A7-003C-45B7-8B2D-98D8CB0EA285@oracle.com> References: <543914E8.8070507@lodderstedt.net> <54391575.9080707@lodderstedt.net> To: Torsten Lodderstadt X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/E311IxhjPg8tH3Tu4MYjGMLljZY X-Mailman-Approved-At: Sun, 12 Oct 2014 17:55:17 -0700 Cc: kitten@ietf.org, "oauth@ietf.org WG" Subject: Re: [kitten] [OAUTH-WG] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 00:37:40 -0000 --Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Torsten, Big +1 to your comments. I think the SASL-OAuth work is very important work and it is the = *classic* use case for OAuth Dynamic Registration. SASL clients are typically developed independently of server = implementation and are meant to work with any server. This means that = having a pre-negotiated client_id is pretty much impossible without dyn = reg or some equivalent solution =97 and why do another? There may be simpler profiles you can develop specific to SASL, but I = think OAuth Dyn Reg should work well for this use case. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt = wrote: > Hi all, >=20 > there is some discussion going on in the KITTEN WG regarding the = SASL/Oauth mechanism that might be of interest for the OAuth WG as well. >=20 > kind regards, > Torsten. >=20 >=20 > -------- Original-Nachricht -------- > Betreff: Re: [kitten] I-D Action: = draft-ietf-kitten-sasl-oauth-16.txt > Datum: Sat, 11 Oct 2014 13:30:48 +0200 > Von: Torsten Lodderstedt > An: Kitten@ietf.org > Kopie (CC): tjs@psaux.com >=20 > Hi all, >=20 > as one of the proposers (beside Hannes) of the change, I would like to = explain the rationale. >=20 > > -16 is submitted, and there is one suggested change (which I was = supposed to have added in already and blew it), which is to replace = section 3.2.2 with the text (farther) below. My comments on the = suggested text: >=20 > > #1) I don't think the dynamic registration stuff is baked enough to = want to pull that in to the "oauth-configuration" definition. I don't = want to pull it in because I don't think dynamic registration is = required for SASL/OAUTH (as evidenced by the Google and Outlook.com = implementations. >=20 >=20 > Existing implementations at Google and Outlook.com are no evidence = against dynamic client registration. They demonstrate that it is = possible > to implement the server side. But we are talking about clients (more = precisely about generic clients). I'm not aware of any generic > client implementing the SASL mechanisms in the moment. I recommend = taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. >=20 > Before I dive into the registration details, I would like to give my = personal summary why this SASL profile is needed. > =20 > In my opinion, one of the main purposes of this mechanism is to allow = generic clients to authorize access to standard protocols, such as IMAP, > using OAuth Access Tokens. This offers the following advantages: >=20 > - multi-factor authn: An increasing number of service providers (e.g. = Google, Yahoo, Apple) offer 2-factor authentication to their users, > but only for apps and web sites. Why? It currently does not work in = conjunction with IMAP and the like. Instead, application-specific = passwords > must be used, which offer a terrible user experience and therefore are = a significant burden for better Internet security. Using OAuth access = tokens > allows to decouple service access and authentication/authorization = process. So the authorization server can choose the = appropriate/available > mechanisms to authenticate at its discretion. This also allows to use = any kind of (provider-specific) multi-factor authentication methods also > in the context of IMAP and the like. >=20 > - Furthermore, using OAuth also allows to use refresh tokens as = persistent credential for service login, that way eleminating the need = to store user > passwords on devices. > =20 > So basically, the SASL OAuth profile can (at least in my opinion) be a = major leap forward in Internet security. >=20 > Why does this require dynamic registration? >=20 > Well, OAuth requires any client to possess a client_id (and = client_secret) with the particular authorization server. Nowadays = developers typically > register with the authz server's provider out of band and bake the = credentials into the software package. This works for clients, which > are directly programmed against a certain deployment/API, such as = Facebook, but is inappropriate (if not unfeasible) for generic > clients using standardized protocols, e.g. Thunderbird. >=20 > Or do you want to register the Thunderbird deveopers with every = e-Mail/Calendar-provider in the world up-front? >=20 > I don't think so. That's why the OAuth WG came up with the = specification for dynamic client registration, which allows > the client to dynamically obtain client credentials from the = authorization server. It basically solves the client credential = challenge for generic > clients, but it does integrate the registration step into an overall = process. >=20 > That's why I think we must define a way for a generic SASL client to, = based on user-provided data, find the appropriate authorization server = and > register with it. I think the SASL mechanism should specify how those = mechanisms are used in concert in order to authorize service access = using OAuth. > Otherwise, the SASL mechanism can only be used for point to point = integrations among partners but never for generic clients. >=20 > So I think true interoperability calls for addition of registration as = well. >=20 > Regarding state of dynamic client registration: It's not ratified yet = but already sent to IESG for publication. > Beside that it is already implement in existing OpenId Connect = deployments. >=20 > > #2) I didn't really want to make all of the OpenID elements = required but I don't have a strong opinion here, my initial intent was = to use the OpenID Discovery format as an existing format to be re-used = here but leave it flexible. >=20 > Agreed. Using the format as specified by OpenID Connect makes sense. = As generic OAuth differs from OpenID Connect, the WG should (probably in = cooperation with > the OAuth WG) discuss, which elements are really needed. >=20 > > #3) I am against recommending scope names at all in any way. I = would not include the last sentence of paragraph 5 below and strike the = scope names. >=20 >=20 > Given there is already a response parameter scope, which intructs the = client on what scope to use in the authz request, I tend to agree. I'm = not yet fully > convinced whether this approach will work. But let's give it a try. >=20 > kind regards, > Torsten. >=20 >=20 >=20 > > New text for 3.2.2: > > ----------------------- > > 3.2.2. Server Response to Failed Authentication > > > > > > For a failed authentication the server returns a JSON [RFC4627] > > formatted error result, and fails the authentication. The error > > result consists of the following values: > > > > > > status (REQUIRED): The authorization error code. Valid error > > codes are defined in the IANA "OAuth Extensions Error Registry" > > specified in the OAuth 2 core specification. > > > > > > scope (OPTIONAL): An OAuth scope which is valid to access the > > service. This may be empty which implies that unscoped tokens > > are required, or a scope value. If a scope is specified then a > > single scope is preferred, use of a space separated list of > > scopes is NOT RECOMMENDED. > > > > > > oauth-configuration (OPTIONAL): The URL for a document following > > the OpenID Provider Configuration Information schema, as > > described in Section 3 of the OpenID Connect Discovery > > [OpenID.Discovery], that is appropriate for the user. The > > server MAY return different URLs for users from different > > domains and a client MUST NOT cache a single returned value and > > assume it applies for all users/domains that the server > > suports. The returned discovery document MUST have all data > > elements required by the OpenID Connect Discovery specification > > populated. In addition, the discovery document MUST contain > > the 'registration_endpoint' element to learn about the endpoint > > to be used with the Dynamic Client Registration protocol > > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > > parameters necessary for the OAuth protocol exchange to > > function. Authorization servers MUST implement the > > authorization code grant and other grant types MAY be > > supported. Furthermore, authorization servers MUST implement > > the ability to issue refresh tokens for use with native > > applications to benefit from an abbreviated protocol exchange. > > The use of the 'offline_access' scope, as defined in > > [OpenID.Core] is RECOMMENDED to give clients the capability to > > explicitly request a refresh token. > > > > > > If the resource server provides a scope (as part of the element of > > the configuration payload) then the client MUST always request > > scoped tokens from the token endpoint. This specification > > RECOMMMENDs the use of the following scopes: > > > > imap: The 'imap' scope value is used to interact with IMAP mail > > servers. > > > > pop3: The 'pop3' scope value is used to interact with POP3 mail > > servers. > > > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > > > > > If the resource server provides no scope to the client then the > > client SHOULD presume an empty scope (unscoped token) is needed. > > > > > > Since clients may interact with a number of application servers, > > such as email servers and XMPP servers, they need to have a way > > to determine whether dynamic client registration has been performed > > already and whether an already available refresh token can be > > re-used to obtain an access token for the desired resource server. > > This specification RECOMMENDs that a client uses the information in > > the 'issue' element to make this determination. > > ----------------------- > > > > > > I think we're getting very close :) > > > > -bill >=20 >=20 >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Torsten,

Big +1 to your = comments.

I think the SASL-OAuth work is very = important work and it is the *classic* use case for OAuth Dynamic = Registration.

SASL clients are typically = developed independently of server implementation and are meant to work = with any server.  This means that having a pre-negotiated client_id = is pretty much impossible without dyn reg or some equivalent solution =97 = and why do another?

There may be simpler = profiles you can develop specific to SASL, but I think OAuth Dyn Reg = should work well for this use case.

Phil

On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20
Hi all,

there is some discussion going on in the KITTEN WG regarding the SASL/Oauth mechanism that might be of interest for the OAuth WG as well.

kind regards,
Torsten.


-------- Original-Nachricht --------
Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
Datum: Sat, 11 Oct 2014 13:30:48 +0200
Von:= Torsten Lodderstedt <torsten@lodderstedt.net>
An: = Kitten@ietf.org
Kopie (CC): tjs@psaux.com <tjs@psaux.com> 


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to =
explain the rationale.

> -16 is submitted, and there is one suggested change (which I was =
supposed to have added in already and blew it), which is to replace =
section 3.2.2 with the text (farther) below. My comments on the =
suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough =
to want to pull that in to the "oauth-configuration" definition. I don't =
want to pull it in because I don't think dynamic registration is =
required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against =
dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more =
precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend =
taking a look at https://bug=
zilla.mozilla.org/show_bug.cgi?id=3D849540.

Before I dive into the registration details, I would like to give my =
personal summary why this SASL profile is needed.
=20
In my opinion, one of the main purposes of this mechanism is to allow =
generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. =
Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in =
conjunction with IMAP and the like. Instead, application-specific =
passwords
must be used, which offer a terrible user experience and therefore are a =
significant burden for better Internet security. Using OAuth access =
tokens
allows to decouple service access and authentication/authorization =
process. So the authorization server can choose the =
appropriate/available
mechanisms to authenticate at its discretion. This also allows to use =
any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as =
persistent credential for service login, that way eleminating the need =
to store user
passwords on devices.
=20
So basically, the SASL OAuth profile can (at least in my opinion) be a =
major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and =
client_secret) with the particular authorization server. Nowadays =
developers typically
register with the authz server's provider out of band and bake the =
credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as =
Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every =
e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification =
for dynamic client registration, which allows
the client to dynamically obtain client credentials from the =
authorization server. It basically solves the client credential =
challenge for generic
clients, but it does integrate the registration step into an overall =
process.

That's why I think we must define a way for a generic SASL client to, =
based on user-provided data, find the appropriate authorization server =
and
register with it. I think the SASL mechanism should specify how those =
mechanisms are used in concert in order to authorize service access =
using OAuth.
Otherwise, the SASL mechanism can only be used for point to point =
integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as =
well.

Regarding state of dynamic client registration: It's not ratified yet =
but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect =
deployments.

> #2)  I didn't really want to make all of the OpenID elements =
required but I don't have a strong opinion here, my initial intent was =
to use the OpenID Discovery format as an existing format to be re-used =
here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As =
generic OAuth differs from OpenID Connect, the WG should (probably in =
cooperation with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I =
would not include the last sentence of paragraph 5 below and strike the =
scope names.


Given there is already a response parameter scope, which intructs the =
client on what scope to use in the authz request, I tend to agree. I'm =
not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>   New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP =
servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill




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


_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA-- From nobody Mon Oct 13 09:09:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3101A033C for ; Mon, 13 Oct 2014 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrSi6j1vTAZQ for ; Mon, 13 Oct 2014 09:08:49 -0700 (PDT) Received: from nm47-vm1.bullet.mail.bf1.yahoo.com (nm47-vm1.bullet.mail.bf1.yahoo.com [216.109.115.124]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CF21A0346 for ; Mon, 13 Oct 2014 09:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413216528; bh=4uuUis+cUQXulwkzumY4SM0w5OKB7zniYeumyZevt9o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=IaktBI9/ZmyEufHuixzd7odrl/DXJ78cUB0pu5dCcQYmZwUNKWDWYJLZLxv7zdyukih0ciw9mhd0xW4n/1FHpCB+7SmztTcv5osZJkZiM9kHmNqZtWYxi6ti4RvMieV++5vyQNKCAl6XdM4CqAzvb03iYs3e6OI66RYaGAGufJ+50y+WSUDj9Af5qiqNmsJuTXBnNZ2gvKT0ozhwqc46+WFMZZvlnIh/TJ8th1lJM4sUMrxEDDL5RVxpGVLI6mpU0mEvO/OIfWqavkOAQusgbhlglhKvQteztO+7Lkg/BHEWXpqKAHaIrJL5oKxgCOgqulnos+aaLN9b1ZUwxwUN4g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=p/VcElWYKuyko02dPtTah4zUjQaabVhVM3W1sMAbeMHhI8vGOf+on9xOcXvyCz1pgZigRdjKn8KVuNoWg5ZTcwCBtoUy5soRN8v/8M13i/3chrRab6SpVDYo5dfXf+thcG/lXGZ6pO3gVEWvw5Q9V00u3CajCtT+UEq5Icrrb2f65fO/7dAvJR/FiQrFYLlzwOYnsz1KtczeinWLlPqsdQj1x55u5sE5x4WtqUoIcucLW3dK69CSFasxfXuJqEMiy4tbzG4YFXxulsCJlzJtwLF3G/8Aqs+Zi98kqHNSvv9fX3pKIkUOD1wkYoWIcfMft52mARnmrnsn7dKlwa65Hw==; Received: from [98.139.215.140] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 16:08:48 -0000 Received: from [98.139.212.230] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 16:08:48 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 16:08:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 228095.28428.bm@omp1039.mail.bf1.yahoo.com X-YMail-OSG: wlpbk5QVM1n_J74I8GvjvSMSZn90AooGre3w3wmIxnHQUhupKvLT50HyT5uGQ_5 hqsnTOS80iTiodBuRwJX5IC.Kk9iJsSCaij_l0effuN3Llh2R60UHCwiXP3h5QjvuAGVTyI8rAKt ZOhfgRYvKKQGfRx4qngdsBXLHCvBmwYkWf36I_RFmrSrLSzrdot4Vg76vpGkwBU9WvWzIRYDepNF o31mT07y8_qwhZ0Clv.Bo4p3QIAlZkuOgNd_15UTSXjtLynTKH6xFUEWgADrT_LvKjSS76quEGcx jNXkgSA2c2B7gQ6AZIuDFpP59TBDyeNYSHNNGdhLaqEWSVyZ4Ebh_BGNDMv4EhX4uTW4rE.Y.o6o N7rw2yCvvPMCmi_jLUQMYL2xObkjV_QbkcH9yNOs3n4639IqPWuZLrQoCWFRn6UmaIR2L53L1noR 1_8QHh3v7gOVl.96LnELvNW_W2xQMZ5Ym6mi4nI_2JxcTITWad9iu7Rs.WgupU_k_HeNBELUUoux k49nlOYzNXLuIXgknPvTHGmznqUd6GvX9odDpYYIqpfAPDzfSTCxU4sVE7Mp0RMmJfUVT3_Py0hz RZKzwGmvKj4HQYVd8GvFnv57X6wPhWnP69GJt9R.Ud6VunSSouqg5H4R78H8SkJIk Date: Mon, 13 Oct 2014 16:08:47 +0000 (UTC) From: Bill Mills To: Torsten Lodderstedt , "Kitten@ietf.org" Message-ID: <1602239841.299714.1413216527278.JavaMail.yahoo@jws10606.mail.bf1.yahoo.com> In-Reply-To: <543914E8.8070507@lodderstedt.net> References: <543914E8.8070507@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_299713_870851213.1413216527273" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/I6ytbtcbbbpP8A_kRC_5-Q-Ly9M Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:08:56 -0000 ------=_Part_299713_870851213.1413216527273 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I totally agree that generic and interoperable OAuth client implementations= need both endpoint discovery and client registration. =C2=A0I disagree tha= t this spec needs registration. =C2=A0This spec is about using OAuth on res= ource servers which have nothing to do with authentication and token issuan= ce. We might need to talk about client registration requirements in a token= profile, but this draft doesn't define new tokens either. On whether to specify the full OpenID Connect Discovery schema, I think a S= HOULD is reasonable, I don't really like the MUST.=20 On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt wrote: =20 Hi all, as one of the proposers (beside Hannes) of the change, I would like to expl= ain the rationale. > -16 is submitted, and there is one suggested change (which I was supposed= to have added in already and blew it), which is to replace section 3.2.2 w= ith the text (farther) below. My comments on the suggested text: > #1)=C2=A0 I don't think the dynamic registration stuff is baked enough to= want to pull that in to the "oauth-configuration" definition. I don't want= to pull it in because I don't think dynamic registration is required for S= ASL/OAUTH (as evidenced by the Google and Outlook.com implementations. Existing implementations at Google and Outlook.com are no evidence against = dynamic client registration. They demonstrate that it is possible to implement the server side. But we are talking about clients (more precis= ely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking a= look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. Before I dive into the registration details, I would like to give my person= al summary why this SASL profile is needed. =C2=A0=20 In my opinion, one of the main purposes of this mechanism is to allow gener= ic clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: - multi-factor authn: An increasing number of service providers (e.g. Googl= e, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjunc= tion with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a si= gnificant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process.= So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any k= ind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. - Furthermore, using OAuth also allows to use refresh tokens as persistent = credential for service login, that way eleminating the need to store user passwords on devices. =C2=A0=20 So basically, the SASL OAuth profile can (at least in my opinion) be a majo= r leap forward in Internet security. Why does this require dynamic registration? Well, OAuth requires any client to possess a client_id (and client_secret) = with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credenti= als into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook,= but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. Or do you want to register the Thunderbird deveopers with every e-Mail/Cale= ndar-provider in the world up-front? I don't think so. That's why the OAuth WG came up with the specification fo= r dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization = server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall proces= s. That's why I think we must define a way for a generic SASL client to, based= on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mecha= nisms are used in concert in order to authorize service access using OAuth. Otherwise, the SASL mechanism can only be used for point to point integrati= ons among partners but never for generic clients. So I think true interoperability calls for addition of registration as well= . Regarding state of dynamic client registration: It's not ratified yet but a= lready sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments. > #2)=C2=A0 I didn't really want to make all of the OpenID elements require= d but I don't have a strong opinion here, my initial intent was to use the = OpenID Discovery format as an existing format to be re-used here but leave = it flexible. Agreed. Using the format as specified by OpenID Connect makes sense. As gen= eric OAuth differs from OpenID Connect, the WG should (probably in cooperat= ion with the OAuth WG) discuss, which elements are really needed. > #3)=C2=A0 I am against recommending scope names at all in any way.=C2=A0 = I would not include the last sentence of paragraph 5 below and strike the s= cope names. Given there is already a response parameter scope, which intructs the clien= t on what scope to use in the authz request, I tend to agree. I'm not yet f= ully convinced whether this approach will work. But let's give it a try. kind regards, Torsten. >=C2=A0 New text for 3.2.2: > ----------------------- > 3.2.2.=C2=A0 Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication.=C2=A0 The error > result consists of the following values: > > > status (REQUIRED):=C2=A0 The authorization error code.=C2=A0 Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL):=C2=A0 An OAuth scope which is valid to access the > service.=C2=A0 This may be empty which implies that unscoped tokens > are required, or a scope value.=C2=A0 If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL):=C2=A0 The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user.=C2=A0 The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports.=C2=A0 The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated.=C2=A0 In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function.=C2=A0 Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported.=C2=A0 Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint.=C2=A0 This specification > RECOMMMENDs the use of the following scopes: > > imap:=C2=A0 The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3:=C2=A0 The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp:=C2=A0 The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill ------=_Part_299713_870851213.1413216527273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I totally agree that generic an= d interoperable OAuth client implementations need both endpoint discovery a= nd client registration.  I disagree that this spec needs registration.=  This spec is about using OAuth on resource servers which have nothin= g to do with authentication and token issuance. We might need to talk about= client registration requirements in a token profile, but this draft doesn'= t define new tokens either.

On whether to specify the full OpenID Connect = Discovery schema, I think a SHOULD is reasonable, I don't really like the M= UST.


On Saturday, October 11, 2014 4:30 AM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

as one of the proposers= (beside Hannes) of the change, I would like to explain the rationale.
<= br>> -16 is submitted, and there is one suggested change (which I was su= pposed to have added in already and blew it), which is to replace section 3= .2.2 with the text (farther) below. My comments on the suggested text:
<= br>> #1)  I don't think the dynamic registration stuff is baked eno= ugh to want to pull that in to the "oauth-configuration" definition. I don'= t want to pull it in because I don't think dynamic registration is required= for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations= .


Existing implementations at Google and Outlook.com are no evid= ence against dynamic client registration. They demonstrate that it is possi= ble
to implement the server side. But we are talking about clients (more= precisely about generic clients). I'm not aware of any generic
client i= mplementing the SASL mechanisms in the moment. I recommend taking a look at= https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540.

Before I div= e into the registration details, I would like to give my personal summary w= hy this SASL profile is needed.
 
In my opinion, one of the mai= n purposes of this mechanism is to allow generic clients to authorize acces= s to standard protocols, such as IMAP,
using OAuth Access Tokens. This o= ffers the following advantages:

- multi-factor authn: An increasing = number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor auth= entication to their users,
but only for apps and web sites. Why? It curr= ently does not work in conjunction with IMAP and the like. Instead, applica= tion-specific passwords
must be used, which offer a terrible user experi= ence and therefore are a significant burden for better Internet security. U= sing OAuth access tokens
allows to decouple service access and authentic= ation/authorization process. So the authorization server can choose the app= ropriate/available
mechanisms to authenticate at its discretion. This al= so allows to use any kind of (provider-specific) multi-factor authenticatio= n methods also
in the context of IMAP and the like.

- Furthermore= , using OAuth also allows to use refresh tokens as persistent credential fo= r service login, that way eleminating the need to store user
passwords o= n devices.
 
So basically, the SASL OAuth profile can (at least= in my opinion) be a major leap forward in Internet security.

Why do= es this require dynamic registration?

Well, OAuth requires any clien= t to possess a client_id (and client_secret) with the particular authorizat= ion server. Nowadays developers typically
register with the authz server= 's provider out of band and bake the credentials into the software package.= This works for clients, which
are directly programmed against a certain= deployment/API, such as Facebook, but is inappropriate (if not unfeasible)= for generic
clients using standardized protocols, e.g. Thunderbird.
=
Or do you want to register the Thunderbird deveopers with every e-Mail/= Calendar-provider in the world up-front?

I don't think so. That's wh= y the OAuth WG came up with the specification for dynamic client registrati= on, which allows
the client to dynamically obtain client credentials fro= m the authorization server. It basically solves the client credential chall= enge for generic
clients, but it does integrate the registration step in= to an overall process.

That's why I think we must define a way for a= generic SASL client to, based on user-provided data, find the appropriate = authorization server and
register with it. I think the SASL mechanism sh= ould specify how those mechanisms are used in concert in order to authorize= service access using OAuth.
Otherwise, the SASL mechanism can only be u= sed for point to point integrations among partners but never for generic cl= ients.

So I think true interoperability calls for addition of regist= ration as well.

Regarding state of dynamic client registration: It's= not ratified yet but already sent to IESG for publication.
Beside that = it is already implement in existing OpenId Connect deployments.

>= #2)  I didn't really want to make all of the OpenID elements required= but I don't have a strong opinion here, my initial intent was to use the O= penID Discovery format as an existing format to be re-used here but leave i= t flexible.

Agreed. Using the format as specified by OpenID Connect = makes sense. As generic OAuth differs from OpenID Connect, the WG should (p= robably in cooperation with
the OAuth WG) discuss, which elements are re= ally needed.

> #3)  I am against recommending scope names at= all in any way.  I would not include the last sentence of paragraph 5= below and strike the scope names.


Given there is already a resp= onse parameter scope, which intructs the client on what scope to use in the= authz request, I tend to agree. I'm not yet fully
convinced whether thi= s approach will work. But let's give it a try.

kind regards,
Tors= ten.



>  New text for 3.2.2:
> ---------------= --------
> 3.2.2.  Server Response to Failed Authentication
&= gt;
>
> For a failed authentication the server returns a JSON [= RFC4627]
> formatted error result, and fails the authentication. = ; The error
> result consists of the following values:
>
>= ;
> status (REQUIRED):  The authorization error code.  Vali= d error
> codes are defined in the IANA "OAuth Extensions Error Regis= try"
> specified in the OAuth 2 core specification.
>
>> scope (OPTIONAL):  An OAuth scope which is valid to access the<= br>> service.  This may be empty which implies that unscoped tokens=
> are required, or a scope value.  If a scope is specified then= a
> single scope is preferred, use of a space separated list of
&= gt; scopes is NOT RECOMMENDED.
>
>
> oauth-configuration = (OPTIONAL):  The URL for a document following
> the OpenID Provi= der Configuration Information schema, as
> described in Section 3 of = the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriat= e for the user.  The
> server MAY return different URLs for user= s from different
> domains and a client MUST NOT cache a single retur= ned value and
> assume it applies for all users/domains that the serv= er
> suports.  The returned discovery document MUST have all dat= a
> elements required by the OpenID Connect Discovery specification> populated.  In addition, the discovery document MUST contain> the 'registration_endpoint' element to learn about the endpoint
&g= t; to be used with the Dynamic Client Registration protocol
> [I-D.ie= tf-oauth-dyn-reg] to obtain the minimum number of
> parameters necess= ary for the OAuth protocol exchange to
> function.  Authorizatio= n servers MUST implement the
> authorization code grant and other gra= nt types MAY be
> supported.  Furthermore, authorization servers= MUST implement
> the ability to issue refresh tokens for use with na= tive
> applications to benefit from an abbreviated protocol exchange.=
> The use of the 'offline_access' scope, as defined in
> [Open= ID.Core] is RECOMMENDED to give clients the capability to
> explicitl= y request a refresh token.
>
>
> If the resource server p= rovides a scope (as part of the element of
> the configuration payloa= d) then the client MUST always request
> scoped tokens from the token= endpoint.  This specification
> RECOMMMENDs the use of the foll= owing scopes:
>
> imap:  The 'imap' scope value is used to= interact with IMAP mail
> servers.
>
> pop3:  The '= pop3' scope value is used to interact with POP3 mail
> servers.
&g= t;
> xmpp:  The 'xmpp' scope value is used to interact with XMPP= servers.
>
>
>
> If the resource server provides n= o scope to the client then the
> client SHOULD presume an empty scope= (unscoped token) is needed.
>
>
> Since clients may inte= ract with a number of application servers,
> such as email servers an= d XMPP servers, they need to have a way
> to determine whether dynami= c client registration has been performed
> already and whether an alr= eady available refresh token can be
> re-used to obtain an access tok= en for the desired resource server.
> This specification RECOMMENDs t= hat a client uses the information in
> the 'issue' element to make th= is determination.
> -----------------------
>
>
> I= think we're getting very close :)
>
> -bill





------=_Part_299713_870851213.1413216527273-- From nobody Mon Oct 13 13:48:15 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3D31A0081 for ; Mon, 13 Oct 2014 13:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUROlKq8Z8EV for ; Mon, 13 Oct 2014 13:48:08 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A5B1A004B for ; Mon, 13 Oct 2014 13:48:07 -0700 (PDT) Received: from [79.253.15.72] (helo=[192.168.71.80]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XdmXE-0000Up-IR; Mon, 13 Oct 2014 22:48:04 +0200 Message-ID: <543C3A85.4080504@lodderstedt.net> Date: Mon, 13 Oct 2014 22:48:05 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bill Mills , "Kitten@ietf.org" References: <543914E8.8070507@lodderstedt.net> <1602239841.299714.1413216527278.JavaMail.yahoo@jws10606.mail.bf1.yahoo.com> In-Reply-To: <1602239841.299714.1413216527278.JavaMail.yahoo@jws10606.mail.bf1.yahoo.com> Content-Type: multipart/alternative; boundary="------------000102030209020102050807" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3y0-DilLafz5GGvf9GeIT6bCvq0 Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:48:13 -0000 This is a multi-part message in MIME format. --------------000102030209020102050807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Bill, Am 13.10.2014 18:08, schrieb Bill Mills: > I totally agree that generic and interoperable OAuth client > implementations need both endpoint discovery and client registration. > I disagree that this spec needs registration. > This spec is about using OAuth on resource servers which have nothing > to do with authentication and token issuance. I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach? I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth. Such a generic client must (at most) perform the following steps in order to get access to the resource server: 1) client tries to access resource server 2) resource server refuses access and returns discovery URL 3) client obtains metadata from discovery URL 4) client determines its client credentials for this particular authz server 5) if client is not in possession of suitable client credentials -> register with the authz server (at the registration endpoint obtained from the discovery document) 6) client performs authz flow with the authz server 7) client accesses resource server again (with new access token) This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process. Do you have an alternative proposal to achieve this goal? > We might need to talk about client registration requirements in a > token profile, but this draft doesn't define new tokens either. There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments). kind regards, Torsten. > > On whether to specify the full OpenID Connect Discovery schema, I > think a SHOULD is reasonable, I don't really like the MUST. > > > On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt > wrote: > > > Hi all, > > as one of the proposers (beside Hannes) of the change, I would like to > explain the rationale. > > > -16 is submitted, and there is one suggested change (which I was > supposed to have added in already and blew it), which is to replace > section 3.2.2 with the text (farther) below. My comments on the > suggested text: > > > #1) I don't think the dynamic registration stuff is baked enough to > want to pull that in to the "oauth-configuration" definition. I don't > want to pull it in because I don't think dynamic registration is > required for SASL/OAUTH (as evidenced by the Google and Outlook.com > implementations. > > > Existing implementations at Google and Outlook.com are no evidence > against dynamic client registration. They demonstrate that it is possible > to implement the server side. But we are talking about clients (more > precisely about generic clients). I'm not aware of any generic > client implementing the SASL mechanisms in the moment. I recommend > taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540. > > Before I dive into the registration details, I would like to give my > personal summary why this SASL profile is needed. > > In my opinion, one of the main purposes of this mechanism is to allow > generic clients to authorize access to standard protocols, such as IMAP, > using OAuth Access Tokens. This offers the following advantages: > > - multi-factor authn: An increasing number of service providers (e.g. > Google, Yahoo, Apple) offer 2-factor authentication to their users, > but only for apps and web sites. Why? It currently does not work in > conjunction with IMAP and the like. Instead, application-specific > passwords > must be used, which offer a terrible user experience and therefore are > a significant burden for better Internet security. Using OAuth access > tokens > allows to decouple service access and authentication/authorization > process. So the authorization server can choose the appropriate/available > mechanisms to authenticate at its discretion. This also allows to use > any kind of (provider-specific) multi-factor authentication methods also > in the context of IMAP and the like. > > - Furthermore, using OAuth also allows to use refresh tokens as > persistent credential for service login, that way eleminating the need > to store user > passwords on devices. > > So basically, the SASL OAuth profile can (at least in my opinion) be a > major leap forward in Internet security. > > Why does this require dynamic registration? > > Well, OAuth requires any client to possess a client_id (and > client_secret) with the particular authorization server. Nowadays > developers typically > register with the authz server's provider out of band and bake the > credentials into the software package. This works for clients, which > are directly programmed against a certain deployment/API, such as > Facebook, but is inappropriate (if not unfeasible) for generic > clients using standardized protocols, e.g. Thunderbird. > > Or do you want to register the Thunderbird deveopers with every > e-Mail/Calendar-provider in the world up-front? > > I don't think so. That's why the OAuth WG came up with the > specification for dynamic client registration, which allows > the client to dynamically obtain client credentials from the > authorization server. It basically solves the client credential > challenge for generic > clients, but it does integrate the registration step into an overall > process. > > That's why I think we must define a way for a generic SASL client to, > based on user-provided data, find the appropriate authorization server and > register with it. I think the SASL mechanism should specify how those > mechanisms are used in concert in order to authorize service access > using OAuth. > Otherwise, the SASL mechanism can only be used for point to point > integrations among partners but never for generic clients. > > So I think true interoperability calls for addition of registration as > well. > > Regarding state of dynamic client registration: It's not ratified yet > but already sent to IESG for publication. > Beside that it is already implement in existing OpenId Connect > deployments. > > > #2) I didn't really want to make all of the OpenID elements > required but I don't have a strong opinion here, my initial intent was > to use the OpenID Discovery format as an existing format to be re-used > here but leave it flexible. > > Agreed. Using the format as specified by OpenID Connect makes sense. > As generic OAuth differs from OpenID Connect, the WG should (probably > in cooperation with > the OAuth WG) discuss, which elements are really needed. > > > #3) I am against recommending scope names at all in any way. I > would not include the last sentence of paragraph 5 below and strike > the scope names. > > > Given there is already a response parameter scope, which intructs the > client on what scope to use in the authz request, I tend to agree. I'm > not yet fully > convinced whether this approach will work. But let's give it a try. > > kind regards, > Torsten. > > > > > New text for 3.2.2: > > ----------------------- > > 3.2.2. Server Response to Failed Authentication > > > > > > For a failed authentication the server returns a JSON [RFC4627] > > formatted error result, and fails the authentication. The error > > result consists of the following values: > > > > > > status (REQUIRED): The authorization error code. Valid error > > codes are defined in the IANA "OAuth Extensions Error Registry" > > specified in the OAuth 2 core specification. > > > > > > scope (OPTIONAL): An OAuth scope which is valid to access the > > service. This may be empty which implies that unscoped tokens > > are required, or a scope value. If a scope is specified then a > > single scope is preferred, use of a space separated list of > > scopes is NOT RECOMMENDED. > > > > > > oauth-configuration (OPTIONAL): The URL for a document following > > the OpenID Provider Configuration Information schema, as > > described in Section 3 of the OpenID Connect Discovery > > [OpenID.Discovery], that is appropriate for the user. The > > server MAY return different URLs for users from different > > domains and a client MUST NOT cache a single returned value and > > assume it applies for all users/domains that the server > > suports. The returned discovery document MUST have all data > > elements required by the OpenID Connect Discovery specification > > populated. In addition, the discovery document MUST contain > > the 'registration_endpoint' element to learn about the endpoint > > to be used with the Dynamic Client Registration protocol > > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > > parameters necessary for the OAuth protocol exchange to > > function. Authorization servers MUST implement the > > authorization code grant and other grant types MAY be > > supported. Furthermore, authorization servers MUST implement > > the ability to issue refresh tokens for use with native > > applications to benefit from an abbreviated protocol exchange. > > The use of the 'offline_access' scope, as defined in > > [OpenID.Core] is RECOMMENDED to give clients the capability to > > explicitly request a refresh token. > > > > > > If the resource server provides a scope (as part of the element of > > the configuration payload) then the client MUST always request > > scoped tokens from the token endpoint. This specification > > RECOMMMENDs the use of the following scopes: > > > > imap: The 'imap' scope value is used to interact with IMAP mail > > servers. > > > > pop3: The 'pop3' scope value is used to interact with POP3 mail > > servers. > > > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > > > > > If the resource server provides no scope to the client then the > > client SHOULD presume an empty scope (unscoped token) is needed. > > > > > > Since clients may interact with a number of application servers, > > such as email servers and XMPP servers, they need to have a way > > to determine whether dynamic client registration has been performed > > already and whether an already available refresh token can be > > re-used to obtain an access token for the desired resource server. > > This specification RECOMMENDs that a client uses the information in > > the 'issue' element to make this determination. > > ----------------------- > > > > > > I think we're getting very close :) > > > > -bill > > > > > > --------------000102030209020102050807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Bill,

Am 13.10.2014 18:08, schrieb Bill Mills:
I totally agree that generic and interoperable OAuth client implementations need both endpoint discovery and client registration.  I disagree that this spec needs registration. 
This spec is about using OAuth on resource servers which have nothing to do with authentication and token issuance.

I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach?

I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth.
Such a generic client must (at most) perform the following steps in order to get access to the resource server:

1) client tries to access resource server
2) resource server refuses access and returns discovery URL
3) client obtains metadata from discovery URL
4) client determines its client credentials for this particular authz server
5) if client is not in possession of suitable client credentials ->  register with the authz server (at the registration endpoint obtained from the discovery document)
6) client performs authz flow with the authz server
7) client accesses resource server again (with new access token)

This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process.

Do you have an alternative proposal to achieve this goal?

We might need to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.

There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments).

kind regards,
Torsten.


On whether to specify the full OpenID Connect Discovery schema, I think a SHOULD is reasonable, I don't really like the MUST.


On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to explain the rationale.

> -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540.

Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
 
In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user
passwords on devices.
 
So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall process.

That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well.

Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect deployments.

> #2)  I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.


Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>  New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill







--------------000102030209020102050807-- From nobody Mon Oct 13 14:05:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2871A0041 for ; Mon, 13 Oct 2014 14:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_d9DhBCkIJP for ; Mon, 13 Oct 2014 14:05:17 -0700 (PDT) Received: from nm38-vm0.bullet.mail.bf1.yahoo.com (nm38-vm0.bullet.mail.bf1.yahoo.com [72.30.239.16]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CAF1A003B for ; Mon, 13 Oct 2014 14:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413234316; bh=/2uPl7ArvXTg73cKnJ8oj+Dr7Vs+nMmgqSPFgaMqg5Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=iv1WAATogoUyFkt9dVSDMVGgAxBYCQkUuEqCZv1JjuC5l+H+0n/oQvVQoWXAV6v/1X7p7APW1rE5UdYbehThPngTWXDrvbFik6iBqGj5Qadwd2VFKrv9UMg7sDFIjQIU3juWqYPzXdHGL0p180oXlb2DYW+LcoeV165UzCf+DREx/I6ZeqIEvJjLQwn1jqn0VB7zRzHHNlhaqBXu/29gU5LAyRYS9KeZqdjuLAe4LkSKCFmO0Rv6jFj6NolwoGI/5zaJith/9ck1aixFPiqLFGwMdMI27UTRpaDJBW/hJDhYG1lb05h4EuAt4wd5ut8NhSA1W83prAuBv7vW6r5rww== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=o5KOudGuIZtJrKjsb/4Ns58Tt3B5Y9+ytAl6vqmDwRh0fPthUVdO3f76wsKfsf8Y1d/aigzf9O37upKWQCtUMDWUv1dJkqaBJhhR1nUIjG+sTLbb8H5Pf8eTQ1LqysJvWZJUJF8pyZwnwXxyr6vyhMfsCNX7tgo+bc/0HGbNLNNmyziQqNVmAYgk7np0WNnPbTqX3CIZs0Zn2Y/XthgWYIMlSC9Wjv90q6sbOeTd1Z0dfobeRmHy1BYJkpEYEvnrqHtRODAX9KLl3d9xjLV8ayEcVlUu5lh6JnaX0CHafy+H1mTBpMv3pk97svfEhI/PG8G/S16lwvAGGqqJHV3vIg==; Received: from [98.139.215.142] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 21:05:16 -0000 Received: from [98.139.215.251] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 21:05:15 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 13 Oct 2014 21:05:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 168045.67963.bm@omp1064.mail.bf1.yahoo.com Date: Mon, 13 Oct 2014 21:05:14 +0000 (UTC) From: Bill Mills To: Torsten Lodderstedt , "Kitten@ietf.org" Message-ID: <2083170889.328105.1413234314028.JavaMail.yahoo@jws10608.mail.bf1.yahoo.com> In-Reply-To: <543C3A85.4080504@lodderstedt.net> References: <543C3A85.4080504@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_328104_400777075.1413234314019" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rFDYArO8xDv3fykkWOyqHjgxTOs Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:05:21 -0000 ------=_Part_328104_400777075.1413234314019 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 3 through 6 should be handled by OAuth (and OpenID?) and are outside the sc= ope of this spec. =C2=A0This spec deals with 1 and maybe 2 & 7 above). =C2= =A0 A generic mail/contacts/calendar client will used more than SASL endpoints,= notably CalDAV and CardDAV. =C2=A0This isn't the place to solve the genera= l problem. =C2=A0=C2=A0 -bill =20 On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt wrote: =20 Hi Bill, =20 Am 13.10.2014 18:08, schrieb Bill Mills: =20 I totally agree that generic and interoperable OAuth client implementatio= ns need both endpoint discovery and client registration. =C2=A0I disagree t= hat this spec needs registration.=C2=A0=20 =20 =20 This spec is about using OAuth on resource servers which have nothing to do= with authentication and token issuance.=20 =20 I agree these are different aspects. Does this mean they need to be treate= d in different specs? What is the benefit of this approach?=20 =20 I'm not looking for a generic OAuth client. My goal is to enable the devel= opment of generic email/calendar/xmpp ... clients, which authorize access t= o the respective service using OAuth. Such a generic client must (at most) perform the following steps in order = to get access to the resource server: =20 1) client tries to access resource server 2) resource server refuses access and returns discovery URL 3) client obtains metadata from discovery URL 4) client determines its client credentials for this particular authz serv= er 5) if client is not in possession of suitable client credentials ->=C2=A0 = register with the authz server (at the registration endpoint obtained from = the discovery document) 6) client performs authz flow with the authz server 7) client accesses resource server again (with new access token)=20 =20 This spec currently does not specify steps 4 through 6, which means there = is no way to implement the whole process in an interoperable way in my gene= ric email client. I therefore suggest to add registration to this spec in o= rder to cover the entire process.=20 =20 Do you have an alternative proposal to achieve this goal?=20 =20 =20 We might need to talk about client registration requirements in a token p= rofile, but this draft doesn't define new tokens either. =20 =20 There is no need to define new tokens as this is not relevant for client/r= esource server interop. Resource server know the authz server's token forma= t (which is standard in OAuth deployments).=20 =20 kind regards, Torsten. =20 =20 =20 On whether to specify the full OpenID Connect Discovery schema, I think a= SHOULD is reasonable, I don't really like the MUST.=20 =20 On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt wrote: =20 =20 Hi all, =20 as one of the proposers (beside Hannes) of the change, I would like to exp= lain the rationale. =20 > -16 is submitted, and there is one suggested change (which I was suppose= d to have added in already and blew it), which is to replace section 3.2.2 = with the text (farther) below. My comments on the suggested text: =20 > #1)=C2=A0 I don't think the dynamic registration stuff is baked enough t= o want to pull that in to the "oauth-configuration" definition. I don't wan= t to pull it in because I don't think dynamic registration is required for = SASL/OAUTH (as evidenced by the Google and Outlook.com implementations. =20 =20 Existing implementations at Google and Outlook.com are no evidence against= dynamic client registration. They demonstrate that it is possible to implement the server side. But we are talking about clients (more preci= sely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking = a look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. =20 Before I dive into the registration details, I would like to give my perso= nal summary why this SASL profile is needed. =C2=A0=20 In my opinion, one of the main purposes of this mechanism is to allow gene= ric clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: =20 - multi-factor authn: An increasing number of service providers (e.g. Goog= le, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjun= ction with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a s= ignificant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process= . So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any = kind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. =20 - Furthermore, using OAuth also allows to use refresh tokens as persistent= credential for service login, that way eleminating the need to store user passwords on devices. =C2=A0=20 So basically, the SASL OAuth profile can (at least in my opinion) be a maj= or leap forward in Internet security. =20 Why does this require dynamic registration? =20 Well, OAuth requires any client to possess a client_id (and client_secret)= with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credent= ials into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook= , but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. =20 Or do you want to register the Thunderbird deveopers with every e-Mail/Cal= endar-provider in the world up-front? =20 I don't think so. That's why the OAuth WG came up with the specification f= or dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization= server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall proce= ss. =20 That's why I think we must define a way for a generic SASL client to, base= d on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mech= anisms are used in concert in order to authorize service access using OAuth= . Otherwise, the SASL mechanism can only be used for point to point integrat= ions among partners but never for generic clients. =20 So I think true interoperability calls for addition of registration as wel= l. =20 Regarding state of dynamic client registration: It's not ratified yet but = already sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments= . =20 > #2)=C2=A0 I didn't really want to make all of the OpenID elements requir= ed but I don't have a strong opinion here, my initial intent was to use the= OpenID Discovery format as an existing format to be re-used here but leave= it flexible. =20 Agreed. Using the format as specified by OpenID Connect makes sense. As ge= neric OAuth differs from OpenID Connect, the WG should (probably in coopera= tion with the OAuth WG) discuss, which elements are really needed. =20 > #3)=C2=A0 I am against recommending scope names at all in any way.=C2=A0= I would not include the last sentence of paragraph 5 below and strike the = scope names. =20 =20 Given there is already a response parameter scope, which intructs the clie= nt on what scope to use in the authz request, I tend to agree. I'm not yet = fully convinced whether this approach will work. But let's give it a try. =20 kind regards, Torsten. =20 =20 =20 >=C2=A0 New text for 3.2.2: > ----------------------- > 3.2.2.=C2=A0 Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication.=C2=A0 The error > result consists of the following values: > > > status (REQUIRED):=C2=A0 The authorization error code.=C2=A0 Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL):=C2=A0 An OAuth scope which is valid to access the > service.=C2=A0 This may be empty which implies that unscoped tokens > are required, or a scope value.=C2=A0 If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL):=C2=A0 The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user.=C2=A0 The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports.=C2=A0 The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated.=C2=A0 In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function.=C2=A0 Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported.=C2=A0 Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint.=C2=A0 This specification > RECOMMMENDs the use of the following scopes: > > imap:=C2=A0 The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3:=C2=A0 The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp:=C2=A0 The 'xmpp' scope value is used to interact with XMPP servers= . > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_Part_328104_400777075.1413234314019 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
3 through 6 should be handled by= OAuth (and OpenID?) and are outside the scope of this spec.  <= span style=3D"font-size: 15.5555562973022px;" class=3D"">This spec deals wi= th 1 and maybe 2 & 7 above).  

<= /span>
A generic mail/contacts/calen= dar client will used more than SASL endpoints, notably CalDAV and CardDAV. =  This isn't the place to solve the general problem.   

-bill


On Monday, Octo= ber 13, 2014 1:48 PM, Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:


Hi Bill,

Am 13.10.2014 18:08, schrie= b Bill Mills:
I totally a= gree that generic and interoperable OAuth client implementations need both endpoint discovery and client registration.  I disagr= ee that this spec needs registration. 
This spec is about using OAuth on resource servers which have nothing to do with authentication and token issuance.

I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach?

I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth.
Such a generic client must (at most) perform the following steps in order to get access to the resource server:

1) client tries to access resource server
2) resource server refuses access and returns discovery URL
3) client obtains metadata from discovery URL
4) client determines its client credentials for this particular authz server
5) if client is not in possession of suitable client credentials ->  register with the authz server (at the registration endpoin= t obtained from the discovery document)
6) client performs authz flow with the authz server
7) client accesses resource server again (with new access token)

This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process.

Do you have an alternative proposal to achieve this goal?

We might ne= ed to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.

There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments).

kind regards,
Torsten.



On whether to specify the full OpenID Connect Discovery schema, I think a SHOULD is reasonable, I don't really like the MUST.


On Saturda= y, October 11, 2014 4:30 AM, Torsten Lodderstedt <torsten@lodderstedt.ne= t> wrote:


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to explain the rationale.

> -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D8= 49540.

Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
 
In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user
passwords on devices.
 
So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall process.

That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well.

Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect deployments.

> #2)  I didn't really want to make all of the Open= ID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
the OAuth WG) discuss, which elements are really needed.
> #3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.


Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>  New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication<= br clear=3D"none"> >
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.=   Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid = to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST ha= ve all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement t= he
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MU= ST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill









------=_Part_328104_400777075.1413234314019-- From nobody Mon Oct 13 23:03:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812D51A6F9F for ; Mon, 13 Oct 2014 23:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIx_6-Vqbd8Q for ; Mon, 13 Oct 2014 23:03:15 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DDB1A6F98 for ; Mon, 13 Oct 2014 23:03:13 -0700 (PDT) Received: from [79.253.15.72] (helo=[192.168.71.100]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XdvCM-0007fY-Om; Tue, 14 Oct 2014 08:03:07 +0200 Date: Tue, 14 Oct 2014 08:03:02 +0200 Message-ID: <31r908v52l19r5cb7nsqiouy.1413266582842@email.android.com> Importance: normal From: Torsten Lodderstedt To: Bill Mills , "Kitten@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1347985349412330" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/AZwjjUMGFXpU9MLx-MOJ6nla5aM Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 06:03:21 -0000 ----_com.android.email_1347985349412330 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgQmlsbCwKCmFyZSB5b3UgcHJvcG9zaW5nIHRvIHdyaXRlIGEgbmV3ICJnZW5lcmljIGNsaWVu dCIgSS1EL1JGQyBpbiB0aGUgT0F1dGggV0c/CgpraW5kIHJlZ2FyZHMswqAKVG9yc3Rlbi7CoAoK PGRpdj4tLS0tLS0tLSBVcnNwcsO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS08L2Rpdj48ZGl2 PlZvbjogQmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gPC9kaXY+PGRpdj5EYXR1 bToxMy4xMC4yMDE0ICAyMzowNSAgKEdNVCswMTowMCkgPC9kaXY+PGRpdj5BbjogVG9yc3RlbiBM b2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+LCBLaXR0ZW5AaWV0Zi5vcmcgPC9k aXY+PGRpdj5DYzogdGpzQHBzYXV4LmNvbSwgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2No b2ZlbmlnQGdteC5uZXQ+LCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4gPC9kaXY+PGRp dj5CZXRyZWZmOiBSZTogW2tpdHRlbl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1raXR0ZW4tc2Fz bC1vYXV0aC0xNi50eHQgPC9kaXY+PGRpdj4KPC9kaXY+MyB0aHJvdWdoIDYgc2hvdWxkIGJlIGhh bmRsZWQgYnkgT0F1dGggKGFuZCBPcGVuSUQ/KSBhbmQgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgc3BlYy4gIFRoaXMgc3BlYyBkZWFscyB3aXRoIDEgYW5kIG1heWJlIDIgJiA3IGFib3Zl KS4gIAoKQSBnZW5lcmljIG1haWwvY29udGFjdHMvY2FsZW5kYXIgY2xpZW50IHdpbGwgdXNlZCBt b3JlIHRoYW4gU0FTTCBlbmRwb2ludHMsIG5vdGFibHkgQ2FsREFWIGFuZCBDYXJkREFWLiAgVGhp cyBpc24ndCB0aGUgcGxhY2UgdG8gc29sdmUgdGhlIGdlbmVyYWwgcHJvYmxlbS4gICAKCi1iaWxs CgoKCk9uIE1vbmRheSwgT2N0b2JlciAxMywgMjAxNCAxOjQ4IFBNLCBUb3JzdGVuIExvZGRlcnN0 ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6CgoKSGkgQmlsbCwKCkFtIDEzLjEw LjIwMTQgMTg6MDgsIHNjaHJpZWIgQmlsbCBNaWxsczoKSSB0b3RhbGx5IGFncmVlIHRoYXQgZ2Vu ZXJpYyBhbmQgaW50ZXJvcGVyYWJsZSBPQXV0aCBjbGllbnQgaW1wbGVtZW50YXRpb25zIG5lZWQg Ym90aCBlbmRwb2ludCBkaXNjb3ZlcnkgYW5kIGNsaWVudCByZWdpc3RyYXRpb24uICBJIGRpc2Fn cmVlIHRoYXQgdGhpcyBzcGVjIG5lZWRzIHJlZ2lzdHJhdGlvbi4gIApUaGlzIHNwZWMgaXMgYWJv dXQgdXNpbmcgT0F1dGggb24gcmVzb3VyY2Ugc2VydmVycyB3aGljaCBoYXZlIG5vdGhpbmcgdG8g ZG8gd2l0aCBhdXRoZW50aWNhdGlvbiBhbmQgdG9rZW4gaXNzdWFuY2UuCgpJIGFncmVlIHRoZXNl IGFyZSBkaWZmZXJlbnQgYXNwZWN0cy4gRG9lcyB0aGlzIG1lYW4gdGhleSBuZWVkIHRvIGJlIHRy ZWF0ZWQgaW4gZGlmZmVyZW50IHNwZWNzPyBXaGF0IGlzIHRoZSBiZW5lZml0IG9mIHRoaXMgYXBw cm9hY2g/IAoKSSdtIG5vdCBsb29raW5nIGZvciBhIGdlbmVyaWMgT0F1dGggY2xpZW50LiBNeSBn b2FsIGlzIHRvIGVuYWJsZSB0aGUgZGV2ZWxvcG1lbnQgb2YgZ2VuZXJpYyBlbWFpbC9jYWxlbmRh ci94bXBwIC4uLiBjbGllbnRzLCB3aGljaCBhdXRob3JpemUgYWNjZXNzIHRvIHRoZSByZXNwZWN0 aXZlIHNlcnZpY2UgdXNpbmcgT0F1dGguClN1Y2ggYSBnZW5lcmljIGNsaWVudCBtdXN0IChhdCBt b3N0KSBwZXJmb3JtIHRoZSBmb2xsb3dpbmcgc3RlcHMgaW4gb3JkZXIgdG8gZ2V0IGFjY2VzcyB0 byB0aGUgcmVzb3VyY2Ugc2VydmVyOgoKMSkgY2xpZW50IHRyaWVzIHRvIGFjY2VzcyByZXNvdXJj ZSBzZXJ2ZXIKMikgcmVzb3VyY2Ugc2VydmVyIHJlZnVzZXMgYWNjZXNzIGFuZCByZXR1cm5zIGRp c2NvdmVyeSBVUkwKMykgY2xpZW50IG9idGFpbnMgbWV0YWRhdGEgZnJvbSBkaXNjb3ZlcnkgVVJM CjQpIGNsaWVudCBkZXRlcm1pbmVzIGl0cyBjbGllbnQgY3JlZGVudGlhbHMgZm9yIHRoaXMgcGFy dGljdWxhciBhdXRoeiBzZXJ2ZXIKNSkgaWYgY2xpZW50IGlzIG5vdCBpbiBwb3NzZXNzaW9uIG9m IHN1aXRhYmxlIGNsaWVudCBjcmVkZW50aWFscyAtPiAgcmVnaXN0ZXIgd2l0aCB0aGUgYXV0aHog c2VydmVyIChhdCB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IG9idGFpbmVkIGZyb20gdGhlIGRp c2NvdmVyeSBkb2N1bWVudCkKNikgY2xpZW50IHBlcmZvcm1zIGF1dGh6IGZsb3cgd2l0aCB0aGUg YXV0aHogc2VydmVyCjcpIGNsaWVudCBhY2Nlc3NlcyByZXNvdXJjZSBzZXJ2ZXIgYWdhaW4gKHdp dGggbmV3IGFjY2VzcyB0b2tlbikgCgpUaGlzIHNwZWMgY3VycmVudGx5IGRvZXMgbm90IHNwZWNp Znkgc3RlcHMgNCB0aHJvdWdoIDYsIHdoaWNoIG1lYW5zIHRoZXJlIGlzIG5vIHdheSB0byBpbXBs ZW1lbnQgdGhlIHdob2xlIHByb2Nlc3MgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkgaW4gbXkgZ2Vu ZXJpYyBlbWFpbCBjbGllbnQuIEkgdGhlcmVmb3JlIHN1Z2dlc3QgdG8gYWRkIHJlZ2lzdHJhdGlv biB0byB0aGlzIHNwZWMgaW4gb3JkZXIgdG8gY292ZXIgdGhlIGVudGlyZSBwcm9jZXNzLiAKCkRv IHlvdSBoYXZlIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIHRvIGFjaGlldmUgdGhpcyBnb2FsPyAK CldlIG1pZ2h0IG5lZWQgdG8gdGFsayBhYm91dCBjbGllbnQgcmVnaXN0cmF0aW9uIHJlcXVpcmVt ZW50cyBpbiBhIHRva2VuIHByb2ZpbGUsIGJ1dCB0aGlzIGRyYWZ0IGRvZXNuJ3QgZGVmaW5lIG5l dyB0b2tlbnMgZWl0aGVyLgoKVGhlcmUgaXMgbm8gbmVlZCB0byBkZWZpbmUgbmV3IHRva2VucyBh cyB0aGlzIGlzIG5vdCByZWxldmFudCBmb3IgY2xpZW50L3Jlc291cmNlIHNlcnZlciBpbnRlcm9w LiBSZXNvdXJjZSBzZXJ2ZXIga25vdyB0aGUgYXV0aHogc2VydmVyJ3MgdG9rZW4gZm9ybWF0ICh3 aGljaCBpcyBzdGFuZGFyZCBpbiBPQXV0aCBkZXBsb3ltZW50cykuIAoKa2luZCByZWdhcmRzLApU b3JzdGVuLgoKCgpPbiB3aGV0aGVyIHRvIHNwZWNpZnkgdGhlIGZ1bGwgT3BlbklEIENvbm5lY3Qg RGlzY292ZXJ5IHNjaGVtYSwgSSB0aGluayBhIFNIT1VMRCBpcyByZWFzb25hYmxlLCBJIGRvbid0 IHJlYWxseSBsaWtlIHRoZSBNVVNULgoKCk9uIFNhdHVyZGF5LCBPY3RvYmVyIDExLCAyMDE0IDQ6 MzAgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90 ZToKCgpIaSBhbGwsCgphcyBvbmUgb2YgdGhlIHByb3Bvc2VycyAoYmVzaWRlIEhhbm5lcykgb2Yg dGhlIGNoYW5nZSwgSSB3b3VsZCBsaWtlIHRvIGV4cGxhaW4gdGhlIHJhdGlvbmFsZS4KCj4gLTE2 IGlzIHN1Ym1pdHRlZCwgYW5kIHRoZXJlIGlzIG9uZSBzdWdnZXN0ZWQgY2hhbmdlICh3aGljaCBJ IHdhcyBzdXBwb3NlZCB0byBoYXZlIGFkZGVkIGluIGFscmVhZHkgYW5kIGJsZXcgaXQpLCB3aGlj aCBpcyB0byByZXBsYWNlIHNlY3Rpb24gMy4yLjIgd2l0aCB0aGUgdGV4dCAoZmFydGhlcikgYmVs b3cuIE15IGNvbW1lbnRzIG9uIHRoZSBzdWdnZXN0ZWQgdGV4dDoKCj4gIzEpICBJIGRvbid0IHRo aW5rIHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzdHVmZiBpcyBiYWtlZCBlbm91Z2ggdG8gd2Fu dCB0byBwdWxsIHRoYXQgaW4gdG8gdGhlICJvYXV0aC1jb25maWd1cmF0aW9uIiBkZWZpbml0aW9u LiBJIGRvbid0IHdhbnQgdG8gcHVsbCBpdCBpbiBiZWNhdXNlIEkgZG9uJ3QgdGhpbmsgZHluYW1p YyByZWdpc3RyYXRpb24gaXMgcmVxdWlyZWQgZm9yIFNBU0wvT0FVVEggKGFzIGV2aWRlbmNlZCBi eSB0aGUgR29vZ2xlIGFuZCBPdXRsb29rLmNvbSBpbXBsZW1lbnRhdGlvbnMuCgoKRXhpc3Rpbmcg aW1wbGVtZW50YXRpb25zIGF0IEdvb2dsZSBhbmQgT3V0bG9vay5jb20gYXJlIG5vIGV2aWRlbmNl IGFnYWluc3QgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uLiBUaGV5IGRlbW9uc3RyYXRlIHRo YXQgaXQgaXMgcG9zc2libGUKdG8gaW1wbGVtZW50IHRoZSBzZXJ2ZXIgc2lkZS4gQnV0IHdlIGFy ZSB0YWxraW5nIGFib3V0IGNsaWVudHMgKG1vcmUgcHJlY2lzZWx5IGFib3V0IGdlbmVyaWMgY2xp ZW50cykuIEknbSBub3QgYXdhcmUgb2YgYW55IGdlbmVyaWMKY2xpZW50IGltcGxlbWVudGluZyB0 aGUgU0FTTCBtZWNoYW5pc21zIGluIHRoZSBtb21lbnQuIEkgcmVjb21tZW5kIHRha2luZyBhIGxv b2sgYXQgICAgICAgICAgICAgICAgIGh0dHBzOi8vYnVnemlsbGEubW96aWxsYS5vcmcvc2hvd19i dWcuY2dpP2lkPTg0OTU0MC4KCkJlZm9yZSBJIGRpdmUgaW50byB0aGUgcmVnaXN0cmF0aW9uIGRl dGFpbHMsIEkgd291bGQgbGlrZSB0byBnaXZlIG15IHBlcnNvbmFsIHN1bW1hcnkgd2h5IHRoaXMg U0FTTCBwcm9maWxlIGlzIG5lZWRlZC4KICAKSW4gbXkgb3Bpbmlvbiwgb25lIG9mIHRoZSBtYWlu IHB1cnBvc2VzIG9mIHRoaXMgbWVjaGFuaXNtIGlzIHRvIGFsbG93IGdlbmVyaWMgY2xpZW50cyB0 byBhdXRob3JpemUgYWNjZXNzIHRvIHN0YW5kYXJkIHByb3RvY29scywgc3VjaCBhcyBJTUFQLAp1 c2luZyBPQXV0aCBBY2Nlc3MgVG9rZW5zLiBUaGlzIG9mZmVycyB0aGUgZm9sbG93aW5nIGFkdmFu dGFnZXM6CgotIG11bHRpLWZhY3RvciBhdXRobjogQW4gaW5jcmVhc2luZyBudW1iZXIgb2Ygc2Vy dmljZSBwcm92aWRlcnMgKGUuZy4gR29vZ2xlLCBZYWhvbywgQXBwbGUpIG9mZmVyIDItZmFjdG9y IGF1dGhlbnRpY2F0aW9uIHRvIHRoZWlyIHVzZXJzLApidXQgb25seSBmb3IgYXBwcyBhbmQgd2Vi IHNpdGVzLiBXaHk/IEl0IGN1cnJlbnRseSBkb2VzIG5vdCB3b3JrIGluIGNvbmp1bmN0aW9uIHdp dGggSU1BUCBhbmQgdGhlIGxpa2UuIEluc3RlYWQsIGFwcGxpY2F0aW9uLXNwZWNpZmljIHBhc3N3 b3JkcwptdXN0IGJlIHVzZWQsIHdoaWNoIG9mZmVyIGEgdGVycmlibGUgdXNlciBleHBlcmllbmNl IGFuZCAgICAgICAgICAgICAgICAgdGhlcmVmb3JlIGFyZSBhIHNpZ25pZmljYW50IGJ1cmRlbiBm b3IgYmV0dGVyIEludGVybmV0IHNlY3VyaXR5LiBVc2luZyBPQXV0aCBhY2Nlc3MgdG9rZW5zCmFs bG93cyB0byBkZWNvdXBsZSBzZXJ2aWNlIGFjY2VzcyBhbmQgYXV0aGVudGljYXRpb24vYXV0aG9y aXphdGlvbiBwcm9jZXNzLiBTbyB0aGUgICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2Vy dmVyIGNhbiBjaG9vc2UgdGhlIGFwcHJvcHJpYXRlL2F2YWlsYWJsZQptZWNoYW5pc21zIHRvIGF1 dGhlbnRpY2F0ZSBhdCBpdHMgZGlzY3JldGlvbi4gVGhpcyBhbHNvIGFsbG93cyB0byB1c2UgYW55 IGtpbmQgb2YgKHByb3ZpZGVyLXNwZWNpZmljKSBtdWx0aS1mYWN0b3IgYXV0aGVudGljYXRpb24g bWV0aG9kcyBhbHNvCmluIHRoZSBjb250ZXh0IG9mIElNQVAgYW5kIHRoZSBsaWtlLgoKLSBGdXJ0 aGVybW9yZSwgdXNpbmcgT0F1dGggYWxzbyBhbGxvd3MgdG8gdXNlIHJlZnJlc2ggdG9rZW5zIGFz IHBlcnNpc3RlbnQgY3JlZGVudGlhbCBmb3Igc2VydmljZSBsb2dpbiwgdGhhdCB3YXkgZWxlbWlu YXRpbmcgdGhlIG5lZWQgdG8gc3RvcmUgdXNlcgpwYXNzd29yZHMgb24gZGV2aWNlcy4KICAKU28g YmFzaWNhbGx5LCB0aGUgU0FTTCBPQXV0aCBwcm9maWxlIGNhbiAoYXQgbGVhc3QgaW4gbXkgb3Bp bmlvbikgYmUgYSBtYWpvciBsZWFwIGZvcndhcmQgaW4gSW50ZXJuZXQgc2VjdXJpdHkuCgpXaHkg ZG9lcyB0aGlzIHJlcXVpcmUgZHluYW1pYyByZWdpc3RyYXRpb24/CgpXZWxsLCBPQXV0aCByZXF1 aXJlcyBhbnkgY2xpZW50IHRvIHBvc3Nlc3MgYSBjbGllbnRfaWQgKGFuZCBjbGllbnRfc2VjcmV0 KSB3aXRoIHRoZSBwYXJ0aWN1bGFyIGF1dGhvcml6YXRpb24gc2VydmVyLiBOb3dhZGF5cyBkZXZl bG9wZXJzIHR5cGljYWxseQpyZWdpc3RlciB3aXRoIHRoZSBhdXRoeiBzZXJ2ZXIncyBwcm92aWRl ciBvdXQgb2YgYmFuZCBhbmQgYmFrZSB0aGUgY3JlZGVudGlhbHMgaW50byB0aGUgc29mdHdhcmUg cGFja2FnZS4gVGhpcyB3b3JrcyBmb3IgY2xpZW50cywgd2hpY2gKYXJlIGRpcmVjdGx5IHByb2dy YW1tZWQgYWdhaW5zdCBhIGNlcnRhaW4gZGVwbG95bWVudC9BUEksIHN1Y2ggYXMgRmFjZWJvb2ss IGJ1dCBpcyBpbmFwcHJvcHJpYXRlICAgICAgICAgICAgICAgICAoaWYgbm90IHVuZmVhc2libGUp IGZvciBnZW5lcmljCmNsaWVudHMgdXNpbmcgc3RhbmRhcmRpemVkIHByb3RvY29scywgZS5nLiBU aHVuZGVyYmlyZC4KCk9yIGRvIHlvdSB3YW50IHRvIHJlZ2lzdGVyIHRoZSBUaHVuZGVyYmlyZCBk ZXZlb3BlcnMgd2l0aCBldmVyeSBlLU1haWwvQ2FsZW5kYXItcHJvdmlkZXIgaW4gdGhlIHdvcmxk IHVwLWZyb250PwoKSSBkb24ndCB0aGluayBzby4gVGhhdCdzIHdoeSB0aGUgT0F1dGggV0cgY2Ft ZSB1cCB3aXRoIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRp b24sIHdoaWNoIGFsbG93cwp0aGUgY2xpZW50IHRvIGR5bmFtaWNhbGx5IG9idGFpbiBjbGllbnQg Y3JlZGVudGlhbHMgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIEl0IGJhc2ljYWxseSBz b2x2ZXMgdGhlIGNsaWVudCBjcmVkZW50aWFsIGNoYWxsZW5nZSBmb3IgZ2VuZXJpYwpjbGllbnRz LCBidXQgaXQgZG9lcyBpbnRlZ3JhdGUgdGhlIHJlZ2lzdHJhdGlvbiBzdGVwIGludG8gYW4gb3Zl cmFsbCBwcm9jZXNzLgoKVGhhdCdzIHdoeSBJIHRoaW5rIHdlIG11c3QgZGVmaW5lIGEgd2F5IGZv ciBhIGdlbmVyaWMgU0FTTCBjbGllbnQgdG8sIGJhc2VkIG9uIHVzZXItcHJvdmlkZWQgZGF0YSwg ZmluZCB0aGUgYXBwcm9wcmlhdGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kCnJlZ2lzdGVyIHdp dGggaXQuIEkgdGhpbmsgdGhlIFNBU0wgbWVjaGFuaXNtIHNob3VsZCBzcGVjaWZ5IGhvdyB0aG9z ZSBtZWNoYW5pc21zIGFyZSB1c2VkIGluIGNvbmNlcnQgaW4gb3JkZXIgdG8gYXV0aG9yaXplIHNl cnZpY2UgYWNjZXNzIHVzaW5nIE9BdXRoLgpPdGhlcndpc2UsIHRoZSBTQVNMIG1lY2hhbmlzbSBj YW4gb25seSBiZSB1c2VkIGZvciBwb2ludCB0byBwb2ludCBpbnRlZ3JhdGlvbnMgYW1vbmcgcGFy dG5lcnMgYnV0IG5ldmVyIGZvciBnZW5lcmljIGNsaWVudHMuCgpTbyBJIHRoaW5rIHRydWUgaW50 ZXJvcGVyYWJpbGl0eSBjYWxscyBmb3IgYWRkaXRpb24gb2YgcmVnaXN0cmF0aW9uIGFzIHdlbGwu CgpSZWdhcmRpbmcgc3RhdGUgb2YgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uOiBJdCdzIG5v dCByYXRpZmllZCB5ZXQgYnV0IGFscmVhZHkgc2VudCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbi4K QmVzaWRlIHRoYXQgaXQgaXMgYWxyZWFkeSBpbXBsZW1lbnQgaW4gZXhpc3RpbmcgT3BlbklkICAg ICAgICAgICAgICAgICBDb25uZWN0IGRlcGxveW1lbnRzLgoKPiAjMikgIEkgZGlkbid0IHJlYWxs eSB3YW50IHRvIG1ha2UgYWxsIG9mIHRoZSBPcGVuSUQgZWxlbWVudHMgcmVxdWlyZWQgYnV0IEkg ZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIGhlcmUsIG15IGluaXRpYWwgaW50ZW50IHdhcyB0 byB1c2UgdGhlIE9wZW5JRCBEaXNjb3ZlcnkgZm9ybWF0IGFzIGFuIGV4aXN0aW5nIGZvcm1hdCB0 byBiZSByZS11c2VkIGhlcmUgYnV0IGxlYXZlIGl0IGZsZXhpYmxlLgoKQWdyZWVkLiBVc2luZyB0 aGUgZm9ybWF0IGFzIHNwZWNpZmllZCBieSBPcGVuSUQgQ29ubmVjdCBtYWtlcyBzZW5zZS4gQXMg Z2VuZXJpYyBPQXV0aCBkaWZmZXJzIGZyb20gT3BlbklEIENvbm5lY3QsIHRoZSBXRyBzaG91bGQg KHByb2JhYmx5IGluIGNvb3BlcmF0aW9uIHdpdGgKdGhlIE9BdXRoIFdHKSBkaXNjdXNzLCB3aGlj aCBlbGVtZW50cyBhcmUgcmVhbGx5IG5lZWRlZC4KCj4gIzMpICBJIGFtIGFnYWluc3QgcmVjb21t ZW5kaW5nIHNjb3BlIG5hbWVzIGF0IGFsbCBpbiBhbnkgd2F5LiAgSSB3b3VsZCBub3QgaW5jbHVk ZSB0aGUgbGFzdCBzZW50ZW5jZSBvZiBwYXJhZ3JhcGggNSBiZWxvdyBhbmQgc3RyaWtlIHRoZSBz Y29wZSBuYW1lcy4KCgpHaXZlbiB0aGVyZSBpcyBhbHJlYWR5IGEgcmVzcG9uc2UgcGFyYW1ldGVy IHNjb3BlLCB3aGljaCBpbnRydWN0cyB0aGUgY2xpZW50IG9uIHdoYXQgc2NvcGUgdG8gdXNlIGlu IHRoZSBhdXRoeiByZXF1ZXN0LCBJIHRlbmQgdG8gYWdyZWUuIEknbSBub3QgeWV0IGZ1bGx5CmNv bnZpbmNlZCB3aGV0aGVyIHRoaXMgYXBwcm9hY2ggd2lsbCB3b3JrLiBCdXQgbGV0J3MgZ2l2ZSBp dCBhIHRyeS4KCmtpbmQgcmVnYXJkcywKVG9yc3Rlbi4KCgoKPiAgTmV3IHRleHQgZm9yIDMuMi4y Ogo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gMy4yLjIuICBTZXJ2ZXIgUmVzcG9uc2UgdG8g RmFpbGVkIEF1dGhlbnRpY2F0aW9uCj4KPgo+IEZvciBhIGZhaWxlZCBhdXRoZW50aWNhdGlvbiB0 aGUgc2VydmVyIHJldHVybnMgYSBKU09OIFtSRkM0NjI3XQo+IGZvcm1hdHRlZCBlcnJvciByZXN1 bHQsIGFuZCBmYWlscyB0aGUgYXV0aGVudGljYXRpb24uICBUaGUgZXJyb3IKPiByZXN1bHQgY29u c2lzdHMgb2YgdGhlIGZvbGxvd2luZyB2YWx1ZXM6Cj4KPgo+IHN0YXR1cyAoUkVRVUlSRUQpOiAg VGhlIGF1dGhvcml6YXRpb24gZXJyb3IgY29kZS4gIFZhbGlkIGVycm9yCj4gY29kZXMgYXJlIGRl ZmluZWQgaW4gdGhlIElBTkEgIk9BdXRoIEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnkiCj4gc3Bl Y2lmaWVkIGluIHRoZSBPQXV0aCAyIGNvcmUgc3BlY2lmaWNhdGlvbi4KPgo+Cj4gc2NvcGUgKE9Q VElPTkFMKTogIEFuIE9BdXRoIHNjb3BlIHdoaWNoIGlzIHZhbGlkIHRvIGFjY2VzcyB0aGUKPiBz ZXJ2aWNlLiAgVGhpcyBtYXkgYmUgZW1wdHkgd2hpY2ggaW1wbGllcyB0aGF0IHVuc2NvcGVkIHRv a2Vucwo+IGFyZSByZXF1aXJlZCwgb3IgYSBzY29wZSB2YWx1ZS4gIElmIGEgc2NvcGUgaXMgc3Bl Y2lmaWVkIHRoZW4gYQo+IHNpbmdsZSBzY29wZSBpcyBwcmVmZXJyZWQsIHVzZSBvZiBhIHNwYWNl IHNlcGFyYXRlZCBsaXN0IG9mCj4gc2NvcGVzIGlzIE5PVCBSRUNPTU1FTkRFRC4KPgo+Cj4gb2F1 dGgtY29uZmlndXJhdGlvbiAoT1BUSU9OQUwpOiAgVGhlIFVSTCBmb3IgYSBkb2N1bWVudCBmb2xs b3dpbmcKPiB0aGUgT3BlbklEIFByb3ZpZGVyIENvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24gc2No ZW1hLCBhcwo+IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMgb2YgdGhlIE9wZW5JRCBDb25uZWN0IERp c2NvdmVyeQo+IFtPcGVuSUQuRGlzY292ZXJ5XSwgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhl IHVzZXIuICBUaGUKPiBzZXJ2ZXIgTUFZIHJldHVybiBkaWZmZXJlbnQgVVJMcyBmb3IgdXNlcnMg ZnJvbSBkaWZmZXJlbnQKPiBkb21haW5zIGFuZCBhIGNsaWVudCBNVVNUIE5PVCBjYWNoZSBhIHNp bmdsZSByZXR1cm5lZCB2YWx1ZSBhbmQKPiBhc3N1bWUgaXQgYXBwbGllcyBmb3IgYWxsIHVzZXJz L2RvbWFpbnMgdGhhdCB0aGUgc2VydmVyCj4gc3Vwb3J0cy4gIFRoZSByZXR1cm5lZCBkaXNjb3Zl cnkgZG9jdW1lbnQgTVVTVCBoYXZlIGFsbCBkYXRhCj4gZWxlbWVudHMgcmVxdWlyZWQgYnkgdGhl IE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeSBzcGVjaWZpY2F0aW9uCj4gcG9wdWxhdGVkLiAgSW4g YWRkaXRpb24sIHRoZSBkaXNjb3ZlcnkgZG9jdW1lbnQgTVVTVCBjb250YWluCj4gdGhlICdyZWdp c3RyYXRpb25fZW5kcG9pbnQnIGVsZW1lbnQgdG8gbGVhcm4gYWJvdXQgdGhlIGVuZHBvaW50Cj4g dG8gYmUgdXNlZCB3aXRoIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gcHJvdG9jb2wK PiBbSS1ELmlldGYtb2F1dGgtZHluLXJlZ10gdG8gb2J0YWluIHRoZSBtaW5pbXVtIG51bWJlciBv Zgo+IHBhcmFtZXRlcnMgbmVjZXNzYXJ5IGZvciB0aGUgT0F1dGggcHJvdG9jb2wgZXhjaGFuZ2Ug dG8KPiBmdW5jdGlvbi4gIEF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIGltcGxlbWVudCB0aGUK PiBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgYW5kIG90aGVyIGdyYW50IHR5cGVzIE1BWSBiZQo+ IHN1cHBvcnRlZC4gIEZ1cnRoZXJtb3JlLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCBpbXBs ZW1lbnQKPiB0aGUgYWJpbGl0eSB0byBpc3N1ZSByZWZyZXNoIHRva2VucyBmb3IgdXNlIHdpdGgg bmF0aXZlCj4gYXBwbGljYXRpb25zIHRvIGJlbmVmaXQgZnJvbSBhbiBhYmJyZXZpYXRlZCBwcm90 b2NvbCBleGNoYW5nZS4KPiBUaGUgdXNlIG9mIHRoZSAnb2ZmbGluZV9hY2Nlc3MnIHNjb3BlLCBh cyBkZWZpbmVkIGluCj4gW09wZW5JRC5Db3JlXSBpcyBSRUNPTU1FTkRFRCB0byBnaXZlIGNsaWVu dHMgdGhlIGNhcGFiaWxpdHkgdG8KPiBleHBsaWNpdGx5IHJlcXVlc3QgYSByZWZyZXNoIHRva2Vu Lgo+Cj4KPiBJZiB0aGUgcmVzb3VyY2Ugc2VydmVyIHByb3ZpZGVzIGEgc2NvcGUgKGFzIHBhcnQg b2YgdGhlIGVsZW1lbnQgb2YKPiB0aGUgY29uZmlndXJhdGlvbiBwYXlsb2FkKSB0aGVuIHRoZSBj bGllbnQgTVVTVCAgICAgICAgICAgICAgICAgYWx3YXlzIHJlcXVlc3QKPiBzY29wZWQgdG9rZW5z IGZyb20gdGhlIHRva2VuIGVuZHBvaW50LiAgVGhpcyBzcGVjaWZpY2F0aW9uCj4gUkVDT01NTUVO RHMgdGhlIHVzZSBvZiB0aGUgZm9sbG93aW5nIHNjb3BlczoKPgo+IGltYXA6ICBUaGUgJ2ltYXAn IHNjb3BlIHZhbHVlIGlzIHVzZWQgdG8gaW50ZXJhY3Qgd2l0aCBJTUFQIG1haWwKPiBzZXJ2ZXJz Lgo+Cj4gcG9wMzogIFRoZSAncG9wMycgc2NvcGUgdmFsdWUgaXMgdXNlZCB0byBpbnRlcmFjdCB3 aXRoIFBPUDMgbWFpbAo+IHNlcnZlcnMuCj4KPiB4bXBwOiAgVGhlICd4bXBwJyBzY29wZSB2YWx1 ZSBpcyB1c2VkIHRvIGludGVyYWN0IHdpdGggWE1QUCBzZXJ2ZXJzLgo+Cj4KPgo+IElmIHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgcHJvdmlkZXMgbm8gc2NvcGUgdG8gdGhlIGNsaWVudCB0aGVuIHRoZQo+ IGNsaWVudCBTSE9VTEQgcHJlc3VtZSBhbiBlbXB0eSBzY29wZSAodW5zY29wZWQgdG9rZW4pIGlz IG5lZWRlZC4KPgo+Cj4gU2luY2UgY2xpZW50cyBtYXkgaW50ZXJhY3Qgd2l0aCBhIG51bWJlciBv ZiBhcHBsaWNhdGlvbiBzZXJ2ZXJzLAo+IHN1Y2ggYXMgZW1haWwgc2VydmVycyBhbmQgWE1QUCBz ZXJ2ZXJzLCB0aGV5IG5lZWQgdG8gaGF2ZSBhIHdheQo+IHRvIGRldGVybWluZSB3aGV0aGVyIGR5 bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBoYXMgYmVlbiBwZXJmb3JtZWQKPiBhbHJlYWR5IGFu ZCB3aGV0aGVyIGFuIGFscmVhZHkgYXZhaWxhYmxlIHJlZnJlc2ggdG9rZW4gY2FuIGJlCj4gcmUt dXNlZCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuIGZvciB0aGUgZGVzaXJlZCByZXNvdXJjZSBz ZXJ2ZXIuCj4gVGhpcyBzcGVjaWZpY2F0aW9uIFJFQ09NTUVORHMgdGhhdCBhIGNsaWVudCB1c2Vz IHRoZSBpbmZvcm1hdGlvbiBpbgo+IHRoZSAnaXNzdWUnIGVsZW1lbnQgdG8gbWFrZSB0aGlzIGRl dGVybWluYXRpb24uCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+Cj4gSSB0aGluayB3ZSdy ZSBnZXR0aW5nIHZlcnkgY2xvc2UgOikKPgo+IC1iaWxsCgoKCgoKCgoKCg== ----_com.android.email_1347985349412330 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+SGkgQmlsbCw8ZGl2Pjxicj48L2Rp dj48ZGl2PmFyZSB5b3UgcHJvcG9zaW5nIHRvIHdyaXRlIGEgbmV3ICJnZW5lcmljIGNsaWVudCIg SS1EL1JGQyBpbiB0aGUgT0F1dGggV0c/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5raW5kIHJl Z2FyZHMsJm5ic3A7PC9kaXY+PGRpdj5Ub3JzdGVuLiZuYnNwOzwvZGl2Pjxicj48YnI+PGRpdj4t LS0tLS0tLSBVcnNwcsO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS08L2Rpdj48ZGl2PlZvbjog QmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gPC9kaXY+PGRpdj5EYXR1bToxMy4x MC4yMDE0ICAyMzowNSAgKEdNVCswMTowMCkgPC9kaXY+PGRpdj5BbjogVG9yc3RlbiBMb2RkZXJz dGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+LCBLaXR0ZW5AaWV0Zi5vcmcgPC9kaXY+PGRp dj5DYzogdGpzQHBzYXV4LmNvbSwgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2Zlbmln QGdteC5uZXQ+LCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4gPC9kaXY+PGRpdj5CZXRy ZWZmOiBSZTogW2tpdHRlbl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0 aC0xNi50eHQgPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IzAwMDsgYmFj a2dyb3VuZC1jb2xvcjojZmZmOyBmb250LWZhbWlseTpIZWx2ZXRpY2FOZXVlLCBIZWx2ZXRpY2Eg TmV1ZSwgSGVsdmV0aWNhLCBBcmlhbCwgTHVjaWRhIEdyYW5kZSwgc2Fucy1zZXJpZjtmb250LXNp emU6MTZweCI+PGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTI3OTMwMzkxODVfMzIwMDY1IiBkaXI9 Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZTogMTUuNTU1NTU2Mjk3MzAyMnB4OyIgY2xhc3M9IiI+PHNw YW4gaWQ9Inl1aV8zXzE2XzBfMV8xNDEyNzkzMDM5MTg1XzMyMDA3NSIgY2xhc3M9IiIgc3R5bGU9 IiI+MyB0aHJvdWdoIDYgc2hvdWxkIGJlIGhhbmRsZWQgYnkgT0F1dGggKGFuZCBPcGVuSUQ/KSBh bmQgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlYy4gJm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDE1LjU1NTU1NjI5NzMwMjJweDsiIGNsYXNzPSIiPlRoaXMgc3Bl YyBkZWFscyB3aXRoIDEgYW5kIG1heWJlIDIgJmFtcDsgNyBhYm92ZSkuICZuYnNwOzwvc3Bhbj48 L2Rpdj48ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQxMjc5MzAzOTE4NV8zMjAwNjUiIGRpcj0ibHRy IiBzdHlsZT0iZm9udC1zaXplOiAxNS41NTU1NTYyOTczMDIycHg7IiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxNS41NTU1NTYyOTczMDIycHg7IiBjbGFzcz0iIj48YnI+PC9zcGFu PjwvZGl2PjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDEyNzkzMDM5MTg1XzMyMDA2NSIgZGlyPSJs dHIiIHN0eWxlPSJmb250LXNpemU6IDE1LjU1NTU1NjI5NzMwMjJweDsiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDE2cHg7IiBpZD0ieXVpXzNfMTZfMF8xXzE0MTI3OTMwMzkxODVf MzIyNzQ4Ij5BIGdlbmVyaWMgbWFpbC9jb250YWN0cy9jYWxlbmRhciBjbGllbnQgd2lsbCB1c2Vk IG1vcmUgdGhhbiBTQVNMIGVuZHBvaW50cywgbm90YWJseSBDYWxEQVYgYW5kIENhcmREQVYuICZu YnNwO1RoaXMgaXNuJ3QgdGhlIHBsYWNlIHRvIHNvbHZlIHRoZSBnZW5lcmFsIHByb2JsZW0uICZu YnNwOyZuYnNwOzwvc3Bhbj48YnI+PC9kaXY+PGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTI3OTMw MzkxODVfMzIwMDY1IiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZTogMTUuNTU1NTU2Mjk3MzAy MnB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTZweDsiPjxicj48L3NwYW4+ PC9kaXY+PGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTI3OTMwMzkxODVfMzIwMDY1IiBkaXI9Imx0 ciIgc3R5bGU9ImZvbnQtc2l6ZTogMTUuNTU1NTU2Mjk3MzAyMnB4OyIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTZweDsiPi1iaWxsPC9zcGFuPjwvZGl2PjxkaXYgaWQ9Inl1aV8z XzE2XzBfMV8xNDEyNzkzMDM5MTg1XzMyMDA2NSIgZGlyPSJsdHIiPjxzcGFuPjxicj48L3NwYW4+ PC9kaXY+IDxkaXYgY2xhc3M9InF0ZFNlcGFyYXRlQlIiPjxicj48YnI+PC9kaXY+PGRpdiBjbGFz cz0ieWFob29fcXVvdGVkIiBzdHlsZT0iZGlzcGxheTogYmxvY2s7Ij4gPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYU5ldWUsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIEFyaWFs LCBMdWNpZGEgR3JhbmRlLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij4gPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYU5ldWUsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2Es IEFyaWFsLCBMdWNpZGEgR3JhbmRlLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij4gPGRp diBkaXI9Imx0ciI+IDxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj4gT24gTW9uZGF5LCBPY3Rv YmVyIDEzLCAyMDE0IDE6NDggUE0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0Jmd0OyB3cm90ZTo8YnI+IDwvZm9udD4gPC9kaXY+ICA8YnI+PGJyPiA8ZGl2 IGNsYXNzPSJ5X21zZ19jb250YWluZXIiPjxkaXYgaWQ9InlpdjE3Nzk1NjI2NTgiPjxkaXY+CiAg ICBIaSBCaWxsLDxiciBjbGVhcj0ibm9uZSI+CiAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgPGRp diBjbGFzcz0ieWl2MTc3OTU2MjY1OG1vei1jaXRlLXByZWZpeCI+QW0gMTMuMTAuMjAxNCAxODow OCwgc2NocmllYiBCaWxsCiAgICAgIE1pbGxzOjxiciBjbGVhcj0ibm9uZSI+CiAgICA8L2Rpdj4K ICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICA8ZGl2IHN0eWxlPSJjb2xvcjojMDAw O2JhY2tncm91bmQtY29sb3I6I2ZmZjtmb250LWZhbWlseTpIZWx2ZXRpY2FOZXVlLCBIZWx2ZXRp Y2EgTmV1ZSwgSGVsdmV0aWNhLCBBcmlhbCwgTHVjaWRhIEdyYW5kZSwgc2Fucy1zZXJpZjtmb250 LXNpemU6MTZweDsiPgogICAgICAgIDxkaXYgZGlyPSJsdHIiIGlkPSJ5aXYxNzc5NTYyNjU4eXVp XzNfMTZfMF8xXzE0MTI3OTMwMzkxODVfMjE1MjI2Ij48c3BhbiBpZD0ieWl2MTc3OTU2MjY1OHl1 aV8zXzE2XzBfMV8xNDEyNzkzMDM5MTg1XzIxNjcwNyI+SSB0b3RhbGx5IGFncmVlIHRoYXQKICAg ICAgICAgICAgZ2VuZXJpYyBhbmQgaW50ZXJvcGVyYWJsZSBPQXV0aCBjbGllbnQgaW1wbGVtZW50 YXRpb25zIG5lZWQKICAgICAgICAgICAgYm90aCBlbmRwb2ludCBkaXNjb3ZlcnkgYW5kIGNsaWVu dCByZWdpc3RyYXRpb24uICZuYnNwO0kgZGlzYWdyZWUKICAgICAgICAgICAgdGhhdCB0aGlzIHNw ZWMgbmVlZHMgcmVnaXN0cmF0aW9uLiZuYnNwOyA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAg PC9zcGFuPjwvZGl2PgogICAgICA8L2Rpdj4KICAgIDwvYmxvY2txdW90ZT4KICAgIDxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGlkPSJ5aXYxNzc5NTYyNjU4eXVpXzNfMTZfMF8xXzE0MTI3 OTMwMzkxODVfMjE2NzA3Ij5UaGlzCiAgICAgICAgc3BlYyBpcyBhYm91dCB1c2luZyBPQXV0aCBv biByZXNvdXJjZSBzZXJ2ZXJzIHdoaWNoIGhhdmUgbm90aGluZwogICAgICAgIHRvIGRvIHdpdGgg YXV0aGVudGljYXRpb24gYW5kIHRva2VuIGlzc3VhbmNlLiA8L3NwYW4+PC9ibG9ja3F1b3RlPgog ICAgPGJyIGNsZWFyPSJub25lIj4KICAgIEkgYWdyZWUgdGhlc2UgYXJlIGRpZmZlcmVudCBhc3Bl Y3RzLiBEb2VzIHRoaXMgbWVhbiB0aGV5IG5lZWQgdG8gYmUKICAgIHRyZWF0ZWQgaW4gZGlmZmVy ZW50IHNwZWNzPyBXaGF0IGlzIHRoZSBiZW5lZml0IG9mIHRoaXMgYXBwcm9hY2g/IDxiciBjbGVh cj0ibm9uZSI+CiAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgSSdtIG5vdCBsb29raW5nIGZvciBh IGdlbmVyaWMgT0F1dGggY2xpZW50LiBNeSBnb2FsIGlzIHRvIGVuYWJsZSB0aGUKICAgIGRldmVs b3BtZW50IG9mIGdlbmVyaWMgZW1haWwvY2FsZW5kYXIveG1wcCAuLi4gY2xpZW50cywgd2hpY2gK ICAgIGF1dGhvcml6ZSBhY2Nlc3MgdG8gdGhlIHJlc3BlY3RpdmUgc2VydmljZSB1c2luZyBPQXV0 aC48YnIgY2xlYXI9Im5vbmUiPgogICAgU3VjaCBhIGdlbmVyaWMgY2xpZW50IG11c3QgKGF0IG1v c3QpIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBzdGVwcyBpbgogICAgb3JkZXIgdG8gZ2V0IGFjY2Vz cyB0byB0aGUgcmVzb3VyY2Ugc2VydmVyOjxiciBjbGVhcj0ibm9uZSI+CiAgICA8YnIgY2xlYXI9 Im5vbmUiPgogICAgMSkgY2xpZW50IHRyaWVzIHRvIGFjY2VzcyByZXNvdXJjZSBzZXJ2ZXI8YnIg Y2xlYXI9Im5vbmUiPgogICAgMikgcmVzb3VyY2Ugc2VydmVyIHJlZnVzZXMgYWNjZXNzIGFuZCBy ZXR1cm5zIGRpc2NvdmVyeSBVUkw8YnIgY2xlYXI9Im5vbmUiPgogICAgMykgY2xpZW50IG9idGFp bnMgbWV0YWRhdGEgZnJvbSBkaXNjb3ZlcnkgVVJMPGJyIGNsZWFyPSJub25lIj4KICAgIDQpIGNs aWVudCBkZXRlcm1pbmVzIGl0cyBjbGllbnQgY3JlZGVudGlhbHMgZm9yIHRoaXMgcGFydGljdWxh cgogICAgYXV0aHogc2VydmVyPGJyIGNsZWFyPSJub25lIj4KICAgIDUpIGlmIGNsaWVudCBpcyBu b3QgaW4gcG9zc2Vzc2lvbiBvZiBzdWl0YWJsZSBjbGllbnQgY3JlZGVudGlhbHMKICAgIC0mZ3Q7 Jm5ic3A7IHJlZ2lzdGVyIHdpdGggdGhlIGF1dGh6IHNlcnZlciAoYXQgdGhlIHJlZ2lzdHJhdGlv biBlbmRwb2ludAogICAgb2J0YWluZWQgZnJvbSB0aGUgZGlzY292ZXJ5IGRvY3VtZW50KTxiciBj bGVhcj0ibm9uZSI+CiAgICA2KSBjbGllbnQgcGVyZm9ybXMgYXV0aHogZmxvdyB3aXRoIHRoZSBh dXRoeiBzZXJ2ZXI8YnIgY2xlYXI9Im5vbmUiPgogICAgNykgY2xpZW50IGFjY2Vzc2VzIHJlc291 cmNlIHNlcnZlciBhZ2FpbiAod2l0aCBuZXcgYWNjZXNzIHRva2VuKSA8YnIgY2xlYXI9Im5vbmUi PgogICAgPGJyIGNsZWFyPSJub25lIj4KICAgIFRoaXMgc3BlYyBjdXJyZW50bHkgZG9lcyBub3Qg c3BlY2lmeSBzdGVwcyA0IHRocm91Z2ggNiwgd2hpY2ggbWVhbnMKICAgIHRoZXJlIGlzIG5vIHdh eSB0byBpbXBsZW1lbnQgdGhlIHdob2xlIHByb2Nlc3MgaW4gYW4gaW50ZXJvcGVyYWJsZQogICAg d2F5IGluIG15IGdlbmVyaWMgZW1haWwgY2xpZW50LiBJIHRoZXJlZm9yZSBzdWdnZXN0IHRvIGFk ZAogICAgcmVnaXN0cmF0aW9uIHRvIHRoaXMgc3BlYyBpbiBvcmRlciB0byBjb3ZlciB0aGUgZW50 aXJlIHByb2Nlc3MuIDxiciBjbGVhcj0ibm9uZSI+CiAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAg RG8geW91IGhhdmUgYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwgdG8gYWNoaWV2ZSB0aGlzIGdvYWw/ IDxiciBjbGVhcj0ibm9uZSI+CiAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+CiAgICAgIDxkaXYgc3R5bGU9ImNvbG9yOiMwMDA7YmFja2dyb3VuZC1jb2xv cjojZmZmO2ZvbnQtZmFtaWx5OkhlbHZldGljYU5ldWUsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRp Y2EsIEFyaWFsLCBMdWNpZGEgR3JhbmRlLCBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNnB4OyI+CiAg ICAgICAgPGRpdiBkaXI9Imx0ciIgaWQ9InlpdjE3Nzk1NjI2NTh5dWlfM18xNl8wXzFfMTQxMjc5 MzAzOTE4NV8yMTUyMjYiPjxzcGFuIGlkPSJ5aXYxNzc5NTYyNjU4eXVpXzNfMTZfMF8xXzE0MTI3 OTMwMzkxODVfMjE2NzA3Ij5XZSBtaWdodCBuZWVkIHRvIHRhbGsKICAgICAgICAgICAgYWJvdXQg Y2xpZW50IHJlZ2lzdHJhdGlvbiByZXF1aXJlbWVudHMgaW4gYSB0b2tlbiBwcm9maWxlLAogICAg ICAgICAgICBidXQgdGhpcyBkcmFmdCBkb2Vzbid0IGRlZmluZSBuZXcgdG9rZW5zIGVpdGhlci48 L3NwYW4+PC9kaXY+CiAgICAgIDwvZGl2PgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJyIGNsZWFy PSJub25lIj4KICAgIFRoZXJlIGlzIG5vIG5lZWQgdG8gZGVmaW5lIG5ldyB0b2tlbnMgYXMgdGhp cyBpcyBub3QgcmVsZXZhbnQgZm9yCiAgICBjbGllbnQvcmVzb3VyY2Ugc2VydmVyIGludGVyb3Au IFJlc291cmNlIHNlcnZlciBrbm93IHRoZSBhdXRoegogICAgc2VydmVyJ3MgdG9rZW4gZm9ybWF0 ICh3aGljaCBpcyBzdGFuZGFyZCBpbiBPQXV0aCBkZXBsb3ltZW50cykuIDxiciBjbGVhcj0ibm9u ZSI+CiAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAga2luZCByZWdhcmRzLDxiciBjbGVhcj0ibm9u ZSI+CiAgICBUb3JzdGVuLjxkaXYgY2xhc3M9InlpdjE3Nzk1NjI2NTh5cXQ2OTgyNjEwMDYwIiBp ZD0ieWl2MTc3OTU2MjY1OHlxdGZkNDI1MzQiPjxiciBjbGVhcj0ibm9uZSI+CiAgICA8YnIgY2xl YXI9Im5vbmUiPgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgIDxkaXYgc3R5bGU9 ImNvbG9yOiMwMDA7YmFja2dyb3VuZC1jb2xvcjojZmZmO2ZvbnQtZmFtaWx5OkhlbHZldGljYU5l dWUsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIEFyaWFsLCBMdWNpZGEgR3JhbmRlLCBzYW5z LXNlcmlmO2ZvbnQtc2l6ZToxNnB4OyI+CiAgICAgICAgPGRpdiBkaXI9Imx0ciIgaWQ9InlpdjE3 Nzk1NjI2NTh5dWlfM18xNl8wXzFfMTQxMjc5MzAzOTE4NV8yMTUyMjYiPjxzcGFuPjxiciBjbGVh cj0ibm9uZSI+CiAgICAgICAgICA8L3NwYW4+PC9kaXY+CiAgICAgICAgPGRpdiBkaXI9Imx0ciIg aWQ9InlpdjE3Nzk1NjI2NTh5dWlfM18xNl8wXzFfMTQxMjc5MzAzOTE4NV8yMTUyMjYiPk9uIHdo ZXRoZXIKICAgICAgICAgIHRvIHNwZWNpZnkgdGhlIGZ1bGwgT3BlbklEIENvbm5lY3QgRGlzY292 ZXJ5IHNjaGVtYSwgSSB0aGluayBhCiAgICAgICAgICBTSE9VTEQgaXMgcmVhc29uYWJsZSwgSSBk b24ndCByZWFsbHkgbGlrZSB0aGUgTVVTVC48L2Rpdj4KICAgICAgICA8ZGl2IGNsYXNzPSJ5aXYx Nzc5NTYyNjU4cXRkU2VwYXJhdGVCUiI+PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgIDxiciBj bGVhcj0ibm9uZSI+CiAgICAgICAgPC9kaXY+CiAgICAgICAgPGRpdiBjbGFzcz0ieWl2MTc3OTU2 MjY1OHlhaG9vX3F1b3RlZCIgc3R5bGU9ImRpc3BsYXk6IGJsb2NrOyI+CiAgICAgICAgICA8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2FOZXVlLCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0 aWNhLCBBcmlhbCwgTHVjaWRhIEdyYW5kZSwgc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPgog ICAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2FOZXVlLCBIZWx2ZXRp Y2EgTmV1ZSwgSGVsdmV0aWNhLCBBcmlhbCwgTHVjaWRhIEdyYW5kZSwgc2Fucy1zZXJpZjtmb250 LXNpemU6MTZweDsiPgogICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPiA8Zm9udCBmYWNlPSJB cmlhbCIgc2l6ZT0iMiI+IE9uIFNhdHVyZGF5LAogICAgICAgICAgICAgICAgICBPY3RvYmVyIDEx LCAyMDE0IDQ6MzAgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQKICAgICAgICAgICAgICAgICAgPGEg cmVsPSJub2ZvbGxvdyIgc2hhcGU9InJlY3QiIGNsYXNzPSJ5aXYxNzc5NTYyNjU4bW96LXR4dC1s aW5rLXJmYzIzOTZFIiB5bWFpbHRvPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRh cmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPiZsdDt0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDs8L2E+IHdyb3RlOjxiciBjbGVhcj0ibm9uZSI+CiAg ICAgICAgICAgICAgICA8L2ZvbnQ+IDwvZGl2PgogICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICA8ZGl2IGNs YXNzPSJ5aXYxNzc5NTYyNjU4eV9tc2dfY29udGFpbmVyIj5IaSBhbGwsPGJyIGNsZWFyPSJub25l Ij4KICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICBhcyBv bmUgb2YgdGhlIHByb3Bvc2VycyAoYmVzaWRlIEhhbm5lcykgb2YgdGhlIGNoYW5nZSwgSQogICAg ICAgICAgICAgICAgd291bGQgbGlrZSB0byBleHBsYWluIHRoZSByYXRpb25hbGUuPGJyIGNsZWFy PSJub25lIj4KICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAg ICAmZ3Q7IC0xNiBpcyBzdWJtaXR0ZWQsIGFuZCB0aGVyZSBpcyBvbmUgc3VnZ2VzdGVkIGNoYW5n ZQogICAgICAgICAgICAgICAgKHdoaWNoIEkgd2FzIHN1cHBvc2VkIHRvIGhhdmUgYWRkZWQgaW4g YWxyZWFkeSBhbmQgYmxldwogICAgICAgICAgICAgICAgaXQpLCB3aGljaCBpcyB0byByZXBsYWNl IHNlY3Rpb24gMy4yLjIgd2l0aCB0aGUgdGV4dAogICAgICAgICAgICAgICAgKGZhcnRoZXIpIGJl bG93LiBNeSBjb21tZW50cyBvbiB0aGUgc3VnZ2VzdGVkIHRleHQ6PGJyIGNsZWFyPSJub25lIj4K ICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7ICMx KSZuYnNwOyBJIGRvbid0IHRoaW5rIHRoZSBkeW5hbWljIHJlZ2lzdHJhdGlvbiBzdHVmZgogICAg ICAgICAgICAgICAgaXMgYmFrZWQgZW5vdWdoIHRvIHdhbnQgdG8gcHVsbCB0aGF0IGluIHRvIHRo ZQogICAgICAgICAgICAgICAgIm9hdXRoLWNvbmZpZ3VyYXRpb24iIGRlZmluaXRpb24uIEkgZG9u J3Qgd2FudCB0byBwdWxsCiAgICAgICAgICAgICAgICBpdCBpbiBiZWNhdXNlIEkgZG9uJ3QgdGhp bmsgZHluYW1pYyByZWdpc3RyYXRpb24gaXMKICAgICAgICAgICAgICAgIHJlcXVpcmVkIGZvciBT QVNML09BVVRIIChhcyBldmlkZW5jZWQgYnkgdGhlIEdvb2dsZSBhbmQKICAgICAgICAgICAgICAg IE91dGxvb2suY29tIGltcGxlbWVudGF0aW9ucy48YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAg ICAgICAgPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9uZSI+ CiAgICAgICAgICAgICAgICBFeGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYXQgR29vZ2xlIGFuZCBP dXRsb29rLmNvbSBhcmUKICAgICAgICAgICAgICAgIG5vIGV2aWRlbmNlIGFnYWluc3QgZHluYW1p YyBjbGllbnQgcmVnaXN0cmF0aW9uLiBUaGV5CiAgICAgICAgICAgICAgICBkZW1vbnN0cmF0ZSB0 aGF0IGl0IGlzIHBvc3NpYmxlPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIHRvIGlt cGxlbWVudCB0aGUgc2VydmVyIHNpZGUuIEJ1dCB3ZSBhcmUgdGFsa2luZyBhYm91dAogICAgICAg ICAgICAgICAgY2xpZW50cyAobW9yZSBwcmVjaXNlbHkgYWJvdXQgZ2VuZXJpYyBjbGllbnRzKS4g SSdtIG5vdAogICAgICAgICAgICAgICAgYXdhcmUgb2YgYW55IGdlbmVyaWM8YnIgY2xlYXI9Im5v bmUiPgogICAgICAgICAgICAgICAgY2xpZW50IGltcGxlbWVudGluZyB0aGUgU0FTTCBtZWNoYW5p c21zIGluIHRoZSBtb21lbnQuIEkKICAgICAgICAgICAgICAgIHJlY29tbWVuZCB0YWtpbmcgYSBs b29rIGF0CiAgICAgICAgICAgICAgICA8YSByZWw9Im5vZm9sbG93IiBzaGFwZT0icmVjdCIgY2xh c3M9InlpdjE3Nzk1NjI2NThtb3otdHh0LWxpbmstZnJlZXRleHQiIHRhcmdldD0iX2JsYW5rIiBo cmVmPSJodHRwczovL2J1Z3ppbGxhLm1vemlsbGEub3JnL3Nob3dfYnVnLmNnaT9pZD04NDk1NDAi Pmh0dHBzOi8vYnVnemlsbGEubW96aWxsYS5vcmcvc2hvd19idWcuY2dpP2lkPTg0OTU0MDwvYT4u PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9uZSI+CiAgICAg ICAgICAgICAgICBCZWZvcmUgSSBkaXZlIGludG8gdGhlIHJlZ2lzdHJhdGlvbiBkZXRhaWxzLCBJ IHdvdWxkCiAgICAgICAgICAgICAgICBsaWtlIHRvIGdpdmUgbXkgcGVyc29uYWwgc3VtbWFyeSB3 aHkgdGhpcyBTQVNMIHByb2ZpbGUKICAgICAgICAgICAgICAgIGlzIG5lZWRlZC48YnIgY2xlYXI9 Im5vbmUiPgogICAgICAgICAgICAgICAgJm5ic3A7IDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAg ICAgICAgICBJbiBteSBvcGluaW9uLCBvbmUgb2YgdGhlIG1haW4gcHVycG9zZXMgb2YgdGhpcwog ICAgICAgICAgICAgICAgbWVjaGFuaXNtIGlzIHRvIGFsbG93IGdlbmVyaWMgY2xpZW50cyB0byBh dXRob3JpemUKICAgICAgICAgICAgICAgIGFjY2VzcyB0byBzdGFuZGFyZCBwcm90b2NvbHMsIHN1 Y2ggYXMgSU1BUCw8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgdXNpbmcgT0F1dGgg QWNjZXNzIFRva2Vucy4gVGhpcyBvZmZlcnMgdGhlIGZvbGxvd2luZwogICAgICAgICAgICAgICAg YWR2YW50YWdlczo8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgPGJyIGNsZWFyPSJu b25lIj4KICAgICAgICAgICAgICAgIC0gbXVsdGktZmFjdG9yIGF1dGhuOiBBbiBpbmNyZWFzaW5n IG51bWJlciBvZiBzZXJ2aWNlCiAgICAgICAgICAgICAgICBwcm92aWRlcnMgKGUuZy4gR29vZ2xl LCBZYWhvbywgQXBwbGUpIG9mZmVyIDItZmFjdG9yCiAgICAgICAgICAgICAgICBhdXRoZW50aWNh dGlvbiB0byB0aGVpciB1c2Vycyw8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgYnV0 IG9ubHkgZm9yIGFwcHMgYW5kIHdlYiBzaXRlcy4gV2h5PyBJdCBjdXJyZW50bHkgZG9lcwogICAg ICAgICAgICAgICAgbm90IHdvcmsgaW4gY29uanVuY3Rpb24gd2l0aCBJTUFQIGFuZCB0aGUgbGlr ZS4gSW5zdGVhZCwKICAgICAgICAgICAgICAgIGFwcGxpY2F0aW9uLXNwZWNpZmljIHBhc3N3b3Jk czxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICBtdXN0IGJlIHVzZWQsIHdoaWNoIG9m ZmVyIGEgdGVycmlibGUgdXNlciBleHBlcmllbmNlIGFuZAogICAgICAgICAgICAgICAgdGhlcmVm b3JlIGFyZSBhIHNpZ25pZmljYW50IGJ1cmRlbiBmb3IgYmV0dGVyIEludGVybmV0CiAgICAgICAg ICAgICAgICBzZWN1cml0eS4gVXNpbmcgT0F1dGggYWNjZXNzIHRva2VuczxiciBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgICBhbGxvd3MgdG8gZGVjb3VwbGUgc2VydmljZSBhY2Nlc3MgYW5k CiAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHByb2Nlc3MuIFNv IHRoZQogICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FuIGNob29zZSB0aGUK ICAgICAgICAgICAgICAgIGFwcHJvcHJpYXRlL2F2YWlsYWJsZTxiciBjbGVhcj0ibm9uZSI+CiAg ICAgICAgICAgICAgICBtZWNoYW5pc21zIHRvIGF1dGhlbnRpY2F0ZSBhdCBpdHMgZGlzY3JldGlv bi4gVGhpcyBhbHNvCiAgICAgICAgICAgICAgICBhbGxvd3MgdG8gdXNlIGFueSBraW5kIG9mIChw cm92aWRlci1zcGVjaWZpYykKICAgICAgICAgICAgICAgIG11bHRpLWZhY3RvciBhdXRoZW50aWNh dGlvbiBtZXRob2RzIGFsc288YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgaW4gdGhl IGNvbnRleHQgb2YgSU1BUCBhbmQgdGhlIGxpa2UuPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAg ICAgICAgIDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAtIEZ1cnRoZXJtb3JlLCB1 c2luZyBPQXV0aCBhbHNvIGFsbG93cyB0byB1c2UgcmVmcmVzaAogICAgICAgICAgICAgICAgdG9r ZW5zIGFzIHBlcnNpc3RlbnQgY3JlZGVudGlhbCBmb3Igc2VydmljZSBsb2dpbiwgdGhhdAogICAg ICAgICAgICAgICAgd2F5IGVsZW1pbmF0aW5nIHRoZSBuZWVkIHRvIHN0b3JlIHVzZXI8YnIgY2xl YXI9Im5vbmUiPgogICAgICAgICAgICAgICAgcGFzc3dvcmRzIG9uIGRldmljZXMuPGJyIGNsZWFy PSJub25lIj4KICAgICAgICAgICAgICAgICZuYnNwOyA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAg ICAgICAgICAgU28gYmFzaWNhbGx5LCB0aGUgU0FTTCBPQXV0aCBwcm9maWxlIGNhbiAoYXQgbGVh c3QgaW4gbXkKICAgICAgICAgICAgICAgIG9waW5pb24pIGJlIGEgbWFqb3IgbGVhcCBmb3J3YXJk IGluIEludGVybmV0IHNlY3VyaXR5LjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8 YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgV2h5IGRvZXMgdGhpcyByZXF1aXJlIGR5 bmFtaWMgcmVnaXN0cmF0aW9uPzxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8YnIg Y2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgV2VsbCwgT0F1dGggcmVxdWlyZXMgYW55IGNs aWVudCB0byBwb3NzZXNzIGEgY2xpZW50X2lkCiAgICAgICAgICAgICAgICAoYW5kIGNsaWVudF9z ZWNyZXQpIHdpdGggdGhlIHBhcnRpY3VsYXIgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgICAg c2VydmVyLiBOb3dhZGF5cyBkZXZlbG9wZXJzIHR5cGljYWxseTxiciBjbGVhcj0ibm9uZSI+CiAg ICAgICAgICAgICAgICByZWdpc3RlciB3aXRoIHRoZSBhdXRoeiBzZXJ2ZXIncyBwcm92aWRlciBv dXQgb2YgYmFuZAogICAgICAgICAgICAgICAgYW5kIGJha2UgdGhlIGNyZWRlbnRpYWxzIGludG8g dGhlIHNvZnR3YXJlIHBhY2thZ2UuIFRoaXMKICAgICAgICAgICAgICAgIHdvcmtzIGZvciBjbGll bnRzLCB3aGljaDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICBhcmUgZGlyZWN0bHkg cHJvZ3JhbW1lZCBhZ2FpbnN0IGEgY2VydGFpbgogICAgICAgICAgICAgICAgZGVwbG95bWVudC9B UEksIHN1Y2ggYXMgRmFjZWJvb2ssIGJ1dCBpcyBpbmFwcHJvcHJpYXRlCiAgICAgICAgICAgICAg ICAoaWYgbm90IHVuZmVhc2libGUpIGZvciBnZW5lcmljPGJyIGNsZWFyPSJub25lIj4KICAgICAg ICAgICAgICAgIGNsaWVudHMgdXNpbmcgc3RhbmRhcmRpemVkIHByb3RvY29scywgZS5nLiBUaHVu ZGVyYmlyZC48YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgPGJyIGNsZWFyPSJub25l Ij4KICAgICAgICAgICAgICAgIE9yIGRvIHlvdSB3YW50IHRvIHJlZ2lzdGVyIHRoZSBUaHVuZGVy YmlyZCBkZXZlb3BlcnMKICAgICAgICAgICAgICAgIHdpdGggZXZlcnkgZS1NYWlsL0NhbGVuZGFy LXByb3ZpZGVyIGluIHRoZSB3b3JsZAogICAgICAgICAgICAgICAgdXAtZnJvbnQ/PGJyIGNsZWFy PSJub25lIj4KICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAg ICBJIGRvbid0IHRoaW5rIHNvLiBUaGF0J3Mgd2h5IHRoZSBPQXV0aCBXRyBjYW1lIHVwIHdpdGgK ICAgICAgICAgICAgICAgIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBkeW5hbWljIGNsaWVudCByZWdp c3RyYXRpb24sIHdoaWNoCiAgICAgICAgICAgICAgICBhbGxvd3M8YnIgY2xlYXI9Im5vbmUiPgog ICAgICAgICAgICAgICAgdGhlIGNsaWVudCB0byBkeW5hbWljYWxseSBvYnRhaW4gY2xpZW50IGNy ZWRlbnRpYWxzIGZyb20KICAgICAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4g SXQgYmFzaWNhbGx5IHNvbHZlcyB0aGUgY2xpZW50CiAgICAgICAgICAgICAgICBjcmVkZW50aWFs IGNoYWxsZW5nZSBmb3IgZ2VuZXJpYzxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICBj bGllbnRzLCBidXQgaXQgZG9lcyBpbnRlZ3JhdGUgdGhlIHJlZ2lzdHJhdGlvbiBzdGVwCiAgICAg ICAgICAgICAgICBpbnRvIGFuIG92ZXJhbGwgcHJvY2Vzcy48YnIgY2xlYXI9Im5vbmUiPgogICAg ICAgICAgICAgICAgPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIFRoYXQncyB3aHkg SSB0aGluayB3ZSBtdXN0IGRlZmluZSBhIHdheSBmb3IgYSBnZW5lcmljCiAgICAgICAgICAgICAg ICBTQVNMIGNsaWVudCB0bywgYmFzZWQgb24gdXNlci1wcm92aWRlZCBkYXRhLCBmaW5kIHRoZQog ICAgICAgICAgICAgICAgYXBwcm9wcmlhdGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kPGJyIGNs ZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIHJlZ2lzdGVyIHdpdGggaXQuIEkgdGhpbmsgdGhl IFNBU0wgbWVjaGFuaXNtIHNob3VsZAogICAgICAgICAgICAgICAgc3BlY2lmeSBob3cgdGhvc2Ug bWVjaGFuaXNtcyBhcmUgdXNlZCBpbiBjb25jZXJ0IGluCiAgICAgICAgICAgICAgICBvcmRlciB0 byBhdXRob3JpemUgc2VydmljZSBhY2Nlc3MgdXNpbmcgT0F1dGguPGJyIGNsZWFyPSJub25lIj4K ICAgICAgICAgICAgICAgIE90aGVyd2lzZSwgdGhlIFNBU0wgbWVjaGFuaXNtIGNhbiBvbmx5IGJl IHVzZWQgZm9yIHBvaW50CiAgICAgICAgICAgICAgICB0byBwb2ludCBpbnRlZ3JhdGlvbnMgYW1v bmcgcGFydG5lcnMgYnV0IG5ldmVyIGZvcgogICAgICAgICAgICAgICAgZ2VuZXJpYyBjbGllbnRz LjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAg ICAgICAgICAgICAgU28gSSB0aGluayB0cnVlIGludGVyb3BlcmFiaWxpdHkgY2FsbHMgZm9yIGFk ZGl0aW9uIG9mCiAgICAgICAgICAgICAgICByZWdpc3RyYXRpb24gYXMgd2VsbC48YnIgY2xlYXI9 Im5vbmUiPgogICAgICAgICAgICAgICAgPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAg IFJlZ2FyZGluZyBzdGF0ZSBvZiBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb246IEl0J3Mgbm90 CiAgICAgICAgICAgICAgICByYXRpZmllZCB5ZXQgYnV0IGFscmVhZHkgc2VudCB0byBJRVNHIGZv ciBwdWJsaWNhdGlvbi48YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgQmVzaWRlIHRo YXQgaXQgaXMgYWxyZWFkeSBpbXBsZW1lbnQgaW4gZXhpc3RpbmcgT3BlbklkCiAgICAgICAgICAg ICAgICBDb25uZWN0IGRlcGxveW1lbnRzLjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAg ICA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyAjMikmbmJzcDsgSSBkaWRu J3QgcmVhbGx5IHdhbnQgdG8gbWFrZSBhbGwgb2YgdGhlIE9wZW5JRAogICAgICAgICAgICAgICAg ZWxlbWVudHMgcmVxdWlyZWQgYnV0IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uCiAgICAg ICAgICAgICAgICBoZXJlLCBteSBpbml0aWFsIGludGVudCB3YXMgdG8gdXNlIHRoZSBPcGVuSUQg RGlzY292ZXJ5CiAgICAgICAgICAgICAgICBmb3JtYXQgYXMgYW4gZXhpc3RpbmcgZm9ybWF0IHRv IGJlIHJlLXVzZWQgaGVyZSBidXQKICAgICAgICAgICAgICAgIGxlYXZlIGl0IGZsZXhpYmxlLjxi ciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAg ICAgICAgICAgQWdyZWVkLiBVc2luZyB0aGUgZm9ybWF0IGFzIHNwZWNpZmllZCBieSBPcGVuSUQg Q29ubmVjdAogICAgICAgICAgICAgICAgbWFrZXMgc2Vuc2UuIEFzIGdlbmVyaWMgT0F1dGggZGlm ZmVycyBmcm9tIE9wZW5JRAogICAgICAgICAgICAgICAgQ29ubmVjdCwgdGhlIFdHIHNob3VsZCAo cHJvYmFibHkgaW4gY29vcGVyYXRpb24gd2l0aDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAg ICAgICB0aGUgT0F1dGggV0cpIGRpc2N1c3MsIHdoaWNoIGVsZW1lbnRzIGFyZSByZWFsbHkgbmVl ZGVkLjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgog ICAgICAgICAgICAgICAgJmd0OyAjMykmbmJzcDsgSSBhbSBhZ2FpbnN0IHJlY29tbWVuZGluZyBz Y29wZSBuYW1lcyBhdCBhbGwKICAgICAgICAgICAgICAgIGluIGFueSB3YXkuJm5ic3A7IEkgd291 bGQgbm90IGluY2x1ZGUgdGhlIGxhc3Qgc2VudGVuY2Ugb2YKICAgICAgICAgICAgICAgIHBhcmFn cmFwaCA1IGJlbG93IGFuZCBzdHJpa2UgdGhlIHNjb3BlIG5hbWVzLjxiciBjbGVhcj0ibm9uZSI+ CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgPGJyIGNs ZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIEdpdmVuIHRoZXJlIGlzIGFscmVhZHkgYSByZXNw b25zZSBwYXJhbWV0ZXIgc2NvcGUsIHdoaWNoCiAgICAgICAgICAgICAgICBpbnRydWN0cyB0aGUg Y2xpZW50IG9uIHdoYXQgc2NvcGUgdG8gdXNlIGluIHRoZSBhdXRoegogICAgICAgICAgICAgICAg cmVxdWVzdCwgSSB0ZW5kIHRvIGFncmVlLiBJJ20gbm90IHlldCBmdWxseTxiciBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgICBjb252aW5jZWQgd2hldGhlciB0aGlzIGFwcHJvYWNoIHdpbGwg d29yay4gQnV0IGxldCdzCiAgICAgICAgICAgICAgICBnaXZlIGl0IGEgdHJ5LjxiciBjbGVhcj0i bm9uZSI+CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAg a2luZCByZWdhcmRzLDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICBUb3JzdGVuLjxi ciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAg ICAgICAgICAgPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgICAmZ3Q7Jm5ic3A7IE5ldyB0ZXh0IGZvciAzLjIuMjo8YnIgY2xl YXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi ciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IDMuMi4yLiZuYnNwOyBTZXJ2ZXIg UmVzcG9uc2UgdG8gRmFpbGVkIEF1dGhlbnRpY2F0aW9uPGJyIGNsZWFyPSJub25lIj4KICAgICAg ICAgICAgICAgICZndDs8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OzxiciBj bGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IEZvciBhIGZhaWxlZCBhdXRoZW50aWNh dGlvbiB0aGUgc2VydmVyIHJldHVybnMgYQogICAgICAgICAgICAgICAgSlNPTiBbUkZDNDYyN108 YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBmb3JtYXR0ZWQgZXJyb3IgcmVz dWx0LCBhbmQgZmFpbHMgdGhlCiAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbi4mbmJzcDsg VGhlIGVycm9yPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgcmVzdWx0IGNv bnNpc3RzIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzOjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAg ICAgICAgICAmZ3Q7PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDs8YnIgY2xl YXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBzdGF0dXMgKFJFUVVJUkVEKTombmJzcDsg VGhlIGF1dGhvcml6YXRpb24gZXJyb3IgY29kZS4mbmJzcDsKICAgICAgICAgICAgICAgIFZhbGlk IGVycm9yPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgY29kZXMgYXJlIGRl ZmluZWQgaW4gdGhlIElBTkEgIk9BdXRoIEV4dGVuc2lvbnMKICAgICAgICAgICAgICAgIEVycm9y IFJlZ2lzdHJ5IjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IHNwZWNpZmll ZCBpbiB0aGUgT0F1dGggMiBjb3JlIHNwZWNpZmljYXRpb24uPGJyIGNsZWFyPSJub25lIj4KICAg ICAgICAgICAgICAgICZndDs8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0Ozxi ciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IHNjb3BlIChPUFRJT05BTCk6Jm5i c3A7IEFuIE9BdXRoIHNjb3BlIHdoaWNoIGlzIHZhbGlkIHRvCiAgICAgICAgICAgICAgICBhY2Nl c3MgdGhlPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgc2VydmljZS4mbmJz cDsgVGhpcyBtYXkgYmUgZW1wdHkgd2hpY2ggaW1wbGllcyB0aGF0CiAgICAgICAgICAgICAgICB1 bnNjb3BlZCB0b2tlbnM8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBhcmUg cmVxdWlyZWQsIG9yIGEgc2NvcGUgdmFsdWUuJm5ic3A7IElmIGEgc2NvcGUgaXMKICAgICAgICAg ICAgICAgIHNwZWNpZmllZCB0aGVuIGE8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAg Jmd0OyBzaW5nbGUgc2NvcGUgaXMgcHJlZmVycmVkLCB1c2Ugb2YgYSBzcGFjZSBzZXBhcmF0ZWQK ICAgICAgICAgICAgICAgIGxpc3Qgb2Y8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAg Jmd0OyBzY29wZXMgaXMgTk9UIFJFQ09NTUVOREVELjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAg ICAgICAgICAmZ3Q7PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDs8YnIgY2xl YXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBvYXV0aC1jb25maWd1cmF0aW9uIChPUFRJ T05BTCk6Jm5ic3A7IFRoZSBVUkwgZm9yIGEKICAgICAgICAgICAgICAgIGRvY3VtZW50IGZvbGxv d2luZzxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IHRoZSBPcGVuSUQgUHJv dmlkZXIgQ29uZmlndXJhdGlvbiBJbmZvcm1hdGlvbgogICAgICAgICAgICAgICAgc2NoZW1hLCBh czxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMgb2YgdGhlIE9wZW5JRCBDb25uZWN0CiAgICAgICAgICAgICAgICBEaXNjb3Zlcnk8YnIg Y2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBbT3BlbklELkRpc2NvdmVyeV0sIHRo YXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZQogICAgICAgICAgICAgICAgdXNlci4mbmJzcDsgVGhl PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgc2VydmVyIE1BWSByZXR1cm4g ZGlmZmVyZW50IFVSTHMgZm9yIHVzZXJzIGZyb20KICAgICAgICAgICAgICAgIGRpZmZlcmVudDxi ciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IGRvbWFpbnMgYW5kIGEgY2xpZW50 IE1VU1QgTk9UIGNhY2hlIGEgc2luZ2xlCiAgICAgICAgICAgICAgICByZXR1cm5lZCB2YWx1ZSBh bmQ8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBhc3N1bWUgaXQgYXBwbGll cyBmb3IgYWxsIHVzZXJzL2RvbWFpbnMgdGhhdCB0aGUKICAgICAgICAgICAgICAgIHNlcnZlcjxi ciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IHN1cG9ydHMuJm5ic3A7IFRoZSBy ZXR1cm5lZCBkaXNjb3ZlcnkgZG9jdW1lbnQgTVVTVCBoYXZlCiAgICAgICAgICAgICAgICBhbGwg ZGF0YTxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IGVsZW1lbnRzIHJlcXVp cmVkIGJ5IHRoZSBPcGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnkKICAgICAgICAgICAgICAgIHNwZWNp ZmljYXRpb248YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBwb3B1bGF0ZWQu Jm5ic3A7IEluIGFkZGl0aW9uLCB0aGUgZGlzY292ZXJ5IGRvY3VtZW50CiAgICAgICAgICAgICAg ICBNVVNUIGNvbnRhaW48YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyB0aGUg J3JlZ2lzdHJhdGlvbl9lbmRwb2ludCcgZWxlbWVudCB0byBsZWFybiBhYm91dAogICAgICAgICAg ICAgICAgdGhlIGVuZHBvaW50PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsg dG8gYmUgdXNlZCB3aXRoIHRoZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24KICAgICAgICAg ICAgICAgIHByb3RvY29sPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgW0kt RC5pZXRmLW9hdXRoLWR5bi1yZWddIHRvIG9idGFpbiB0aGUgbWluaW11bQogICAgICAgICAgICAg ICAgbnVtYmVyIG9mPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgcGFyYW1l dGVycyBuZWNlc3NhcnkgZm9yIHRoZSBPQXV0aCBwcm90b2NvbAogICAgICAgICAgICAgICAgZXhj aGFuZ2UgdG88YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyBmdW5jdGlvbi4m bmJzcDsgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgaW1wbGVtZW50IHRoZTxiciBjbGVhcj0i bm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IGF1dGhvcml6YXRpb24gY29kZSBncmFudCBhbmQg b3RoZXIgZ3JhbnQgdHlwZXMgTUFZCiAgICAgICAgICAgICAgICBiZTxiciBjbGVhcj0ibm9uZSI+ CiAgICAgICAgICAgICAgICAmZ3Q7IHN1cHBvcnRlZC4mbmJzcDsgRnVydGhlcm1vcmUsIGF1dGhv cml6YXRpb24gc2VydmVycyBNVVNUCiAgICAgICAgICAgICAgICBpbXBsZW1lbnQ8YnIgY2xlYXI9 Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyB0aGUgYWJpbGl0eSB0byBpc3N1ZSByZWZyZXNo IHRva2VucyBmb3IgdXNlIHdpdGgKICAgICAgICAgICAgICAgIG5hdGl2ZTxiciBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IGFwcGxpY2F0aW9ucyB0byBiZW5lZml0IGZyb20gYW4g YWJicmV2aWF0ZWQKICAgICAgICAgICAgICAgIHByb3RvY29sIGV4Y2hhbmdlLjxiciBjbGVhcj0i bm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IFRoZSB1c2Ugb2YgdGhlICdvZmZsaW5lX2FjY2Vz cycgc2NvcGUsIGFzIGRlZmluZWQKICAgICAgICAgICAgICAgIGluPGJyIGNsZWFyPSJub25lIj4K ICAgICAgICAgICAgICAgICZndDsgW09wZW5JRC5Db3JlXSBpcyBSRUNPTU1FTkRFRCB0byBnaXZl IGNsaWVudHMgdGhlCiAgICAgICAgICAgICAgICBjYXBhYmlsaXR5IHRvPGJyIGNsZWFyPSJub25l Ij4KICAgICAgICAgICAgICAgICZndDsgZXhwbGljaXRseSByZXF1ZXN0IGEgcmVmcmVzaCB0b2tl bi48YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OzxiciBjbGVhcj0ibm9uZSI+ CiAgICAgICAgICAgICAgICAmZ3Q7PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZn dDsgSWYgdGhlIHJlc291cmNlIHNlcnZlciBwcm92aWRlcyBhIHNjb3BlIChhcyBwYXJ0IG9mCiAg ICAgICAgICAgICAgICB0aGUgZWxlbWVudCBvZjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAg ICAgICAmZ3Q7IHRoZSBjb25maWd1cmF0aW9uIHBheWxvYWQpIHRoZW4gdGhlIGNsaWVudCBNVVNU CiAgICAgICAgICAgICAgICBhbHdheXMgcmVxdWVzdDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAg ICAgICAgICAmZ3Q7IHNjb3BlZCB0b2tlbnMgZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQuJm5ic3A7 IFRoaXMKICAgICAgICAgICAgICAgIHNwZWNpZmljYXRpb248YnIgY2xlYXI9Im5vbmUiPgogICAg ICAgICAgICAgICAgJmd0OyBSRUNPTU1NRU5EcyB0aGUgdXNlIG9mIHRoZSBmb2xsb3dpbmcgc2Nv cGVzOjxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7PGJyIGNsZWFyPSJub25l Ij4KICAgICAgICAgICAgICAgICZndDsgaW1hcDombmJzcDsgVGhlICdpbWFwJyBzY29wZSB2YWx1 ZSBpcyB1c2VkIHRvIGludGVyYWN0CiAgICAgICAgICAgICAgICB3aXRoIElNQVAgbWFpbDxiciBj bGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IHNlcnZlcnMuPGJyIGNsZWFyPSJub25l Ij4KICAgICAgICAgICAgICAgICZndDs8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAg Jmd0OyBwb3AzOiZuYnNwOyBUaGUgJ3BvcDMnIHNjb3BlIHZhbHVlIGlzIHVzZWQgdG8gaW50ZXJh Y3QKICAgICAgICAgICAgICAgIHdpdGggUE9QMyBtYWlsPGJyIGNsZWFyPSJub25lIj4KICAgICAg ICAgICAgICAgICZndDsgc2VydmVycy48YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAg Jmd0OzxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IHhtcHA6Jm5ic3A7IFRo ZSAneG1wcCcgc2NvcGUgdmFsdWUgaXMgdXNlZCB0byBpbnRlcmFjdAogICAgICAgICAgICAgICAg d2l0aCBYTVBQIHNlcnZlcnMuPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDs8 YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OzxiciBjbGVhcj0ibm9uZSI+CiAg ICAgICAgICAgICAgICAmZ3Q7PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsg SWYgdGhlIHJlc291cmNlIHNlcnZlciBwcm92aWRlcyBubyBzY29wZSB0byB0aGUKICAgICAgICAg ICAgICAgIGNsaWVudCB0aGVuIHRoZTxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAm Z3Q7IGNsaWVudCBTSE9VTEQgcHJlc3VtZSBhbiBlbXB0eSBzY29wZSAodW5zY29wZWQKICAgICAg ICAgICAgICAgIHRva2VuKSBpcyBuZWVkZWQuPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAg ICAgICZndDs8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OzxiciBjbGVhcj0i bm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IFNpbmNlIGNsaWVudHMgbWF5IGludGVyYWN0IHdp dGggYSBudW1iZXIgb2YKICAgICAgICAgICAgICAgIGFwcGxpY2F0aW9uIHNlcnZlcnMsPGJyIGNs ZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgc3VjaCBhcyBlbWFpbCBzZXJ2ZXJzIGFu ZCBYTVBQIHNlcnZlcnMsIHRoZXkgbmVlZAogICAgICAgICAgICAgICAgdG8gaGF2ZSBhIHdheTxi ciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IHRvIGRldGVybWluZSB3aGV0aGVy IGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbgogICAgICAgICAgICAgICAgaGFzIGJlZW4gcGVy Zm9ybWVkPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgYWxyZWFkeSBhbmQg d2hldGhlciBhbiBhbHJlYWR5IGF2YWlsYWJsZSByZWZyZXNoCiAgICAgICAgICAgICAgICB0b2tl biBjYW4gYmU8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyByZS11c2VkIHRv IG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4gZm9yIHRoZSBkZXNpcmVkCiAgICAgICAgICAgICAgICBy ZXNvdXJjZSBzZXJ2ZXIuPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDsgVGhp cyBzcGVjaWZpY2F0aW9uIFJFQ09NTUVORHMgdGhhdCBhIGNsaWVudCB1c2VzCiAgICAgICAgICAg ICAgICB0aGUgaW5mb3JtYXRpb24gaW48YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAg Jmd0OyB0aGUgJ2lzc3VlJyBlbGVtZW50IHRvIG1ha2UgdGhpcyBkZXRlcm1pbmF0aW9uLjxiciBj bGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICZndDs8YnIgY2xlYXI9Im5vbmUiPgog ICAgICAgICAgICAgICAgJmd0OzxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAmZ3Q7 IEkgdGhpbmsgd2UncmUgZ2V0dGluZyB2ZXJ5IGNsb3NlIDopPGJyIGNsZWFyPSJub25lIj4KICAg ICAgICAgICAgICAgICZndDs8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgJmd0OyAt YmlsbDxiciBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgog ICAgICAgICAgICAgICAgPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIDxiciBjbGVh cj0ibm9uZSI+CiAgICAgICAgICAgICAgICA8YnIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAg ICAgPGJyIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgIDxiciBjbGVhcj0ibm9uZSI+CiAg ICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPC9kaXY+CiAg ICAgICAgPC9kaXY+CiAgICAgIDwvZGl2PgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJyIGNsZWFy PSJub25lIj4KICA8L2Rpdj48L2Rpdj48L2Rpdj48YnI+PGJyPjwvZGl2PiAgPC9kaXY+IDwvZGl2 PiAgPC9kaXY+IDwvZGl2PjwvYm9keT4= ----_com.android.email_1347985349412330-- From nobody Tue Oct 14 07:55:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6141A87B1 for ; Tue, 14 Oct 2014 07:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxY4QgRa7llt for ; Tue, 14 Oct 2014 07:55:18 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01581A877F for ; Tue, 14 Oct 2014 07:55:17 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-6b-543d39540329 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 49.3C.13180.4593D345; Tue, 14 Oct 2014 10:55:16 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9EEtFN4006514 for ; Tue, 14 Oct 2014 10:55:16 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9EEtDEC027329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Oct 2014 10:55:15 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9EEtDPc010329; Tue, 14 Oct 2014 10:55:13 -0400 (EDT) Date: Tue, 14 Oct 2014 10:55:13 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrBtiaRticPK2vMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVse7mAeaCqcwV117PYmxgPM/UxcjJISFgIjFl1VcoW0ziwr31 bF2MXBxCArOZJNbs+cAI4RxnlJg79SmUc4NJYvG7o1BOA6PEm/0n2ED6WQS0Jf5P7WcGsdkE VCRmvtkIFhcREJbYvfUdWFwYKL702wZGEJtXwFFi8uUlYDWiAjoSq/dPYYGIC0qcnPkEzGYW 0JJYPn0bywRGvllIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQI Cih2F+UdjH8OKh1iFOBgVOLhLYi0CRFiTSwrrsw9xCjJwaQkyltibBsixJeUn1KZkVicEV9U mpNafIhRgoNZSYRXgQMox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEk wWtjAdQoWJSanlqRlplTgpBm4uAEGc4DNNwFpIa3uCAxtzgzHSJ/ilGXo6XpbS+TEEtefl6q lDjvBnOgIgGQoozSPLg5sETwilEc6C1h3gCQUTzAJAI36RXQEiagJa+LrUGWlCQipKQaGI9F lUYzCZ5J4gvm/1QhEsz5O3f3IdfzfWEPZs1ODJz/Ma3Kg3PbU9n7X47NfSG8SfBv+ORr0k+0 L7ysPjbX4ccLVrkJgcXqkdcmRB4/9y38S7qOuqasNVuT0nbnd9ntDXNnMx00WRToqSJ0WItz VhhrLAvz9DClPUtOOAVcE3rUmPp61S6l70osxRmJhlrMRcWJABJsxJjfAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5l6CknOZBF39aZps7wQIsl_L-6o Subject: [kitten] draft-ietf-kitten-iakerb-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:55:23 -0000 Hi all, I've made an update to the IAKERB document, hopefully including all the review comments made on the -00 and -01. It was a manual posting by the secretariat, so there does not appear to be an announce email about it. Here are some links: HTML: https://tools.ietf.org/html/draft-ietf-kitten-iakerb-02 diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-iakerb-02.txt -Ben From nobody Tue Oct 14 08:07:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F161A88F7 for ; Tue, 14 Oct 2014 08:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-y8DNTv_Jmh for ; Tue, 14 Oct 2014 08:06:58 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5636E1A88EC for ; Tue, 14 Oct 2014 08:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413299217; bh=7EKXexEZdN94dTMcLVfE5pqIPg2kLHwulVQ62tIboXM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=oivE+ZwA+gFwigrr1lk1KlWZst+JOK3JbXciuzprA/bHKuDfS5YjIW3Q7nA9JJKAEM2gPgdPrJ6Jq1op2NdOOPt3dMk39BY6vHmVp7zioalQnto0FzrOK+5pw17wBpNisGF4YUH3oqbE1lUf10HmDInRk/TLQYnFNUDVA/988VJZqHoy1ywclKX0v7nSkZ3ummFPSWU/0Ebdb49i58Y/Ze2GrcIJ+dhSyII3MsQR+fTf6PqU0+0TH2cLSzuaXu9UvBTbgWcKI3T5D6FBdUdKWV2NgiJ/6JpwKHKZxTUH4IcKtFl31CKrElI40jlsXCAVHw+LtsyvhHBJC7mLeNc12g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=PC2qRuulO335BjX1YzyRqxsuY9qbgPCxJgKbCpwNDH3LejO2azgeKxR8A8sV1mt/8PE7D4g1PKZnVENINFru8ZEXJkzeCdU/hu9QTuYSDFplpIrid7b2lNhkg2qtkkACHu8658+dTW5jWyCGRBKCLww2mWXKzBAa1KHhs38Hc6iFV5dwCVsNvEu9exa6qupfq3UcZpRnkMwwfzxOadUH9P4LzVDR9uhZKDcDWZEBILDDloXN8iaVttFYamQkganziVl9qBwOSzYNat29j1fMVlv3k6pKGP5ILgQXwl089hWa8YHvaYxgaoB6dbQXlBYasEQeaXsNIsNS9zm+t7lHVQ==; Received: from [98.139.212.151] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 14 Oct 2014 15:06:57 -0000 Received: from [98.139.212.203] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 14 Oct 2014 15:06:57 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 14 Oct 2014 15:06:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 463034.50707.bm@omp1012.mail.bf1.yahoo.com Date: Tue, 14 Oct 2014 15:06:55 +0000 (UTC) From: Bill Mills To: Torsten Lodderstedt , "Kitten@ietf.org" Message-ID: <796188397.63401.1413299215858.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> In-Reply-To: <31r908v52l19r5cb7nsqiouy.1413266582842@email.android.com> References: <31r908v52l19r5cb7nsqiouy.1413266582842@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_63400_1712838063.1413299215847" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/hux5sUO0m5t3a8upUUvT_yhj23g Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:07:04 -0000 ------=_Part_63400_1712838063.1413299215847 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I wasn't planning to. =C2=A0 OpenID is already doing it basically. =C2=A0Th= ere might not yet be =C2=A0a "here's what a well behaved generic client loo= ks like" draft yet, but is that really needed?=20 On Monday, October 13, 2014 11:03 PM, Torsten Lodderstedt wrote: =20 Hi Bill, are you proposing to write a new "generic client" I-D/RFC in the OAuth WG? kind regards,=C2=A0Torsten.=C2=A0 -------- Urspr=C3=BCngliche Nachricht --------Von: Bill Mills Datum:13.10.2= 014 23:05 (GMT+01:00) An: Torsten Lodderstedt , Kitten@ietf.org Cc: tjs@psa= ux.com, Hannes Tschofenig , Benjamin Kaduk Betreff: Re: [kitten] I-D Action= : draft-ietf-kitten-sasl-oauth-16.txt=20 3 through 6 should be handled by OAuth (and OpenID?) and are outside the sc= ope of this spec. =C2=A0This spec deals with 1 and maybe 2 & 7 above). =C2= =A0 A generic mail/contacts/calendar client will used more than SASL endpoints,= notably CalDAV and CardDAV. =C2=A0This isn't the place to solve the genera= l problem. =C2=A0=C2=A0 -bill =20 On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt wrote: =20 Hi Bill, =20 Am 13.10.2014 18:08, schrieb Bill Mills: =20 I totally agree that generic and interoperable OAuth client implementatio= ns need both endpoint discovery and client registration. =C2=A0I disagree t= hat this spec needs registration.=C2=A0=20 =20 =20 This spec is about using OAuth on resource servers which have nothing to do= with authentication and token issuance.=20 =20 I agree these are different aspects. Does this mean they need to be treate= d in different specs? What is the benefit of this approach?=20 =20 I'm not looking for a generic OAuth client. My goal is to enable the devel= opment of generic email/calendar/xmpp ... clients, which authorize access t= o the respective service using OAuth. Such a generic client must (at most) perform the following steps in order = to get access to the resource server: =20 1) client tries to access resource server 2) resource server refuses access and returns discovery URL 3) client obtains metadata from discovery URL 4) client determines its client credentials for this particular authz serv= er 5) if client is not in possession of suitable client credentials ->=C2=A0 = register with the authz server (at the registration endpoint obtained from = the discovery document) 6) client performs authz flow with the authz server 7) client accesses resource server again (with new access token)=20 =20 This spec currently does not specify steps 4 through 6, which means there = is no way to implement the whole process in an interoperable way in my gene= ric email client. I therefore suggest to add registration to this spec in o= rder to cover the entire process.=20 =20 Do you have an alternative proposal to achieve this goal?=20 =20 =20 We might need to talk about client registration requirements in a token p= rofile, but this draft doesn't define new tokens either. =20 =20 There is no need to define new tokens as this is not relevant for client/r= esource server interop. Resource server know the authz server's token forma= t (which is standard in OAuth deployments).=20 =20 kind regards, Torsten. =20 =20 =20 On whether to specify the full OpenID Connect Discovery schema, I think a= SHOULD is reasonable, I don't really like the MUST.=20 =20 On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt wrote: =20 =20 Hi all, =20 as one of the proposers (beside Hannes) of the change, I would like to exp= lain the rationale. =20 > -16 is submitted, and there is one suggested change (which I was suppose= d to have added in already and blew it), which is to replace section 3.2.2 = with the text (farther) below. My comments on the suggested text: =20 > #1)=C2=A0 I don't think the dynamic registration stuff is baked enough t= o want to pull that in to the "oauth-configuration" definition. I don't wan= t to pull it in because I don't think dynamic registration is required for = SASL/OAUTH (as evidenced by the Google and Outlook.com implementations. =20 =20 Existing implementations at Google and Outlook.com are no evidence against= dynamic client registration. They demonstrate that it is possible to implement the server side. But we are talking about clients (more preci= sely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking = a look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. =20 Before I dive into the registration details, I would like to give my perso= nal summary why this SASL profile is needed. =C2=A0=20 In my opinion, one of the main purposes of this mechanism is to allow gene= ric clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: =20 - multi-factor authn: An increasing number of service providers (e.g. Goog= le, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjun= ction with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a s= ignificant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process= . So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any = kind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. =20 - Furthermore, using OAuth also allows to use refresh tokens as persistent= credential for service login, that way eleminating the need to store user passwords on devices. =C2=A0=20 So basically, the SASL OAuth profile can (at least in my opinion) be a maj= or leap forward in Internet security. =20 Why does this require dynamic registration? =20 Well, OAuth requires any client to possess a client_id (and client_secret)= with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credent= ials into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook= , but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. =20 Or do you want to register the Thunderbird deveopers with every e-Mail/Cal= endar-provider in the world up-front? =20 I don't think so. That's why the OAuth WG came up with the specification f= or dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization= server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall proce= ss. =20 That's why I think we must define a way for a generic SASL client to, base= d on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mech= anisms are used in concert in order to authorize service access using OAuth= . Otherwise, the SASL mechanism can only be used for point to point integrat= ions among partners but never for generic clients. =20 So I think true interoperability calls for addition of registration as wel= l. =20 Regarding state of dynamic client registration: It's not ratified yet but = already sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments= . =20 > #2)=C2=A0 I didn't really want to make all of the OpenID elements requir= ed but I don't have a strong opinion here, my initial intent was to use the= OpenID Discovery format as an existing format to be re-used here but leave= it flexible. =20 Agreed. Using the format as specified by OpenID Connect makes sense. As ge= neric OAuth differs from OpenID Connect, the WG should (probably in coopera= tion with the OAuth WG) discuss, which elements are really needed. =20 > #3)=C2=A0 I am against recommending scope names at all in any way.=C2=A0= I would not include the last sentence of paragraph 5 below and strike the = scope names. =20 =20 Given there is already a response parameter scope, which intructs the clie= nt on what scope to use in the authz request, I tend to agree. I'm not yet = fully convinced whether this approach will work. But let's give it a try. =20 kind regards, Torsten. =20 =20 =20 >=C2=A0 New text for 3.2.2: > ----------------------- > 3.2.2.=C2=A0 Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication.=C2=A0 The error > result consists of the following values: > > > status (REQUIRED):=C2=A0 The authorization error code.=C2=A0 Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL):=C2=A0 An OAuth scope which is valid to access the > service.=C2=A0 This may be empty which implies that unscoped tokens > are required, or a scope value.=C2=A0 If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL):=C2=A0 The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user.=C2=A0 The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports.=C2=A0 The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated.=C2=A0 In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function.=C2=A0 Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported.=C2=A0 Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint.=C2=A0 This specification > RECOMMMENDs the use of the following scopes: > > imap:=C2=A0 The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3:=C2=A0 The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp:=C2=A0 The 'xmpp' scope value is used to interact with XMPP servers= . > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_Part_63400_1712838063.1413299215847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wasn't planning to.   Op= enID is already doing it basically.  There might not yet be  a "h= ere's what a well behaved generic client looks like" draft yet, but is that= really needed?


On Monday, October 13, 2014 = 11:03 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi Bill,

are you proposing to w= rite a new "generic client" I-D/RFC in the OAuth WG?

kind regards, 
Torsten. 


-------- Urspr=C3=BCngliche Nachricht -= -------
Von: Bill Mills
Datum:13.10.2014 23:05 (GMT= +01:00)
An: Torsten Lodderstedt , Kitten@ietf.org
Cc: tjs= @psaux.com, Hannes Tschofenig , Benjamin Kaduk
Betreff: Re: [ki= tten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

3 through 6 should be handled by OAuth (and OpenID?) = and are outside the scope of this spec.  This spec deals with 1 and = maybe 2 & 7 above).  

A generic mail/contacts/= calendar client will used more than SASL endpoints, notably CalDAV and Card= DAV.  This isn't the place to solve the general problem.   <= /span>

=
-bill

=


On Mon= day, October 13, 2014 1:48 PM, Torsten Lodderstedt <torsten@lodderstedt.= net> wrote:


Hi Bill,

Am 13.10.2014 18:08, schrie= b Bill Mills:
I totally a= gree that generic and interoperable OAuth client implementations need both endpoint discovery and client registration.  I disagr= ee that this spec needs registration. 
This spec is about using OAuth on resource servers which have nothing to do with authentication and token issuance.

I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach?

I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth.
Such a generic client must (at most) perform the following steps in order to get access to the resource server:

1) client tries to access resource server
2) resource server refuses access and returns discovery URL
3) client obtains metadata from discovery URL
4) client determines its client credentials for this particular authz server
5) if client is not in possession of suitable client credentials ->  register with the authz server (at the registration endpoin= t obtained from the discovery document)
6) client performs authz flow with the authz server
7) client accesses resource server again (with new access token)

This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process.

Do you have an alternative proposal to achieve this goal?

We might ne= ed to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.

There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments).

kind regards,
Torsten.



On whether to specify the full OpenID Connect Discovery schema, I think a SHOULD is reasonable, I don't really like the MUST.


On Saturda= y, October 11, 2014 4:30 AM, Torsten Lodderstedt <torsten@lodderstedt.ne= t> wrote:


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to explain the rationale.

> -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D8= 49540.

Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
 
In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user
passwords on devices.
 
So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall process.

That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well.

Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect deployments.

> #2)  I didn't really want to make all of the Open= ID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
the OAuth WG) discuss, which elements are really needed.
> #3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.


Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>  New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication<= br clear=3D"none"> >
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.=   Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid = to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST ha= ve all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement t= he
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MU= ST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill











=
------=_Part_63400_1712838063.1413299215847-- From nobody Tue Oct 14 09:55:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1CE1A8AE9; Tue, 14 Oct 2014 09:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy4zMIfj3DFs; Tue, 14 Oct 2014 09:54:09 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9701A8AB2; Tue, 14 Oct 2014 09:54:09 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA60172E165; Tue, 14 Oct 2014 12:54:08 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 8A81E72E154; Tue, 14 Oct 2014 12:54:08 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 12:54:07 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt Thread-Index: AQHP5n3sqUqcR0TG3kyoHDqfoyksfZwwFQAA Date: Tue, 14 Oct 2014 16:54:06 +0000 Message-ID: References: <543914E8.8070507@lodderstedt.net> <54391575.9080707@lodderstedt.net> <11F6D8A7-003C-45B7-8B2D-98D8CB0EA285@oracle.com> In-Reply-To: <11F6D8A7-003C-45B7-8B2D-98D8CB0EA285@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: multipart/alternative; boundary="_000_ECC1233B12834CBD89E10568E03968C1mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/O2WO0X1AqMROCsVM7mmMxPFkU-c X-Mailman-Approved-At: Tue, 14 Oct 2014 09:55:54 -0700 Cc: "kitten@ietf.org" , "oauth@ietf.org WG" Subject: Re: [kitten] [OAUTH-WG] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:54:14 -0000 --_000_ECC1233B12834CBD89E10568E03968C1mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Phil on this one (hey, it happens!): this is a classic example= of having one piece of software and many instances of it talking to many d= ifferent service providers. Each of those pairings is going to need to agre= e on a client ID, and one would hope a client secret or equivalent. It's no= t feasible to pre-pack these even with a single authorization service (and = Google and MS are setting a bad example here), let alone every server ever.= Classical OAuth has a strong relationship between the client developer and= the protected resource provider, but this relationship starts to dissolve = when you're talking about common APIs. OpenID Connect is one such common AP= I that we're seeing in the web space (and SCIM will likely be another), but= the SASL work is going to open up a whole slew of "common" protected APIs = that could use OAuth. As such, dynamic registration is going to be essential for this to be inter= operable and scale beyond a single provider / consumer-app pair, and it mak= es perfect sense for Kitten to adopt it here. -- Justin On Oct 12, 2014, at 8:37 PM, Phil Hunt > wrote: Torsten, Big +1 to your comments. I think the SASL-OAuth work is very important work and it is the *classic* = use case for OAuth Dynamic Registration. SASL clients are typically developed independently of server implementation= and are meant to work with any server. This means that having a pre-negot= iated client_id is pretty much impossible without dyn reg or some equivalen= t solution =97 and why do another? There may be simpler profiles you can develop specific to SASL, but I think= OAuth Dyn Reg should work well for this use case. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt > wrote: Hi all, there is some discussion going on in the KITTEN WG regarding the SASL/Oauth= mechanism that might be of interest for the OAuth WG as well. kind regards, Torsten. -------- Original-Nachricht -------- Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.tx= t Datum: Sat, 11 Oct 2014 13:30:48 +0200 Von: Torsten Lodderstedt An: Kitten@ietf.org Kopie (CC): tjs@psaux.com Hi all, as one of the proposers (beside Hannes) of the change, I would like to expl= ain the rationale. > -16 is submitted, and there is one suggested change (which I was supposed= to have added in already and blew it), which is to replace section 3.2.2 w= ith the text (farther) below. My comments on the suggested text: > #1) I don't think the dynamic registration stuff is baked enough to want= to pull that in to the "oauth-configuration" definition. I don't want to p= ull it in because I don't think dynamic registration is required for SASL/O= AUTH (as evidenced by the Google and Outlook.com imple= mentations. Existing implementations at Google and Outlook.com are= no evidence against dynamic client registration. They demonstrate that it = is possible to implement the server side. But we are talking about clients (more precis= ely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking a= look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. Before I dive into the registration details, I would like to give my person= al summary why this SASL profile is needed. In my opinion, one of the main purposes of this mechanism is to allow gener= ic clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: - multi-factor authn: An increasing number of service providers (e.g. Googl= e, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjunc= tion with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a si= gnificant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process.= So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any k= ind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. - Furthermore, using OAuth also allows to use refresh tokens as persistent = credential for service login, that way eleminating the need to store user passwords on devices. So basically, the SASL OAuth profile can (at least in my opinion) be a majo= r leap forward in Internet security. Why does this require dynamic registration? Well, OAuth requires any client to possess a client_id (and client_secret) = with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credenti= als into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook,= but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. Or do you want to register the Thunderbird deveopers with every e-Mail/Cale= ndar-provider in the world up-front? I don't think so. That's why the OAuth WG came up with the specification fo= r dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization = server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall proces= s. That's why I think we must define a way for a generic SASL client to, based= on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mecha= nisms are used in concert in order to authorize service access using OAuth. Otherwise, the SASL mechanism can only be used for point to point integrati= ons among partners but never for generic clients. So I think true interoperability calls for addition of registration as well= . Regarding state of dynamic client registration: It's not ratified yet but a= lready sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments. > #2) I didn't really want to make all of the OpenID elements required but= I don't have a strong opinion here, my initial intent was to use the OpenI= D Discovery format as an existing format to be re-used here but leave it fl= exible. Agreed. Using the format as specified by OpenID Connect makes sense. As gen= eric OAuth differs from OpenID Connect, the WG should (probably in cooperat= ion with the OAuth WG) discuss, which elements are really needed. > #3) I am against recommending scope names at all in any way. I would no= t include the last sentence of paragraph 5 below and strike the scope names= . Given there is already a response parameter scope, which intructs the clien= t on what scope to use in the authz request, I tend to agree. I'm not yet f= ully convinced whether this approach will work. But let's give it a try. kind regards, Torsten. > New text for 3.2.2: > ----------------------- > 3.2.2. Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication. The error > result consists of the following values: > > > status (REQUIRED): The authorization error code. Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL): An OAuth scope which is valid to access the > service. This may be empty which implies that unscoped tokens > are required, or a scope value. If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL): The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user. The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports. The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated. In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function. Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported. Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint. This specification > RECOMMMENDs the use of the following scopes: > > imap: The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3: The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_ECC1233B12834CBD89E10568E03968C1mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <29D9299A6747334FB827DE3D32F32DF2@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I agree with Phil on this one (hey, it happens!): this is a classic example= of having one piece of software and many instances of it talking to many d= ifferent service providers. Each of those pairings is going to need to agre= e on a client ID, and one would hope a client secret or equivalent. It's not feasible to pre-pack these ev= en with a single authorization service (and Google and MS are setting a bad= example here), let alone every server ever. Classical OAuth has a strong r= elationship between the client developer and the protected resource provider, but this relationship starts to disso= lve when you're talking about common APIs. OpenID Connect is one such commo= n API that we're seeing in the web space (and SCIM will likely be another),= but the SASL work is going to open up a whole slew of "common" protected APIs that could use OAuth.

As such, dynamic registration is going to be essential for this to be = interoperable and scale beyond a single provider / consumer-app pair, and i= t makes perfect sense for Kitten to adopt it here.

 -- Justin

On Oct 12, 2014, at 8:37 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Torsten,

Big +1 to your comments.

I think the SASL-OAuth work is very important work and it is the *clas= sic* use case for OAuth Dynamic Registration.

SASL clients are typically developed independently of server implement= ation and are meant to work with any server.  This means that having a= pre-negotiated client_id is pretty much impossible without dyn reg or some= equivalent solution =97 and why do another?

There may be simpler profiles you can develop specific to SASL, but I = think OAuth Dyn Reg should work well for this use case.

Phil<= /span>

On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

there is some discussion going on in the KITTEN WG regarding the SASL/Oauth= mechanism that might be of interest for the OAuth WG as well.

kind regards,
Torsten.


-------- Original-Nachricht --------
Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
Datum: Sat, 11 Oct 2014 13:30:48 +0200
Von: Torsten Lodderstedt <torsten@lodderstedt.net>
An: K= itten@ietf.org
Kopie (CC): tjs= @psaux.com <tjs@ps= aux.com> 


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to expl=
ain the rationale.

> -16 is submitted, and there is one suggested change (which I was suppo=
sed to have added in already and blew it), which is to replace section 3.2.=
2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to w=
ant to pull that in to the "oauth-configuration" definition. I do=
n't want to pull it in because I don't think dynamic registration is requir=
ed for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outl=
ook.com are no evidence against dynamic client registration. They demon=
strate that it is possible
to implement the server side. But we are talking about clients (more precis=
ely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a=
 look at https://bugzilla.mozilla.org/show_bug.cgi?i=
d=3D849540.

Before I dive into the registration details, I would like to give my person=
al summary why this SASL profile is needed.
=20
In my opinion, one of the main purposes of this mechanism is to allow gener=
ic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Googl=
e, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunc=
tion with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a si=
gnificant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process.=
 So the authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any k=
ind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent =
credential for service login, that way eleminating the need to store user
passwords on devices.
=20
So basically, the SASL OAuth profile can (at least in my opinion) be a majo=
r leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) =
with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credenti=
als into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook,=
 but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Cale=
ndar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification fo=
r dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization =
server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall proces=
s.

That's why I think we must define a way for a generic SASL client to, based=
 on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mecha=
nisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrati=
ons among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well=
.

Regarding state of dynamic client registration: It's not ratified yet but a=
lready sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect deployments.

> #2)  I didn't really want to make all of the OpenID elements required =
but I don't have a strong opinion here, my initial intent was to use the Op=
enID Discovery format as an existing format to be re-used here but leave it=
 flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As gen=
eric OAuth differs from OpenID Connect, the WG should (probably in cooperat=
ion with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I would=
 not include the last sentence of paragraph 5 below and strike the scope na=
mes.


Given there is already a response parameter scope, which intructs the clien=
t on what scope to use in the authz request, I tend to agree. I'm not yet f=
ully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>   New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry&qu=
ot;
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill




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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_ECC1233B12834CBD89E10568E03968C1mitreorg_-- From nobody Tue Oct 14 20:00:14 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2297D1A0077 for ; Tue, 14 Oct 2014 20:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kpi12ALECnj for ; Tue, 14 Oct 2014 20:00:10 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654621A006F for ; Tue, 14 Oct 2014 20:00:08 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9F3078R005217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Oct 2014 03:00:07 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9F30502016666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Oct 2014 03:00:06 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9F304w0019771 for ; Wed, 15 Oct 2014 03:00:04 GMT Received: from [10.159.70.14] (/10.159.70.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Oct 2014 20:00:04 -0700 Message-ID: <543DE348.3040006@oracle.com> Date: Tue, 14 Oct 2014 21:00:24 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140924 Thunderbird/17.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" References: <538CFBBA.1080900@oracle.com> In-Reply-To: <538CFBBA.1080900@oracle.com> X-Forwarded-Message-Id: <538CFBBA.1080900@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VnWlCl0yFH2RsPxbdWSZ4sp71pA Subject: [kitten] IETF 91 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 03:00:12 -0000 Please provide any agenda items for the Hawaii session. Submit these topics to the list or co-chairs no later than Monday, October 27, 2014. Shawn. kitten co-chair -- From nobody Tue Oct 14 20:06:08 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895121A00C5 for ; Tue, 14 Oct 2014 20:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5C-TVND3Hdv for ; Tue, 14 Oct 2014 20:06:03 -0700 (PDT) Received: from nm36.bullet.mail.bf1.yahoo.com (nm36.bullet.mail.bf1.yahoo.com [72.30.239.5]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4261A007F for ; Tue, 14 Oct 2014 20:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413342362; bh=lX/cod5euD2n/VQe84RNuq2+epRu7cN3DpgStnFLS/o=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=BYgwln4gezm6Tpq9cHFdv4IkJ1B5G84xIjFDkQbxns96VVIL3x/kNFh6lQ4OBFfyxtRGsN0HfDYH1yRkTzm+zDN4vF26MVba3m+emVG2FeSCa4ZFI2l7tgoHYpT2RwTDhOSj/RvFQ7qo58pMs8LwqPYe0wHqsoTs+BiZBXWxnLh6Anjr+Iha8deMLLTxZmtvDeQDLzxLv5YU9eJx44Je3/IiE+/pSgLXNCe3qp9Iv5jYXT7aaugz/mG8WI0rJpEVUhLqY7ikeGRopEIhH8p+O8MwlZsnMUUG6OjmPNkQqoW5yaMGhk1/OtOLHan4nhpRBGl+lTtyufRkTTXgpQq0mQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=pKEsDxJFJpwrkqnmydxGkPiEOFKlxc4/HhWY3hy/Or8fq2RzkD4YQFkISO9f7EWNBZB4ax/FZvoRWC5d2ZZSpm1LsNWE2JZa+smL+BXq6BAplLMEiVpem4b9KpxdypNMegjg7hy9ixfzUVWXkRQkox/P26y1LBFV4pramLamfIF73mU2m4042wlOhXkokx6VMQfIONHbP2GAaANBBroKI0OAXsdkvgvsltZnGYHP7NaRW5b9HKZXWih0L732OXkmip6sSrdoUyfQldbLP7kd1M+2ar3NWlr2D3+Z6BupWDMyM77NzXJU9QeqqNYY4SuUM1TGVevbDCKJMVvg2ft8Wg==; Received: from [98.139.212.151] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 03:06:02 -0000 Received: from [98.139.212.200] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 03:06:01 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 03:06:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 893898.47396.bm@omp1009.mail.bf1.yahoo.com X-YMail-OSG: JygO5PkVM1mFuayO0_fMs7D9iCb3dLSzpOwpQmfTCQ2caLZ_jDeN9tGhAnGb2lA t_dGWIvLW3LEu6TTO_UqJ61DusgJdflAXNxBhBL.WzGxO6RK_Pdvp8zoo7_JjcJxErqg8E1RUF2. m7y9tsBF9ACwUfltek1A1GsodVYUG.fUGHs5Pg7hwzMwRwf3mjFYA7Nkgm8b6Iqwa8ZMQJo3_HD_ oaicA0pPDjNF2Hm5N9yujKyzx7MUqvKglTFGxcsfwLwA.7wplvHkjkUEI4yb_USjxslo50Bxev.Q lUXQAE05f8LioQscsddOQ2mVQ0ttJcEWu1_camznd3YHkr308dh31cAL4WxJXTp_gr0Aa0HYX4XH 9r5zZ6.5FyBgcNd8V.MVDsV.mid4.L6T4957DKTJMrfOBNxPLLMLgkaaUmWZttm8_fHIN4PAClH8 3cbmfYnGdFHsoTxEj4I5ieYWnUOW10rB.Ot2HUIhH7VyF.lbo6Q6AsiUFmwi7AERftpLDTtap Date: Wed, 15 Oct 2014 03:06:00 +0000 (UTC) From: Bill Mills To: Shawn M Emery , "kitten@ietf.org" Message-ID: <628484794.120040.1413342360910.JavaMail.yahoo@jws106138.mail.bf1.yahoo.com> In-Reply-To: <543DE348.3040006@oracle.com> References: <543DE348.3040006@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_120039_1259466646.1413342360908" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/t_AIx05aoW8CIRnymXL7iJt1rHQ Subject: Re: [kitten] IETF 91 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 03:06:06 -0000 ------=_Part_120039_1259466646.1413342360908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd like to have what is hopefully closing discussions around the one remai= ning issue for WGLC for SASL/OAUTH.=20 On Tuesday, October 14, 2014 8:00 PM, Shawn M Emery wrote: =20 =20 Please provide any agenda items for the Hawaii session.=C2=A0 Submit these= =20 topics to the list or co-chairs no later than Monday, October 27, 2014. Shawn. kitten co-chair -- _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_120039_1259466646.1413342360908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd like to have what is hopefu= lly closing discussions around the one remaining issue for WGLC for SASL/OA= UTH.


On Tuesday, October 14, 2014 8:00 PM, S= hawn M Emery <shawn.emery@oracle.com> wrote:

=

Please provide any a= genda items for the Hawaii session.  Submit these
t= opics to the list or co-chairs no later than Monday, October 27, 2014.


Shawn.
kitten co-chair
--

______________________________________________= _
Kitten mailing list
Kitten@= ietf.org
https://www.ietf.org/mailman/= listinfo/kitten


=
------=_Part_120039_1259466646.1413342360908-- From nobody Wed Oct 15 09:43:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81BC1A8A01 for ; Wed, 15 Oct 2014 09:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs5Idx6_p2VN for ; Wed, 15 Oct 2014 09:42:57 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D9A1A89FC for ; Wed, 15 Oct 2014 09:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1490; q=dns/txt; s=iport; t=1413391377; x=1414600977; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=QS/CWl0fSEGi0nQZKw8ebAZJQf52h0SIhVahi2pM6kE=; b=EOyhj9er3xQVfTh5eqiwORHycVOrsmBmE0Cx/iDJ2M5q8jYYvoZofXzd l6Kx5czifXvbSQtUJ1WCtQ2M4aO8NMPPNzBm8HoZbWHI5R9HDj3jbKudu RngecRFLSMbVpmr3kXhHw8m6vkAAmzFDxhOFStGGMTkJtpbPNDzH4Yf2f 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAGqjPlStJV2c/2dsb2JhbABbgw5TWASDAsh9h02BFxYBfYQsDwE7CgE1AgUWCwILAwIBAgFLDQEHAQGIOg2zLJUlAQEBAQEBBAEBAQEBAQEbgSyPIoJ+gVQFi2GKYoJChE+BMDyDCoJyO4l5g36CAB6BeE2BSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,725,1406592000"; d="scan'208";a="363527712" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 15 Oct 2014 16:42:56 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9FGgu8Q003425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 16:42:56 GMT Received: from [10.129.24.59] (10.129.24.59) by xhc-rcd-x02.cisco.com (173.37.183.76) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 15 Oct 2014 11:42:56 -0500 Message-ID: <543EA410.5000508@cisco.com> Date: Wed, 15 Oct 2014 10:42:56 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kitten WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.59] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tH_nlhRN8dyjR0uFQ4G9xvW9mxE Cc: Kitten Chairs Subject: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:42:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This message begins the Working Group Last Call (WGLC) of "Structure of the GSS Negotiation Loop" < draft-ietf-kitten-gss-loop-00 >. WGLC will end in two weeks, on October 29. The draft is available at: http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-00 Please review the document and send comments to the Working Gorup mailing list < kitten at itef.org > or the co-chairs < kitten-chairs at tools.ietf.org > before the end of the WGLC. Any and all comments on the document are sought in order to access the strength of consensus. Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - -- Your Kitten Chairs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUPqQQAAoJEDWi+S0W7cO1qWgH/1RZmvmiDcd/K/MpD+nAkwXY jl/c/1skuGASgui3zJpzPu1Jviw89nZx8NJwVUxp9CYJH6WL9SCoI6U5p4DyoZt8 pUL/Od6YVpAMVFfQtD0dT90e8flzyUIRkwsI9bBTLpnF/FWCBxvtVYSpVOPIakuz NkxH7e+5si3p5rbv5XuRO/fG2W0hFtdhH0whYf30Glu6azyzXXlNPM87VHapZiNf wcBRiuw8GPSsKyEuTmZaQB9CkTJlPZF0X+fFXltUodDPgGHV3LqfS80DGMnFGCbq YuPpsQdWz45W6I8uem55IF+AXTFLPs+TTEw1sHZS1xZBYyUAlHCVU9lNUvtXExg= =yXbb -----END PGP SIGNATURE----- From nobody Wed Oct 15 11:07:19 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBC01A8AFC for ; Wed, 15 Oct 2014 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfXEfCcLveva for ; Wed, 15 Oct 2014 11:07:02 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A211A8AEB for ; Wed, 15 Oct 2014 11:07:00 -0700 (PDT) Received: from [79.253.15.72] (helo=[192.168.71.80]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XeSyO-0007Wa-60; Wed, 15 Oct 2014 20:06:56 +0200 Message-ID: <543EB7C0.3020106@lodderstedt.net> Date: Wed, 15 Oct 2014 20:06:56 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bill Mills , "Kitten@ietf.org" References: <31r908v52l19r5cb7nsqiouy.1413266582842@email.android.com> <796188397.63401.1413299215858.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> In-Reply-To: <796188397.63401.1413299215858.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> Content-Type: multipart/alternative; boundary="------------040400030001000208050502" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rNUTWjTd9SkL26aWZjxDkvIg6SM Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:07:08 -0000 This is a multi-part message in MIME format. --------------040400030001000208050502 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 14.10.2014 17:06, schrieb Bill Mills: > I wasn't planning to. OpenID is already doing it basically. There > might not yet be a "here's what a well behaved generic client looks > like" draft yet, but is that really needed? I think so. > > > On Monday, October 13, 2014 11:03 PM, Torsten Lodderstedt > wrote: > > > Hi Bill, > > are you proposing to write a new "generic client" I-D/RFC in the OAuth WG? > > kind regards, > Torsten. > > > -------- Ursprüngliche Nachricht -------- > Von: Bill Mills > Datum:13.10.2014 23:05 (GMT+01:00) > An: Torsten Lodderstedt , Kitten@ietf.org > Cc: tjs@psaux.com, Hannes Tschofenig , Benjamin Kaduk > Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt > > 3 through 6 should be handled by OAuth (and OpenID?) and are outside > the scope of this spec. This spec deals with 1 and maybe 2 & 7 above). > > A generic mail/contacts/calendar client will used more than SASL > endpoints, notably CalDAV and CardDAV. This isn't the place to solve > the general problem. > > -bill > > > > On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt > wrote: > > > Hi Bill, > > Am 13.10.2014 18:08, schrieb Bill Mills: >> I totally agree that generic and interoperable OAuth client >> implementations need both endpoint discovery and client registration. >> I disagree that this spec needs registration. >> This spec is about using OAuth on resource servers which have nothing >> to do with authentication and token issuance. > > I agree these are different aspects. Does this mean they need to be > treated in different specs? What is the benefit of this approach? > > I'm not looking for a generic OAuth client. My goal is to enable the > development of generic email/calendar/xmpp ... clients, which > authorize access to the respective service using OAuth. > Such a generic client must (at most) perform the following steps in > order to get access to the resource server: > > 1) client tries to access resource server > 2) resource server refuses access and returns discovery URL > 3) client obtains metadata from discovery URL > 4) client determines its client credentials for this particular authz > server > 5) if client is not in possession of suitable client credentials -> > register with the authz server (at the registration endpoint obtained > from the discovery document) > 6) client performs authz flow with the authz server > 7) client accesses resource server again (with new access token) > > This spec currently does not specify steps 4 through 6, which means > there is no way to implement the whole process in an interoperable way > in my generic email client. I therefore suggest to add registration to > this spec in order to cover the entire process. > > Do you have an alternative proposal to achieve this goal? > >> We might need to talk about client registration requirements in a >> token profile, but this draft doesn't define new tokens either. > > There is no need to define new tokens as this is not relevant for > client/resource server interop. Resource server know the authz > server's token format (which is standard in OAuth deployments). > > kind regards, > Torsten. > > >> >> On whether to specify the full OpenID Connect Discovery schema, I >> think a SHOULD is reasonable, I don't really like the MUST. >> >> >> On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt >> wrote: >> >> >> Hi all, >> >> as one of the proposers (beside Hannes) of the change, I would like >> to explain the rationale. >> >> > -16 is submitted, and there is one suggested change (which I was >> supposed to have added in already and blew it), which is to replace >> section 3.2.2 with the text (farther) below. My comments on the >> suggested text: >> >> > #1) I don't think the dynamic registration stuff is baked enough >> to want to pull that in to the "oauth-configuration" definition. I >> don't want to pull it in because I don't think dynamic registration >> is required for SASL/OAUTH (as evidenced by the Google and >> Outlook.com implementations. >> >> >> Existing implementations at Google and Outlook.com are no evidence >> against dynamic client registration. They demonstrate that it is possible >> to implement the server side. But we are talking about clients (more >> precisely about generic clients). I'm not aware of any generic >> client implementing the SASL mechanisms in the moment. I recommend >> taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540. >> >> Before I dive into the registration details, I would like to give my >> personal summary why this SASL profile is needed. >> >> In my opinion, one of the main purposes of this mechanism is to allow >> generic clients to authorize access to standard protocols, such as IMAP, >> using OAuth Access Tokens. This offers the following advantages: >> >> - multi-factor authn: An increasing number of service providers (e.g. >> Google, Yahoo, Apple) offer 2-factor authentication to their users, >> but only for apps and web sites. Why? It currently does not work in >> conjunction with IMAP and the like. Instead, application-specific >> passwords >> must be used, which offer a terrible user experience and therefore >> are a significant burden for better Internet security. Using OAuth >> access tokens >> allows to decouple service access and authentication/authorization >> process. So the authorization server can choose the appropriate/available >> mechanisms to authenticate at its discretion. This also allows to use >> any kind of (provider-specific) multi-factor authentication methods also >> in the context of IMAP and the like. >> >> - Furthermore, using OAuth also allows to use refresh tokens as >> persistent credential for service login, that way eleminating the >> need to store user >> passwords on devices. >> >> So basically, the SASL OAuth profile can (at least in my opinion) be >> a major leap forward in Internet security. >> >> Why does this require dynamic registration? >> >> Well, OAuth requires any client to possess a client_id (and >> client_secret) with the particular authorization server. Nowadays >> developers typically >> register with the authz server's provider out of band and bake the >> credentials into the software package. This works for clients, which >> are directly programmed against a certain deployment/API, such as >> Facebook, but is inappropriate (if not unfeasible) for generic >> clients using standardized protocols, e.g. Thunderbird. >> >> Or do you want to register the Thunderbird deveopers with every >> e-Mail/Calendar-provider in the world up-front? >> >> I don't think so. That's why the OAuth WG came up with the >> specification for dynamic client registration, which allows >> the client to dynamically obtain client credentials from the >> authorization server. It basically solves the client credential >> challenge for generic >> clients, but it does integrate the registration step into an overall >> process. >> >> That's why I think we must define a way for a generic SASL client to, >> based on user-provided data, find the appropriate authorization >> server and >> register with it. I think the SASL mechanism should specify how those >> mechanisms are used in concert in order to authorize service access >> using OAuth. >> Otherwise, the SASL mechanism can only be used for point to point >> integrations among partners but never for generic clients. >> >> So I think true interoperability calls for addition of registration >> as well. >> >> Regarding state of dynamic client registration: It's not ratified yet >> but already sent to IESG for publication. >> Beside that it is already implement in existing OpenId Connect >> deployments. >> >> > #2) I didn't really want to make all of the OpenID elements >> required but I don't have a strong opinion here, my initial intent >> was to use the OpenID Discovery format as an existing format to be >> re-used here but leave it flexible. >> >> Agreed. Using the format as specified by OpenID Connect makes sense. >> As generic OAuth differs from OpenID Connect, the WG should (probably >> in cooperation with >> the OAuth WG) discuss, which elements are really needed. >> >> > #3) I am against recommending scope names at all in any way. I >> would not include the last sentence of paragraph 5 below and strike >> the scope names. >> >> >> Given there is already a response parameter scope, which intructs the >> client on what scope to use in the authz request, I tend to agree. >> I'm not yet fully >> convinced whether this approach will work. But let's give it a try. >> >> kind regards, >> Torsten. >> >> >> >> > New text for 3.2.2: >> > ----------------------- >> > 3.2.2. Server Response to Failed Authentication >> > >> > >> > For a failed authentication the server returns a JSON [RFC4627] >> > formatted error result, and fails the authentication. The error >> > result consists of the following values: >> > >> > >> > status (REQUIRED): The authorization error code. Valid error >> > codes are defined in the IANA "OAuth Extensions Error Registry" >> > specified in the OAuth 2 core specification. >> > >> > >> > scope (OPTIONAL): An OAuth scope which is valid to access the >> > service. This may be empty which implies that unscoped tokens >> > are required, or a scope value. If a scope is specified then a >> > single scope is preferred, use of a space separated list of >> > scopes is NOT RECOMMENDED. >> > >> > >> > oauth-configuration (OPTIONAL): The URL for a document following >> > the OpenID Provider Configuration Information schema, as >> > described in Section 3 of the OpenID Connect Discovery >> > [OpenID.Discovery], that is appropriate for the user. The >> > server MAY return different URLs for users from different >> > domains and a client MUST NOT cache a single returned value and >> > assume it applies for all users/domains that the server >> > suports. The returned discovery document MUST have all data >> > elements required by the OpenID Connect Discovery specification >> > populated. In addition, the discovery document MUST contain >> > the 'registration_endpoint' element to learn about the endpoint >> > to be used with the Dynamic Client Registration protocol >> > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of >> > parameters necessary for the OAuth protocol exchange to >> > function. Authorization servers MUST implement the >> > authorization code grant and other grant types MAY be >> > supported. Furthermore, authorization servers MUST implement >> > the ability to issue refresh tokens for use with native >> > applications to benefit from an abbreviated protocol exchange. >> > The use of the 'offline_access' scope, as defined in >> > [OpenID.Core] is RECOMMENDED to give clients the capability to >> > explicitly request a refresh token. >> > >> > >> > If the resource server provides a scope (as part of the element of >> > the configuration payload) then the client MUST always request >> > scoped tokens from the token endpoint. This specification >> > RECOMMMENDs the use of the following scopes: >> > >> > imap: The 'imap' scope value is used to interact with IMAP mail >> > servers. >> > >> > pop3: The 'pop3' scope value is used to interact with POP3 mail >> > servers. >> > >> > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. >> > >> > >> > >> > If the resource server provides no scope to the client then the >> > client SHOULD presume an empty scope (unscoped token) is needed. >> > >> > >> > Since clients may interact with a number of application servers, >> > such as email servers and XMPP servers, they need to have a way >> > to determine whether dynamic client registration has been performed >> > already and whether an already available refresh token can be >> > re-used to obtain an access token for the desired resource server. >> > This specification RECOMMENDs that a client uses the information in >> > the 'issue' element to make this determination. >> > ----------------------- >> > >> > >> > I think we're getting very close :) >> > >> > -bill >> >> >> >> >> >> > > > > > --------------040400030001000208050502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Am 14.10.2014 17:06, schrieb Bill Mills:
I wasn't planning to.   OpenID is already doing it basically.  There might not yet be  a "here's what a well behaved generic client looks like" draft yet, but is that really needed?

I think so.



On Monday, October 13, 2014 11:03 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi Bill,

are you proposing to write a new "generic client" I-D/RFC in the OAuth WG?

kind regards, 
Torsten. 


-------- Ursprüngliche Nachricht --------
Von: Bill Mills
Datum:13.10.2014 23:05 (GMT+01:00)
An: Torsten Lodderstedt , Kitten@ietf.org
Cc: tjs@psaux.com, Hannes Tschofenig , Benjamin Kaduk
Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

3 through 6 should be handled by OAuth (and OpenID?) and are outside the scope of this spec.  This spec deals with 1 and maybe 2 & 7 above).  

A generic mail/contacts/calendar client will used more than SASL endpoints, notably CalDAV and CardDAV.  This isn't the place to solve the general problem.   

-bill



On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi Bill,

Am 13.10.2014 18:08, schrieb Bill Mills:
I totally agree that generic and interoperable OAuth client implementations need both endpoint discovery and client registration.  I disagree that this spec needs registration. 
This spec is about using OAuth on resource servers which have nothing to do with authentication and token issuance.

I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach?

I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth.
Such a generic client must (at most) perform the following steps in order to get access to the resource server:

1) client tries to access resource server
2) resource server refuses access and returns discovery URL
3) client obtains metadata from discovery URL
4) client determines its client credentials for this particular authz server
5) if client is not in possession of suitable client credentials ->  register with the authz server (at the registration endpoint obtained from the discovery document)
6) client performs authz flow with the authz server
7) client accesses resource server again (with new access token)

This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process.

Do you have an alternative proposal to achieve this goal?

We might need to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.

There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments).

kind regards,
Torsten.



On whether to specify the full OpenID Connect Discovery schema, I think a SHOULD is reasonable, I don't really like the MUST.


On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to explain the rationale.

> -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540.

Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
 
In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user
passwords on devices.
 
So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall process.

That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well.

Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect deployments.

> #2)  I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.


Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>  New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill












--------------040400030001000208050502-- From nobody Wed Oct 15 11:46:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECD91A1B19 for ; Wed, 15 Oct 2014 11:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKOy8xv6DkIp for ; Wed, 15 Oct 2014 11:46:47 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884391A90E7 for ; Wed, 15 Oct 2014 11:46:47 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9FIkibT032533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Oct 2014 18:46:45 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9FIkhMs003772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 18:46:44 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9FIkh8X001897; Wed, 15 Oct 2014 18:46:43 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Oct 2014 11:46:41 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_118DE4D9-AE42-4D25-9224-66579AA0830D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <543EB7C0.3020106@lodderstedt.net> Date: Wed, 15 Oct 2014 11:46:40 -0700 Message-Id: <6801207E-434D-45D0-8846-6FF581F82703@oracle.com> References: <31r908v52l19r5cb7nsqiouy.1413266582842@email.android.com> <796188397.63401.1413299215858.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> <543EB7C0.3020106@lodderstedt.net> To: Torsten Lodderstadt X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-AspKwDBCvjNc1z77NhRXEhw-SM Cc: "Kitten@ietf.org" , "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:46:53 -0000 --Apple-Mail=_118DE4D9-AE42-4D25-9224-66579AA0830D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 15, 2014, at 11:06 AM, Torsten Lodderstedt = wrote: >=20 > Am 14.10.2014 17:06, schrieb Bill Mills: >> I wasn't planning to. OpenID is already doing it basically. There = might not yet be a "here's what a well behaved generic client looks = like" draft yet, but is that really needed? >=20 > I think so. >=20 >>=20 >>=20 >> On Monday, October 13, 2014 11:03 PM, Torsten Lodderstedt = wrote: >>=20 >>=20 >> Hi Bill, >>=20 >> are you proposing to write a new "generic client" I-D/RFC in the = OAuth WG? >>=20 >> kind regards,=20 >> Torsten.=20 >>=20 >>=20 >> -------- Urspr=FCngliche Nachricht -------- >> Von: Bill Mills >> Datum:13.10.2014 23:05 (GMT+01:00) >> An: Torsten Lodderstedt , Kitten@ietf.org >> Cc: tjs@psaux.com, Hannes Tschofenig , Benjamin Kaduk >> Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt >>=20 >> 3 through 6 should be handled by OAuth (and OpenID?) and are outside = the scope of this spec. This spec deals with 1 and maybe 2 & 7 above). =20= >>=20 >> A generic mail/contacts/calendar client will used more than SASL = endpoints, notably CalDAV and CardDAV. This isn't the place to solve = the general problem. =20 >>=20 >> -bill >>=20 >>=20 >>=20 >> On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt = wrote: >>=20 >>=20 >> Hi Bill, >>=20 >> Am 13.10.2014 18:08, schrieb Bill Mills: >>> I totally agree that generic and interoperable OAuth client = implementations need both endpoint discovery and client registration. I = disagree that this spec needs registration. =20 >>> This spec is about using OAuth on resource servers which have = nothing to do with authentication and token issuance. >>=20 >> I agree these are different aspects. Does this mean they need to be = treated in different specs? What is the benefit of this approach?=20 >>=20 >> I'm not looking for a generic OAuth client. My goal is to enable the = development of generic email/calendar/xmpp ... clients, which authorize = access to the respective service using OAuth. >> Such a generic client must (at most) perform the following steps in = order to get access to the resource server: >>=20 >> 1) client tries to access resource server >> 2) resource server refuses access and returns discovery URL >> 3) client obtains metadata from discovery URL >> 4) client determines its client credentials for this particular authz = server >> 5) if client is not in possession of suitable client credentials -> = register with the authz server (at the registration endpoint obtained = from the discovery document) >> 6) client performs authz flow with the authz server >> 7) client accesses resource server again (with new access token)=20 >>=20 >> This spec currently does not specify steps 4 through 6, which means = there is no way to implement the whole process in an interoperable way = in my generic email client. I therefore suggest to add registration to = this spec in order to cover the entire process.=20 >>=20 >> Do you have an alternative proposal to achieve this goal?=20 >>=20 >>> We might need to talk about client registration requirements in a = token profile, but this draft doesn't define new tokens either. >>=20 >> There is no need to define new tokens as this is not relevant for = client/resource server interop. Resource server know the authz server's = token format (which is standard in OAuth deployments).=20 >>=20 >> kind regards, >> Torsten. >>=20 >>=20 >>>=20 >>> On whether to specify the full OpenID Connect Discovery schema, I = think a SHOULD is reasonable, I don't really like the MUST. >>>=20 >>>=20 >>> On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt = wrote: >>>=20 >>>=20 >>> Hi all, >>>=20 >>> as one of the proposers (beside Hannes) of the change, I would like = to explain the rationale. >>>=20 >>> > -16 is submitted, and there is one suggested change (which I was = supposed to have added in already and blew it), which is to replace = section 3.2.2 with the text (farther) below. My comments on the = suggested text: >>>=20 >>> > #1) I don't think the dynamic registration stuff is baked enough = to want to pull that in to the "oauth-configuration" definition. I don't = want to pull it in because I don't think dynamic registration is = required for SASL/OAUTH (as evidenced by the Google and Outlook.com = implementations. >>>=20 >>>=20 >>> Existing implementations at Google and Outlook.com are no evidence = against dynamic client registration. They demonstrate that it is = possible >>> to implement the server side. But we are talking about clients (more = precisely about generic clients). I'm not aware of any generic >>> client implementing the SASL mechanisms in the moment. I recommend = taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. >>>=20 >>> Before I dive into the registration details, I would like to give my = personal summary why this SASL profile is needed. >>> =20 >>> In my opinion, one of the main purposes of this mechanism is to = allow generic clients to authorize access to standard protocols, such as = IMAP, >>> using OAuth Access Tokens. This offers the following advantages: >>>=20 >>> - multi-factor authn: An increasing number of service providers = (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their = users, >>> but only for apps and web sites. Why? It currently does not work in = conjunction with IMAP and the like. Instead, application-specific = passwords >>> must be used, which offer a terrible user experience and therefore = are a significant burden for better Internet = security. Using OAuth access tokens >>> allows to decouple service access and authentication/authorization = process. So the authorization server can choose the = appropriate/available >>> mechanisms to authenticate at its discretion. This also allows to = use any kind of (provider-specific) multi-factor authentication methods = also >>> in the context of IMAP and the like. >>>=20 >>> - Furthermore, using OAuth also allows to use refresh tokens as = persistent credential for service login, that way eleminating the need = to store user >>> passwords on devices. >>> =20 >>> So basically, the SASL OAuth profile can (at least in my opinion) be = a major leap forward in Internet security. >>>=20 >>> Why does this require dynamic registration? >>>=20 >>> Well, OAuth requires any client to possess a client_id (and = client_secret) with the particular authorization server. Nowadays = developers typically >>> register with the authz server's provider out of band and bake the = credentials into the software package. This works for clients, which >>> are directly programmed against a certain deployment/API, such as = Facebook, but is inappropriate (if not unfeasible) for generic >>> clients using standardized protocols, e.g. Thunderbird. >>>=20 >>> Or do you want to register the Thunderbird deveopers with every = e-Mail/Calendar-provider in the world up-front? >>>=20 >>> I don't think so. That's why the OAuth WG came up with the = specification for dynamic client registration, which allows >>> the client to dynamically obtain client credentials from the = authorization server. It basically solves the client credential = challenge for generic >>> clients, but it does integrate the registration step into an overall = process. >>>=20 >>> That's why I think we must define a way for a generic SASL client = to, based on user-provided data, find the appropriate authorization = server and >>> register with it. I think the SASL mechanism should specify how = those mechanisms are used in concert in order to authorize service = access using OAuth. >>> Otherwise, the SASL mechanism can only be used for point to point = integrations among partners but never for generic clients. >>>=20 >>> So I think true interoperability calls for addition of registration = as well. >>>=20 >>> Regarding state of dynamic client registration: It's not ratified = yet but already sent to IESG for publication. >>> Beside that it is already implement in existing OpenId Connect = deployments. >>>=20 >>> > #2) I didn't really want to make all of the OpenID elements = required but I don't have a strong opinion here, my initial intent was = to use the OpenID Discovery format as an existing format to be re-used = here but leave it flexible. >>>=20 >>> Agreed. Using the format as specified by OpenID Connect makes sense. = As generic OAuth differs from OpenID Connect, the WG should (probably in = cooperation with >>> the OAuth WG) discuss, which elements are really needed. >>>=20 >>> > #3) I am against recommending scope names at all in any way. I = would not include the last sentence of paragraph 5 below and strike the = scope names. >>>=20 >>>=20 >>> Given there is already a response parameter scope, which intructs = the client on what scope to use in the authz request, I tend to agree. = I'm not yet fully >>> convinced whether this approach will work. But let's give it a try. >>>=20 >>> kind regards, >>> Torsten. >>>=20 >>>=20 >>>=20 >>> > New text for 3.2.2: >>> > ----------------------- >>> > 3.2.2. Server Response to Failed Authentication >>> > >>> > >>> > For a failed authentication the server returns a JSON [RFC4627] >>> > formatted error result, and fails the authentication. The error >>> > result consists of the following values: >>> > >>> > >>> > status (REQUIRED): The authorization error code. Valid error >>> > codes are defined in the IANA "OAuth Extensions Error Registry" >>> > specified in the OAuth 2 core specification. >>> > >>> > >>> > scope (OPTIONAL): An OAuth scope which is valid to access the >>> > service. This may be empty which implies that unscoped tokens >>> > are required, or a scope value. If a scope is specified then a >>> > single scope is preferred, use of a space separated list of >>> > scopes is NOT RECOMMENDED. >>> > >>> > >>> > oauth-configuration (OPTIONAL): The URL for a document following >>> > the OpenID Provider Configuration Information schema, as >>> > described in Section 3 of the OpenID Connect Discovery >>> > [OpenID.Discovery], that is appropriate for the user. The >>> > server MAY return different URLs for users from different >>> > domains and a client MUST NOT cache a single returned value and >>> > assume it applies for all users/domains that the server >>> > suports. The returned discovery document MUST have all data >>> > elements required by the OpenID Connect Discovery specification >>> > populated. In addition, the discovery document MUST contain >>> > the 'registration_endpoint' element to learn about the endpoint >>> > to be used with the Dynamic Client Registration protocol >>> > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of >>> > parameters necessary for the OAuth protocol exchange to >>> > function. Authorization servers MUST implement the >>> > authorization code grant and other grant types MAY be >>> > supported. Furthermore, authorization servers MUST implement >>> > the ability to issue refresh tokens for use with native >>> > applications to benefit from an abbreviated protocol exchange. >>> > The use of the 'offline_access' scope, as defined in >>> > [OpenID.Core] is RECOMMENDED to give clients the capability to >>> > explicitly request a refresh token. >>> > >>> > >>> > If the resource server provides a scope (as part of the element of >>> > the configuration payload) then the client MUST always request >>> > scoped tokens from the token endpoint. This specification >>> > RECOMMMENDs the use of the following scopes: >>> > >>> > imap: The 'imap' scope value is used to interact with IMAP mail >>> > servers. >>> > >>> > pop3: The 'pop3' scope value is used to interact with POP3 mail >>> > servers. >>> > >>> > xmpp: The 'xmpp' scope value is used to interact with XMPP = servers. >>> > >>> > >>> > >>> > If the resource server provides no scope to the client then the >>> > client SHOULD presume an empty scope (unscoped token) is needed. >>> > >>> > >>> > Since clients may interact with a number of application servers, >>> > such as email servers and XMPP servers, they need to have a way >>> > to determine whether dynamic client registration has been = performed >>> > already and whether an already available refresh token can be >>> > re-used to obtain an access token for the desired resource server. >>> > This specification RECOMMENDs that a client uses the information = in >>> > the 'issue' element to make this determination. >>> > ----------------------- >>> > >>> > >>> > I think we're getting very close :) >>> > >>> > -bill >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_118DE4D9-AE42-4D25-9224-66579AA0830D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
+1

Phil

On Oct 15, 2014, at 11:06 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20

Am 14.10.2014 17:06, schrieb Bill Mills:
I wasn't planning to.   OpenID is already doing it basically.  There = might not yet be  a "here's what a well behaved generic client looks = like" draft yet, but is that really needed?

I think so.



On = Monday, October 13, 2014 11:03 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi Bill,

are you proposing to write a new "generic client" I-D/RFC in the OAuth WG?

kind regards, 
Torsten. 


-------- Urspr=FCngliche Nachricht = --------
Von: Bill Mills
Datum:13.10.2014 23:05 (GMT+01:00)
Cc: tjs@psaux.com, Hannes Tschofenig , Benjamin Kaduk
Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

3 = through 6 should be handled by OAuth (and OpenID?) and are outside the scope of this spec.  This spec deals with 1 and maybe 2 & 7 above).  

A generic mail/contacts/calendar client will used more than SASL endpoints, notably CalDAV and CardDAV.  This isn't the place to solve = the general problem.   

-bill



On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


=
Hi Bill,

Am 13.10.2014 18:08, schrieb Bill Mills:
I totally agree = that generic and interoperable OAuth client implementations need both endpoint discovery and client registration. =  I disagree that this spec needs registration.  =
This spec is about using OAuth on resource servers which have nothing to do with authentication and token issuance.

I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach?

I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth.
Such a generic client must (at most) perform the following steps in order to get access to the resource server:

1) client tries to access resource server
2) resource server refuses access and returns discovery URL
3) client obtains metadata from discovery URL
4) client determines its client credentials for this particular authz server
5) if client is not in possession of suitable client credentials = ->  register with the authz server (at the registration endpoint obtained from the discovery document)
6) client performs authz flow with the authz server
7) client accesses resource server again (with new access token)

This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process.

Do you have an alternative proposal to achieve this goal?

We might need to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.

There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments).

kind regards,
Torsten.



On whether to specify the full OpenID Connect Discovery schema, I think a SHOULD is reasonable, I don't really like the MUST.


On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to explain the = rationale.

> -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bug= zilla.mozilla.org/show_bug.cgi?id=3D849540.

Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
 
In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and = authentication/authorization process. So the authorization server can choose the = appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store = user
passwords on = devices.
 
So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.

Why does this require dynamic = registration?

Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
= are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every = e-Mail/Calendar-provider in the world = up-front?

I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall process.

That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as = well.

Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect = deployments.

> #2)  I = didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am = against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.


Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
= convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>  New text = for 3.2.2:
> = -----------------------
> 3.2.2.  = Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  = The error
= > result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid = error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An = OAuth scope which is valid to access the
> service.  = This may be empty which implies that unscoped tokens
> are required, or a scope value.  = If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The = URL for a document following
> the OpenID Provider Configuration Information schema, = as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  = The
> server MAY return different URLs for users from = different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  = The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  = In addition, the discovery document MUST contain
> the = 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration = protocol
> = [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined = in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The = 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The = 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The = 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> = -----------------------
>
>
> I think we're getting very close = :)
>
> -bill












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

= --Apple-Mail=_118DE4D9-AE42-4D25-9224-66579AA0830D-- From nobody Wed Oct 15 11:47:48 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE9F1A90D2 for ; Wed, 15 Oct 2014 11:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z33n8pf4exyb for ; Wed, 15 Oct 2014 11:47:44 -0700 (PDT) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B070E1A1B19 for ; Wed, 15 Oct 2014 11:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413398863; bh=0+wMKgEYTI+AfpVHI5E5p0tqlRqZMZbqn2zr62XymGo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=fs+Ia9D7ZWVFaZetWDAjDILvTLiCTQw2qbK0o7VPZEn7B//6l4Ogod0sW4SUklm6QcwbY6SOgyTWlOcpOnGkrooPsqJ+10w+uOO4WEqWN5hog5bAgw7FuypEHsiheRUWxCtD2nsmc2rLQExbwPxSZaIvcgD7Y90mIgswg1DsYyCTIASsIiN1GkrwCj2LifQe1d9qWJomzTkUYh5VHSkSqvE9V41Wqgs/IUT9lwwoSpUBmMGA8NqIiviZVz2FZ7SatAgIUvVHTomVXZRFGjo9aZ/FFT/WXR6A7dMgXTBMszW90HNLpMyRLegPCZkDCsdB8H85GMoA9ZsXbpXUFcdJyg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=WXePeW8Prnq3756BPPunRt8wyV6x87kySJGpSMuVYnep8WO36jzCGVT+sxMCgzCrya/GWqED70r+tH2zEe0VmRRRhssZMQeU/cA2xMuGu48D4Rfn91BnFSTig9CK3g0VmlEo8vHJUbHVXRm44v2z1L6Ht4Xf9D/OtlUU9FYHHF380ORVdHygwdkJyah4nP0GTHYDVAJob3yngwN6cfZCK5CTwCEtjfLGPLHj3REEvu+mY+apmDYeVcr8yYAaZd7fabheED3qhaedQy8o60gK5rGoSp1HpR5B7KYXV98d606bSmhHCqliW66FOWRYr8Z3jjmaeLEabVZ38GsrpnfFZg==; Received: from [98.139.215.142] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 18:47:43 -0000 Received: from [98.139.212.241] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 18:47:43 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 15 Oct 2014 18:47:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 853787.38794.bm@omp1050.mail.bf1.yahoo.com X-YMail-OSG: KKGokx0VM1mVwbEF5bni4tuTI6r7kKh50s74GotZ_AoIEODVUAB4hPArcWnqfnF YdU3lJGV60bEuzu.kVjX3Sn_E2r31ZgEYNAXT8CQo6_Tb2akaavPxzUadhmhYYUEXp62iEQhNZVx Fja0IKE0IpyIr12SbUde0JXpy5rjEDFCo75Yqe8zXqa.ZDOKQWWHLm.rzmC8k3Lai3vhRx4UwwWx hXX4vATBZyAQvoz19H9lWoS3Kvjf4YTFK.zY4rhkCr24lREIDj9flUDPbm931vBu0DDWU9i2.DQ7 1RfIvLOgecw1hRh7O8RPAlNywnGDdHoCE8uZ1qW_Ec5fwNLqUYacnKTkYZt2wYU40Divt7yrVZmH LjD9r_FkIeXuhP8DyhFHHanGBl.JY1N.WWi7JQG1mZmGEhWHGntgNXdT1mEDDlhZPPuU2a_f1Y3A lcIyhN7m5sXqKsUjINTRfrYjYJFGauZJPHRaXUT0LbTprD8UxIn07zBhrEMxLNT8_aLZQTz0TL323 Date: Wed, 15 Oct 2014 18:47:42 +0000 (UTC) From: Bill Mills To: Torsten Lodderstedt , "Kitten@ietf.org" Message-ID: <1150607927.180478.1413398863008.JavaMail.yahoo@jws10636.mail.bf1.yahoo.com> In-Reply-To: <543EB7C0.3020106@lodderstedt.net> References: <543EB7C0.3020106@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_180477_1822550183.1413398863006" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/a9WymcOcy5UWpZ0uYrOJMcGkdzg Cc: "tjs@psaux.com" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:47:46 -0000 ------=_Part_180477_1822550183.1413398863006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that wants to be a draft that's more generalto OpenID and OAuth. = =C2=A0Agreed it's a good thing. ------=_Part_180477_1822550183.1413398863006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
I think that wants to be a draft that's more generalto OpenID and OAuth.  Agreed it's a good thing.
------=_Part_180477_1822550183.1413398863006-- From nobody Thu Oct 16 12:13:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425341A87DB for ; Thu, 16 Oct 2014 12:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.791 X-Spam-Level: * X-Spam-Status: No, score=1.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyAxxFrmbswZ for ; Thu, 16 Oct 2014 12:13:27 -0700 (PDT) Received: from nm41.bullet.mail.bf1.yahoo.com (nm41.bullet.mail.bf1.yahoo.com [216.109.114.57]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E32D1A7D83 for ; Thu, 16 Oct 2014 12:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413486806; bh=ZfaSA9jVfkrATSwfGNNk9U3XvCxVUneXHQVjTBeBsmI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=jBEAQurbo00/8Y3XpLtS4itC6soMVMH+5IsKmInCfPBsmKJfwattEOORyA8hXejJAJnIQMzXdEsO5w56IvvtCUtXRjb242vL9D7cU9bKGWO5ihM1RtGVwGzoLccuLf4J61+jFr+fhU7uU+X0bCXqe10vKLZM6AIgl47dR+YzQvfEpoVAH7GzX9LOulS3DAPcP7Yaa5OJ8Ze7GN+vjVUrylRl+ScBW/vWmcHs79iTyOvifXuIHvAfdjZxy9by8/gsljgOTyjcPwKD/YkmUkodRQUR9GKw0iSV7aLP/IucFDu1M490H2g30QpxfQ/f+255wiyNBUdRwj3SEhLw5C+JsQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=d3YKsV6xGIeYYLFcjoYE0ehEfuPva/EvtBNg39H1Fw7JdLmp4KQzbENFkWEKpU4xl3Fce3f4uCLcEZt6wLTZHBGmEkcAfTc2x20UXexHtnz51X+ZaKgdiELMLwzz15FxCSAwdbqI4yXbdMZDzNTiHIrHmVuKuDgMszT33XqEouRYDLQ1SnLKXgv5ISLjiFTq1nILpcXyD78ZAn7kDlOrntA79HRCuAAIj8YR+Qb/Vya5u226GE8u75qF54bQ4lpDlFLNwfL2aLcv0xM7U6EfgYZSE2SoOf3OclXQMROfODIb5AL2O2zz07d6NTRghLC+iKaqY/goXM/ofuJpHfOa0Q==; Received: from [98.139.215.143] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2014 19:13:26 -0000 Received: from [98.139.212.226] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2014 19:13:26 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 16 Oct 2014 19:13:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 523320.18825.bm@omp1035.mail.bf1.yahoo.com X-YMail-OSG: _oaYAgAVM1n34eUPig1c8bdMRKVnyojWYt0aFUi1X0YmsVd.JI6fGJjQRJOnj02 0H7QLmETNM3tSiqbLRJH0oO_hTYn0qc915boETg05E5fGuJRnjV296Gjr2XqeUlvVb_A3jKPNJl5 LhmZMlguBxJieupnPqR.ilO0.WZcH__XZ560zcegleRS0mbMQAXbHK5kSGK7orznUa8v0YmcghMg 7kIyA_yaocSDPjVbnaMtgP74CPVK5eYdVCWz5zd5dvWkzoK8POn3kMCxAfHJAnwnYUDxkzm3H2Aq dKvdm4i.zyB4an6atUVSbyl_h9fyHjd9cAWG51PRp8fE1mzK0Q.dSYy9cK_dyN2PZ8KHmNy8freU JQje6rlnVQrKGG.vIkva1X2wHyRzbyH2bImVA66NFMi_tJ5uLsOowjj28kFWEglsc.mQKcOEPV0T UYEVVVhCgoiy..2AForLrp2ttQhuhljyqd7X.yfjs7VSKqa7naG4WXwoZQ.dqXOFATlCxS_CT1IE- Date: Thu, 16 Oct 2014 19:12:23 +0000 (UTC) From: Bill Mills To: Bill Mills , Torsten Lodderstedt , "Kitten@ietf.org" Message-ID: <346516680.91005.1413486743123.JavaMail.yahoo@jws10661.mail.bf1.yahoo.com> In-Reply-To: <1150607927.180478.1413398863008.JavaMail.yahoo@jws10636.mail.bf1.yahoo.com> References: <1150607927.180478.1413398863008.JavaMail.yahoo@jws10636.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_91004_328883782.1413486743114" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/BY4Dz9m9uqLIinZkjmEwxHfI3q4 Cc: "tjs@psaux.com" Subject: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:13:29 -0000 ------=_Part_91004_328883782.1413486743114 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Based on the discussion here I've put together softer language that gives t= he right guidance but doesn't make major normative changes in the draft. Section 1 Introduction -- second to last paragraph: Again, steps (E) and (F) are not defined in [RFC6749] (but aredescribed in,= for example, [RFC6750] for the OAuth Bearer Tokeninstead) and are the main= functionality specified within thisdocument. Consequently, the message exc= hange shown in Figure 1 is theresult of this specification. The client will= generally need todetermine the authentication endpoints (and perhaps the s= erviceendpoints) before the OAuth 2.0 protocol exchange messages in steps(A= )-(D) are executed. The discovery of the resource owner,=C2=A0authorization= server endpoints, and client registration are outside=C2=A0the scope of th= is specification. The client must discover the=C2=A0authorization endpoints= using a discovery mechanism such as OpenIDConnect Discovery [OpenID.Discov= ery] or Webfinger using host-meta[RFC7033]. =C2=A0Once credentials are obta= ined the client proceeds to steps(E) and (F) defined in this specification.= =C2=A0Authorization endpointsMAY require client registration and generic c= lients SHOULD supportthe Dynamic Client Registration protocol [I-D.ietf-oau= th-dyn-reg]. (Note: I struck "In band discovery is not tenable if clients=C2=A0support t= he OAuth 2.0 password grant.) Section 3.2.2 In the "oauth-configuration (OPTIONAL):" bullet add: (appended to/after the first paragraph) The returned discovery document SHOULD have all dataelements required by th= e OpenID Connect Discovery specificationpopulated. =C2=A0In addition, the d= iscovery document SHOULD containthe 'registration_endpoint' element to lear= n about the endpointto be used with the Dynamic Client Registration protoco= l[I-D.ietf-oauth-dyn-reg] to obtain the minimum number ofparameters necessa= ry for the OAuth protocol exchange tofunction. =C2=A0Another comparable dis= covery or client registrationmechanism MAY be used if available.=C2=A0 The use of the 'offline_access' scope, as defined in[OpenID.Core] is RECOMM= ENDED to give clients the capability toexplicitly request a refresh token. (At the end of this bullet) Since clients may interact with a number of application servers,such as ema= il servers and XMPP servers, they need to have a wayto determine whether dy= namic client registration has been performedalready and whether an already = available refresh token can bere-used to obtain an access token for the des= ired resource server.This specification RECOMMENDs that a client uses the i= nformation inthe 'issue' element to make this determination. =20 On Wednesday, October 15, 2014 11:47 AM, Bill Mills wrote: =20 I think that wants to be a draft that's more generalto OpenID and OAuth. = =C2=A0Agreed it's a good thing. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_91004_328883782.1413486743114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Base= d on the discussion here I've put together softer language that gives the r= ight guidance but doesn't make major normative changes in the draft.
<= div id=3D"yui_3_16_0_1_1413468337557_77400" dir=3D"ltr">

Section 1 I= ntroduction -- second to last paragraph:

Again, steps (E) and (F) are not defined in [RFC6749] (but are
described in, for example, [RFC6750] for the OAuth Bearer Token
instead) and are the main functionality specified within this
document. Consequently, the message exchange shown in Figure 1 is the
result of this specification. The client will generally need to
=
determine the authentication endpoints (and perhaps the service
=
endpoints) before the OAuth 2.0 protocol exchange messages in steps
(A)-(D) are executed. The discovery of the resource owner, 
authorization server endpoints, and client registration are outside&= nbsp;
the scope of this specification. The client must discover = the 
authorization endpoints using a discovery mechanism such= as OpenID
Connect Discovery [OpenID.Discovery] or Webfinger using= host-meta
[RFC7033].  Once credentials are obtained the clie= nt proceeds to steps
(E) and (F) defined in this specification. &= nbsp;Authorization endpoints
MAY require client registration and g= eneric clients SHOULD support
the Dynamic Client Registration prot= ocol [I-D.ietf-oauth-dyn-reg].

(Note: I struck "In band discovery is not tenable if clients 
support the OAuth 2.0 password grant.)



Section 3.2.2 In the "oauth-configuration (OPTIONAL):" bullet add:<= /div>

(appended to/after the first p= aragraph)

The returned discove= ry document SHOULD have all data
elements required by the OpenID C= onnect Discovery specification
populated.  In addition, the d= iscovery document SHOULD contain
the 'registration_endpoint' eleme= nt to learn about the endpoint
to be used with the Dynamic Client = Registration protocol
[I-D.ietf-oauth-dyn-reg] to obtain the minim= um number of
parameters necessary for the OAuth protocol exchange = to
function.  Another comparable discovery or client registra= tion
mechanism MAY be used if available. 

The use of the 'offline_access' scope, as define= d in
[OpenID.Core] is RECOMMENDED to give clients the capability t= o
explicitly request a refresh token.


(At the end of this bu= llet)

Since clients may inte= ract with a number of application servers,
such as email servers a= nd XMPP servers, they need to have a way
to determine whether dyna= mic client registration has been performed
already and whether an = already available refresh token can be
re-used to obtain an access= token for the desired resource server.
This specification RECOMME= NDs that a client uses the information in
the 'issue' element to m= ake this determination.



On Wednesday, October 15, 2014 11:47 A= M, Bill Mills <wmills_92105@yahoo.com> wrote:

I think th= at wants to be a draft that's more generalto OpenID and OAuth.  Agreed= it's a good thing.

____________________________= ___________________
Kitten mailing list
https://www.ietf.org/mailman/li= stinfo/kitten



------=_Part_91004_328883782.1413486743114-- From nobody Thu Oct 16 13:03:43 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A8D1A892E for ; Thu, 16 Oct 2014 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uiGlzaJZ3Fy for ; Thu, 16 Oct 2014 13:03:32 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6451A88D4 for ; Thu, 16 Oct 2014 13:03:32 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-66-54402493f75e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 11.F1.09603.39420445; Thu, 16 Oct 2014 16:03:31 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9GK3UEp018041; Thu, 16 Oct 2014 16:03:30 -0400 Received: from [18.101.8.102] (vpn-18-101-8-102.mit.edu [18.101.8.102]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9GK3Snv011104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 16:03:29 -0400 Message-ID: <5440248F.4080506@mit.edu> Date: Thu, 16 Oct 2014 16:03:27 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= , Kitten WG References: <543EA410.5000508@cisco.com> In-Reply-To: <543EA410.5000508@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrjtZxSHEoOcCv8XRzatYLD4/vM3q wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGWs3HKAveAzX8WWnlXMDYzTeboYOTkkBEwk Zp+axgRhi0lcuLeerYuRi0NIYDaTxOzpl9ghnI2MEncO32cHqRISOMIkcabPHsTmFVCT2Nlz nRXEZhFQlTh9/Q+YzSagLLF+/1YWEFtUIEziZPMtdoh6QYmTM5+AxUUE4iUm7/wDFhcWsJZ4 eGIDM8R8DYm/rfMZQWxOAU2J/d+nAcU5OJgF1CXWzxMCCTMLyEs0b53NPIFRYBaSqbMQqmYh qVrAyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMjOEhdVHcwTjikdIhRgINR iYdXI9g+RIg1say4MvcQoyQHk5Ior7KEQ4gQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4cSaAc b0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr5MyUKNgUWp6akVaZk4J QpqJgxNkOA/Q8EiQGt7igsTc4sx0iPwpRkUpcV5XkIQASCKjNA+uF5ZEXjGKA70izHsJpIoH mIDgul8BDWYCGjwx1BZkcEkiQkqqgbGYVzCvWG7loYbm3YfdBBnypq8RcitujOTbXfGo9Ncf McubXnZORyzjzvKamr1S+vN5T3Z07WuNl3fmrj3w5MCErPWC7/i5Iu4+fl/3b6nmz0v7H1oE HNQrm16bteLnx9nlC6/pejGcKeDSfinwyWGxnK/ppg/8ujeDL1SeLi//wlu49BnLLT4lluKM REMt5qLiRABQf6Vx/QIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/m_44p9p_5mXINQ9boo6mAuHgPmI Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:03:39 -0000 I am confused about the paragraph beginning "Extra security context tokens can also be emitted if...". This is not a scenario I'm familiar with. On that note, some (most?) protocols do not have a means of transmitting extra context tokens; I guess implementations of those protocols don't have to worry about receiving them, so won't need guidance. I am not convinced that "These resources may be non-local to the current process" is a realistic concern for GSS applications. The example code includes but doesn't use any asserts. GSS_C_EMPTY_BUFFER initializers might be more correct and elegant than memsets. Here are a few editorial comments: * I found this a little confusing: "For the first call to each routine in the loop, the major status code from the previous call to GSS_Init_sec_context() or GSS_Accept_sec_context() should be taken as GSS_S_CONTINUE_NEEDED." I believe this is aimed at the sanity-checking/input validation sections, which use text like "for example, if the initiator's previous call to GSS_Init_sec_context() returned GSS_S_COMPLETE." But I don't think it is really needed. * The example code contains "must not directly cause termination of the process (i.e., by errx())" in two places. I would suggest removing the parentheticals. As it stands, I have to wonder if "i.e." is being used to mean "for example," which is incorrect. * "Upon completion of security context negotiation, the initiator must verify that the values of the [...] flags from the last call to GSS_Init_sec_context() corresponding to the requested flags." This is not grammatically correct. * "avaialble" is a typo. * The document borders on overuse of parentheticals--something I have to fight in my own writing. Some of the parentheticals may be too important to be included as parentheticals; some others could probably be omitted. From nobody Thu Oct 16 13:38:19 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6771A892E for ; Thu, 16 Oct 2014 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ3eQanVzizs for ; Thu, 16 Oct 2014 13:38:15 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D6B1A897A for ; Thu, 16 Oct 2014 13:38:14 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-25-54402cb5cb05 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.96.13180.5BC20445; Thu, 16 Oct 2014 16:38:13 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9GKc76D025463; Thu, 16 Oct 2014 16:38:08 -0400 Received: from [18.101.8.102] (vpn-18-101-8-102.mit.edu [18.101.8.102]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9GKc4U7032515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 16:38:07 -0400 Message-ID: <54402CAC.3010209@mit.edu> Date: Thu, 16 Oct 2014 16:38:04 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrbtVxyHEoGGqjsXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8aNvM2PBZc6KnuUFDYyv2LsYOTkkBEwkXuxfygphi0lcuLee rYuRi0NIYDaTRMvFP2AJIYGNjBIbOsshEkeYJP7sv8ICkuAVUJN4unsFWBGLgKrE9lVfwOJs AsoS6/dvBbNFBcIkTjbfYoeoF5Q4OfMJWFxEwFji7s8bYLawgKHE8wm/GSGWOUp0NU8Em8kp 4CTRduMQG4jNLKAnseP6L1YIW16ieets5gmMArOQjJ2FpGwWkrIFjMyrGGVTcqt0cxMzc4pT k3WLkxPz8lKLdM30cjNL9FJTSjcxgkKS3UV5B+Ofg0qHGAU4GJV4eDWC7UOEWBPLiitzDzFK cjApifIqSziECPEl5adUZiQWZ8QXleakFh9ilOBgVhLhfa4BlONNSaysSi3Kh0lJc7AoifNu +sEXIiSQnliSmp2aWpBaBJOV4eBQkuA9pA3UKFiUmp5akZaZU4KQZuLgBBnOAzT8FEgNb3FB Ym5xZjpE/hSjopQ471uQhABIIqM0D64XljJeMYoDvSLMex6kigeYbuC6XwENZgIaPDHUFmRw SSJCSqqBcX2HXZbLdJHsU9pifN82frh8zYLJUn7KzHTpE3uYv7YdkXVf3OhfFuRkwRku0GBc 72FRmurKlNPnHJmtHWBT3Gzpw/ng7LZPdlUnTjN9tZvEvE6Ea/UDNU/PPSemRq6/5tTIlXwu 6P1m4yWMl7d5XOfp2L8x1T50j7bXc79La5LYP373rmdUYinOSDTUYi4qTgQA8Bf3jfQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2Uees-Kk51c_-O6cXnsUK4QMwNI Subject: Re: [kitten] draft-ietf-kitten-iakerb-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:38:18 -0000 "tickts" is a typo. "Yes, the tags start at 1" might be more professionally stated as "Note that the tag numbers start at 1." "Since the GSS-API acceptor can act as a Kerberos acceptor, it always has an associated Kerberos realm." This does not follow. To be a Kerberos acceptor, all you need are some keys to decrypt AP-REQ authenticators with. You might have keys from multiple realms. There should be guidance on what to do if the acceptor has no default realm. "(including the generic token framing of the GSSAPI-Token type from [RFC4121])" should reference RFC 2743, shouldn't it? On 10/14/2014 10:55 AM, Benjamin Kaduk wrote: > Hi all, > > I've made an update to the IAKERB document, hopefully including all the > review comments made on the -00 and -01. > > It was a manual posting by the secretariat, so there does not appear to be > an announce email about it. Here are some links: > > HTML: https://tools.ietf.org/html/draft-ietf-kitten-iakerb-02 > > diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-iakerb-02.txt > > -Ben > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Thu Oct 16 14:10:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173531A898C for ; Thu, 16 Oct 2014 14:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lM9c5qBBJtK for ; Thu, 16 Oct 2014 14:10:13 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2064A1A89A5 for ; Thu, 16 Oct 2014 14:10:10 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-9c-54403431f540 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 3A.EA.28565.13430445; Thu, 16 Oct 2014 17:10:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9GLA85A029285; Thu, 16 Oct 2014 17:10:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9GLA66H016330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Oct 2014 17:10:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9GLA5ri028162; Thu, 16 Oct 2014 17:10:05 -0400 (EDT) Date: Thu, 16 Oct 2014 17:10:05 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <346516680.91005.1413486743123.JavaMail.yahoo@jws10661.mail.bf1.yahoo.com> Message-ID: References: <1150607927.180478.1413398863008.JavaMail.yahoo@jws10636.mail.bf1.yahoo.com> <346516680.91005.1413486743123.JavaMail.yahoo@jws10661.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nrmto4hBicPEht8XRzatYLF4de8pi 8a3rOrMDs8eSJT+ZPI719LN6zJp1mCmAOYrLJiU1J7MstUjfLoErY+EhjYKVHBW/TqxnamC8 wNbFyMkhIWAi0dO7gQXCFpO4cG89UJyLQ0hgNpPEpoWLGCGcjYwSKxadh3IOMUlsOL6WGcJp YJQ4dPIHK0g/i4C2xIr5l8DmsgmoSMx8sxHI5uAQEVCXaP7uDRJmFoiXmPb5CzuILSyQK/H2 3wswm1MgXGLRzamMIDavgKPEhZuvoeYvZpToWNHMDJIQFdCRWL1/CgtEkaDEyZlPWCCGakks n76NZQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaUbmIEhS+n JO8OxncHlQ4xCnAwKvHwagTbhwixJpYVV+YeYpTkYFIS5V2j7xAixJeUn1KZkVicEV9UmpNa fIhRgoNZSYT3uQZQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJglfQ GKhRsCg1PbUiLTOnBCHNxMEJMpwHaLgvSA1vcUFibnFmOkT+FKOilDgvC0hCACSRUZoH1wtL L68YxYFeEeYNBaniAaYmuO5XQIOZgAZPDLUFGVySiJCSamCcwX/uc2Tsy813pc5NsJnUVRks emhr5bzjdv2Kh1+KdKsbrfOb8V7kFF8C6+3wa+m3Tl450HqBc2JVv7XG0dWG9RdD0xZzPFj3 pqetNSSnefF6+fO9Eib2085sir214f8LPsN9k2X55j2qLuvoaVZ9aWO5tsX1sc6Us1U9jlrV nNePXamL3OyvxFKckWioxVxUnAgAGybcTwoDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/0A4naJgNkQOAVqknC2QAJf4kqrc Cc: "Kitten@ietf.org" Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:10:16 -0000 Sorry for the long radio silence -- the thread started quickly, and I didn't get a large block of time to digest it all until just now. Torsten -- many thanks for sending out the motivation for talking about discovery. I agree that there is a real concern for getting true interoperability, but am not fully decided on where it is best to put the full description. On Thu, 16 Oct 2014, Bill Mills wrote: > Based on the discussion here I've put together softer language that > gives the right guidance but doesn't make major normative changes in the > draft. In particular, I think I would be okay with text like Bill's proposal here, noting that there will need to be discovery and registration available, and giving some guidance for how to do so, but referring to other documents rather than putting lots of detail in this document. That is, I think it is okay for this document to retain a limited scope, so long as it notes what other pieces will be required in order to implement an application that is sufficiently generic. -Ben From nobody Thu Oct 16 22:59:40 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE25D1A90C4 for ; Thu, 16 Oct 2014 22:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WjbaSiMSmwD for ; Thu, 16 Oct 2014 22:59:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F2F1A90B4 for ; Thu, 16 Oct 2014 22:59:37 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9H5xZd5006597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Oct 2014 05:59:36 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s9H5xY0K026595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Oct 2014 05:59:35 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9H5xY44009483 for ; Fri, 17 Oct 2014 05:59:34 GMT Received: from [10.159.104.40] (/10.159.104.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Oct 2014 22:59:34 -0700 Message-ID: <5440B05B.9040408@oracle.com> Date: Thu, 16 Oct 2014 23:59:55 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140924 Thunderbird/17.0.11 MIME-Version: 1.0 To: kitten@ietf.org References: <53D138AC.60702@isode.com> In-Reply-To: <53D138AC.60702@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/MXD_IbWpLwvask8qr34ExTZ7BWk Subject: Re: [kitten] Some test registrations according to draft-ietf-kitten-gssapi-extensions-iana-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 05:59:39 -0000 Could folks please review the example registry that we would like to include in the draft-ietf-kitten-gssapi-extensions-iana draft? Thanks, Shawn. -- On 07/24/14 10:47 AM, Alexey Melnikov wrote: > Shawn and I tried to register several items in the registry. > Does this look reasonable (I am less sure about the last one, so > please double check)? > > Bindings: C > Registration type: Instance > Object Type: Function > Symbol Name: gss_init_sec_context > Binding of: GSS_Init_sec_context > Constant Value/Range: N/A > Description: Create a security context by initiator > Registration Rules: N/A > Reference: RFC 2744 > Expert Reviewer: Kitten WG > Expert Review Notes: > Status: Registered > Obsoleting Reference: N/A > > Bindings: C > Registration type: Instance > Object Type: Function > Symbol Name: gss_accept_sec_context > Binding of: GSS_Accept_sec_context > Constant Value/Range: N/A > Description: Accept a security context from initiator > Registration Rules: N/A > Reference: RFC 2744 > Expert Reviewer: Kitten WG > Expert Review Notes: > Status: Registered > Obsoleting Reference: N/A > > Bindings: C > Registration type: Instance > Object Type: Context-Flag > Symbol Name: GSS_C_DELEG_FLAG > Binding of: deleg_state or deleg_req_flag > Constant Value/Range: 1 > Description: On output (if set): Delegated credentials are available > via the delegated_cred_handle > parameter of GSS_Accept_sec_context/GSS_Init_sec_context. > On input (if set): requests delegation of access rights. > Registration Rules: N/A > Reference: RFC 2744 > Expert Reviewer: Kitten WG > Expert Review Notes: > Status: Registered > Obsoleting Reference: N/A > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Fri Oct 17 08:02:57 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F631A0151 for ; Fri, 17 Oct 2014 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F29W5Hjpuwh6 for ; Fri, 17 Oct 2014 08:02:53 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7C31A01AA for ; Fri, 17 Oct 2014 08:02:53 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-e6-54412f9ca380 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id FD.FB.23365.C9F21445; Fri, 17 Oct 2014 11:02:52 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9HF2pWr019499; Fri, 17 Oct 2014 11:02:51 -0400 Received: from [18.101.8.94] (vpn-18-101-8-94.mit.edu [18.101.8.94]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9HF2ndo019182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 11:02:50 -0400 Message-ID: <54412F99.4090407@mit.edu> Date: Fri, 17 Oct 2014 11:02:49 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Shawn M Emery , kitten@ietf.org References: <53D138AC.60702@isode.com> <5440B05B.9040408@oracle.com> In-Reply-To: <5440B05B.9040408@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrjtH3zHE4PI6EYujm1exWPS9PsTu wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGVM/v+crWARc8XW2XNYGxivMHUxcnJICJhI fD5xnhnCFpO4cG89WxcjF4eQwGwmiQVvFkI5GxklLlx6CuUcZJLY/XQ6C0gLr4CaxPuNB1hB bBYBVYlLR0+AjWUTUJZYv38rWI2oQJjEyeZb7BD1ghInZz4Bi4sIWEvM3HMWzBYWyJJofLYb 7AwhAReJQy2LwGZyCmhJrNqzHqyGWUBPYsf1X6wQtrzE9rdzmCcwCsxCMnYWkrJZSMoWMDKv YpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECApVTkn+HYzfDiodYhTgYFTi4WWI cQgRYk0sK67MPcQoycGkJMp7Q8ExRIgvKT+lMiOxOCO+qDQntfgQowQHs5II768/QOW8KYmV ValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8+XpAQwWLUtNTK9Iyc0oQ0kwc nCDDeYCGd4DU8BYXJOYWZ6ZD5E8x6nK0NL3tZRJiycvPS5US5xXWBSoSACnKKM2DmwNLMa8Y xYHeEub1AxnFA0xPcJNeAS1hAlqy4jfIB8UliQgpqQZGPjauazbL8x23yDIHhrRt/di95ImR afjHx0rfTtzbcj/vY27lzXPWhUuFDp5p6eE2cjvAtF0xL1JdyKD7/4JKg5UOLpoJr0R+XF8y pbDx+tzayzGJd1ZNbNIXUzqfssaw9uviBxEeJgy/jM5dZBQsTU/ncOczLon4p22zj+Gez5Yj vxWXdecqsRRnJBpqMRcVJwIAqs4pDwwDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TYB1hFtoOR9rfM-kOm0nbV8cSCA Subject: Re: [kitten] Some test registrations according to draft-ietf-kitten-gssapi-extensions-iana-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:02:56 -0000 On 10/17/2014 01:59 AM, Shawn M Emery wrote: > Could folks please review the example registry that we would like to > include in the draft-ietf-kitten-gssapi-extensions-iana draft? I have looked at these and don't see any issues. The correspondence of GSS_C_DELEG_FLAG to RFC 2743 concepts is a little bit awkward to describe in a formal way, but the example registration seems to do a reasonable job of it. From nobody Fri Oct 17 09:19:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A241A1BA9 for ; Fri, 17 Oct 2014 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzagpJ-0wn4A for ; Fri, 17 Oct 2014 09:18:56 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB571A1B94 for ; Fri, 17 Oct 2014 09:18:55 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-ba-5441416e6258 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B5.FE.18723.E6141445; Fri, 17 Oct 2014 12:18:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9HGIshF023443; Fri, 17 Oct 2014 12:18:54 -0400 Received: from [18.101.8.94] (vpn-18-101-8-94.mit.edu [18.101.8.94]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9HGIqon015333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 12:18:53 -0400 Message-ID: <5441416B.20306@mit.edu> Date: Fri, 17 Oct 2014 12:18:51 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Rick van Rein , "kitten@ietf.org" References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> In-Reply-To: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrJvn6BhisKLD0OLo5lUsFk9f3WNz YPJYsuQnk8eGf01sAUxRXDYpqTmZZalF+nYJXBnrF19mLnghUfF2/QGWBsYfwl2MnBwSAiYS u28dZIewxSQu3FvP1sXIxSEkMJtJYv6ca0wQzkZGiUNXTrJDOAeZJC7N+sMI0sIroCKx69Yr ZhCbRUBVYsWPdawgNpuAssT6/VtZQGxRgTCJk8232CHqBSVOznwCFhcR8JX4MbUFaB0Hh7BA usTHHR4gYSEBJ4n9OxqYQMKcAs4Sz/bqgYSZBfQkdlz/xQphy0s0b53NPIFRYBaSobOQlM1C UraAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGUJiyu6jsYGw+pHSIUYCD UYmHlzHGIUSINbGsuDL3EKMkB5OSKO8BC8cQIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8v/4A lfOmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfBecgAaKliUmp5akZaZ U4KQZuLgBBnOAzR8FkgNb3FBYm5xZjpE/hSjopQ470OQhABIIqM0D64XlkZeMYoDvSLMuxCk igeYguC6XwENZgIavOI3yNXFJYkIKakGxsh7RpuNp7f9OX8u/sHT+qsSvwsU6o1fX4+eH5S7 ebvDXqUNxx+d/uVccTOEP+3v2f6Scw+mKnGH9tWYhsaYej0x3+esMD8r5vTjfHfVxMy64i4B Xc2L137mXvD2/iG5JW/PoVczFvJrfOJL4l1bHCh/UW3l1X9xp76szk09vHKd6CyrOzynjyqx FGckGmoxFxUnAgDTLT7t/gIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dZs8DkIP2kYbLSAIoUbP18XdXsE Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:18:59 -0000 On 10/11/2014 03:30 PM, Rick van Rein wrote: > I just posted a new I-D that introduces a DH subkey mechanism for Kerberos. The MIT krb5 team has a strong interest in perfect forward secrecy extensions for Kerberos, as well as paths away from the replay cache. Here are my comments on this draft: * This design uses new enctypes so that the subkey field of the AP-REQ and AP-REP can be repurposed for DH negotiation. This approach requires the KDC to keep track of which servers support the new feature, and makes secure opportunistic negotiation of DH impossible. An alternative design would use authorization data for the DH parameters--see RFC 4537 for an analog. We might still want a ticket option as a hint, since client implementations might be reluctant to add DH parameters to every AP-REQ. This design change also removes the need to abuse the RFC 3961 enctype number space, but might have a negative impact on the path away from the replay cache. * DH parameter negotiation as described in section 4.2 does not seem workable. The AP-REQ/AP-REP exchange does not allow multiple round trips. * Derivation of the RFC 3961 key from the DH value seems unspecified. PKINIT has to deal with this, so we shouldn't have to reinvent the wheel (unless the PKINIT methodology doesn't work with ECDH for some reason). * The draft uses a hybrid of ASN.1 and RFC 5246 notation for its formal type specifications. If we want to use TLS representations of DH parameters, we should stick to its notation completely. PKINIT uses ASN.1 and CMS representations instead; for the moment I will reserve judgment on which approach would be easier to implement. * Section 5 says "When requesting a principal ticket, a supporting implementation SHOULD send an KDC-REQ message including the have-kdh ticket flag." KDC-REQ messages do not contain ticket flags; they contain KDC options, which are not protected in AS-REQs. I see no reason why the client should need to indicate support for DH for the KDC to set the ticket flag, and what you describe here allows a trivial downgrade attack against the AS exchange. Editorially, the phrase "principal ticket" does not mean anything to me, and this whole discussion seems out of place in a section titled "Impact on GSS-API". * Is there a compelling reason to specify DH as well as ECDH, or would it be better to just specify ECDH? My preference is to specify only ECDH. * Is it better to allow the client to propose a wide range of ECDH parameters, or only a specific narrow set? My initial preference is to allow only a narrow set, but I don't have a lot of implementation experience backing that up. I also don't know the current state of CFRG recommendations on ECDH. Editorial review is likely premature at this point, but I did notice the following: * "usecases" -> use cases * "scenario's" -> scenarios * "A new ticket flag signals if" -> whether * "may include an optional subkey field" -> may include a subkey * "To setup" -> set up * "replay buffer" -> replay cache * jeapourdise -> jeopardize (or jeopardise if this is UK English) * inasfar -> insofar From nobody Sat Oct 18 10:26:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F7B1A896C for ; Sat, 18 Oct 2014 10:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPLeIrRfx5UI for ; Sat, 18 Oct 2014 10:26:25 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F5E1A896E for ; Sat, 18 Oct 2014 10:26:23 -0700 (PDT) Received: from [79.253.15.72] (helo=[192.168.71.80]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XfXll-0002Yl-BT; Sat, 18 Oct 2014 19:26:21 +0200 Message-ID: <5442A2BD.7070805@lodderstedt.net> Date: Sat, 18 Oct 2014 19:26:21 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bill Mills , "Kitten@ietf.org" References: <1150607927.180478.1413398863008.JavaMail.yahoo@jws10636.mail.bf1.yahoo.com> <346516680.91005.1413486743123.JavaMail.yahoo@jws10661.mail.bf1.yahoo.com> In-Reply-To: <346516680.91005.1413486743123.JavaMail.yahoo@jws10661.mail.bf1.yahoo.com> Content-Type: multipart/alternative; boundary="------------050400010608020503030608" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/hrKO6mqZnrMuyjxRaEY8Sy_-tjU Cc: "tjs@psaux.com" Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 17:26:27 -0000 This is a multi-part message in MIME format. --------------050400010608020503030608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Bill, reads like a good consensus. kind regards, Torsten. Am 16.10.2014 21:12, schrieb Bill Mills: > Based on the discussion here I've put together softer language that > gives the right guidance but doesn't make major normative changes in > the draft. > > > Section 1 Introduction -- second to last paragraph: > > Again, steps (E) and (F) are not defined in [RFC6749] (but are > described in, for example, [RFC6750] for the OAuth Bearer Token > instead) and are the main functionality specified within this > document. Consequently, the message exchange shown in Figure 1 is the > result of this specification. The client will generally need to > determine the authentication endpoints (and perhaps the service > endpoints) before the OAuth 2.0 protocol exchange messages in steps > (A)-(D) are executed. The discovery of the resource owner, > authorization server endpoints, and client registration are outside > the scope of this specification. The client must discover the > authorization endpoints using a discovery mechanism such as OpenID > Connect Discovery [OpenID.Discovery] or Webfinger using host-meta > [RFC7033]. Once credentials are obtained the client proceeds to steps > (E) and (F) defined in this specification. Authorization endpoints > MAY require client registration and generic clients SHOULD support > the Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg]. > > (Note: I struck "In band discovery is not tenable if clients > support the OAuth 2.0 password grant.) > > > > Section 3.2.2 In the "oauth-configuration (OPTIONAL):" bullet add: > > (appended to/after the first paragraph) > > The returned discovery document SHOULD have all data > elements required by the OpenID Connect Discovery specification > populated. In addition, the discovery document SHOULD contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function. Another comparable discovery or client registration > mechanism MAY be used if available. > > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > (At the end of this bullet) > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > > > > On Wednesday, October 15, 2014 11:47 AM, Bill Mills > wrote: > > > I think that wants to be a draft that's more generalto OpenID and > OAuth. Agreed it's a good thing. > > _______________________________________________ > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > > --------------050400010608020503030608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Bill,

reads like a good consensus.

kind regards,
Torsten.

Am 16.10.2014 21:12, schrieb Bill Mills:
Based on the discussion here I've put together softer language that gives the right guidance but doesn't make major normative changes in the draft.


Section 1 Introduction -- second to last paragraph:

Again, steps (E) and (F) are not defined in [RFC6749] (but are
described in, for example, [RFC6750] for the OAuth Bearer Token
instead) and are the main functionality specified within this
document. Consequently, the message exchange shown in Figure 1 is the
result of this specification. The client will generally need to
determine the authentication endpoints (and perhaps the service
endpoints) before the OAuth 2.0 protocol exchange messages in steps
(A)-(D) are executed. The discovery of the resource owner, 
authorization server endpoints, and client registration are outside 
the scope of this specification. The client must discover the 
authorization endpoints using a discovery mechanism such as OpenID
Connect Discovery [OpenID.Discovery] or Webfinger using host-meta
[RFC7033].  Once credentials are obtained the client proceeds to steps
(E) and (F) defined in this specification.  Authorization endpoints
MAY require client registration and generic clients SHOULD support
the Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg].

(Note: I struck "In band discovery is not tenable if clients 
support the OAuth 2.0 password grant.)



Section 3.2.2 In the "oauth-configuration (OPTIONAL):" bullet add:

(appended to/after the first paragraph)

The returned discovery document SHOULD have all data
elements required by the OpenID Connect Discovery specification
populated.  In addition, the discovery document SHOULD contain
the 'registration_endpoint' element to learn about the endpoint
to be used with the Dynamic Client Registration protocol
[I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
parameters necessary for the OAuth protocol exchange to
function.  Another comparable discovery or client registration
mechanism MAY be used if available. 

The use of the 'offline_access' scope, as defined in
[OpenID.Core] is RECOMMENDED to give clients the capability to
explicitly request a refresh token.


(At the end of this bullet)

Since clients may interact with a number of application servers,
such as email servers and XMPP servers, they need to have a way
to determine whether dynamic client registration has been performed
already and whether an already available refresh token can be
re-used to obtain an access token for the desired resource server.
This specification RECOMMENDs that a client uses the information in
the 'issue' element to make this determination.



On Wednesday, October 15, 2014 11:47 AM, Bill Mills <wmills_92105@yahoo.com> wrote:


I think that wants to be a draft that's more generalto OpenID and OAuth.  Agreed it's a good thing.

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




--------------050400010608020503030608-- From nobody Sun Oct 19 07:48:26 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037771A1A4B for ; Sun, 19 Oct 2014 07:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU_QuOFun2u8 for ; Sun, 19 Oct 2014 07:48:20 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43951A1A3E for ; Sun, 19 Oct 2014 07:48:19 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9JEmFuO022238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 19 Oct 2014 16:48:17 +0200 (CEST) (envelope-from rick@openfortress.nl) From: Rick van Rein Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Oct 2014 16:48:15 +0200 To: kitten@ietf.org Message-Id: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zY2z8-zRTSNBvUAapDkkS2JCIIY Subject: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 14:48:22 -0000 Hello, After a discussion on kerberos@mit.edu about the TXT records that never = made it into a standard, we realised that the recent success of DNSSEC = provides a new opportunity for this dnsname-to-realmname mapping. Below = is a proposal to that end. Title: Finding the Kerberos Realm of a Service in DNS Draft: draft-vanrein-dnstxt-krb1-00 Location: http://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/ This is part of my endeavour to move Kerberos towards realm crossover, = for which finding a service=92s realmname can be all but trivial. Any comments on this are highly appreciated! Cheers, Rick van Rein OpenFortress / ARPA2 From nobody Sun Oct 19 11:27:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6975D1A1ABC for ; Sun, 19 Oct 2014 11:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW6qpsSInXNo for ; Sun, 19 Oct 2014 11:27:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449191A1AB7 for ; Sun, 19 Oct 2014 11:27:53 -0700 (PDT) Received: from [77.12.155.181] by 3capp-gmx-bs57.server.lan (via HTTP); Sun, 19 Oct 2014 20:27:51 +0200 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Rick van Rein" Content-Type: text/html; charset=UTF-8 Date: Sun, 19 Oct 2014 19:29:37 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> Resent-Message-Id: Resent-Date: Sun, 19 Oct 2014 20:27:51 +0200 Resent-From: D.Rogers@gmx.net Resent-To: kitten@ietf.org X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:oFf/W/w4uFj5xY7v03JHsmGzRWg8l2dCuKUsmctsAso a5S4W4hsy/ukKVz72reMlbCR0K3U9dcm4aT5sbTcLIyoQhSP+9 8jX7x1MXWQ7bCSneQ07QWfcc3twfdI8loWMHQuoA8FwY1zCUdJ siwIFFrZo5ZtKe6zOT/K5EeMVd9irfco2PfYoq1k8OidX32o7F CzmxwdcE5YkwSpR/mzcXqqTYawmBBa7R8krV7mk0P+0IoSiqqR tlQKAMaIWpVw9IzDywgicPnkT2gzKBPll2GWAxz6eJx52Jtk0Z Bd6c84= X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sBxv1yxszhe6hh8sS3Al1flvCmE Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 18:27:55 -0000
Hi Rick,
 
thanks for this post.

Comment: having read the draft, it appears that a client can reliably determine in which primary realm (domain) it currently resides once your proposals are implemented. But could you add some extra narrative on how this aids you ultimate aim of cross realm trust relationship negotiation. Probably only a small addition, but it would help those of us not yet attuned to this mind-set.

Incidentally, this draft validates an idea of mine from a paper that was essentially a distillation of my Masters thesis and was subsequently published in December 2013. Namely. "The client can determine the ID-TGS by various means outside this discussion, for example it could be included in DNS information." Although this theme was not the main thrust of that paper.
 
 
Hoping to hear from you
Dean Rogers
 
 
Gesendet: Sonntag, 19. Oktober 2014 um 16:48 Uhr
Von: "Rick van Rein" <rick@openfortress.nl>
An: kitten@ietf.org
Betreff: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00
Hello,

After a discussion on kerberos@mit.edu about the TXT records that never made it into a standard, we realised that the recent success of DNSSEC provides a new opportunity for this dnsname-to-realmname mapping. Below is a proposal to that end.

Title: Finding the Kerberos Realm of a Service in DNS
Draft: draft-vanrein-dnstxt-krb1-00
Location: http://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/

This is part of my endeavour to move Kerberos towards realm crossover, for which finding a service’s realmname can be all but trivial.

Any comments on this are highly appreciated!


Cheers,

Rick van Rein
OpenFortress / ARPA2

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
From nobody Sun Oct 19 13:16:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2797A1A6F88 for ; Sun, 19 Oct 2014 13:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z_OU6YXHZ8R for ; Sun, 19 Oct 2014 13:16:02 -0700 (PDT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01641A6F7F for ; Sun, 19 Oct 2014 13:16:01 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9JKFsKB034092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 19 Oct 2014 22:15:55 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein X-Priority: 3 In-Reply-To: Date: Sun, 19 Oct 2014 22:15:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CFEB4F6-5EB4-4442-9A79-7BE8A2163E6F@openfortress.nl> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> To: D.Rogers@gmx.net X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/_vrRJVSpp2fvW1Hp5NB9pTbQ8DM Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 20:16:04 -0000 Hi Dean, > having read the draft, it appears that a client can reliably determine = in which primary realm (domain) it currently resides once your proposals = are implemented. But could you add some extra narrative on how this aids = you ultimate aim of cross realm trust relationship negotiation. Probably = only a small addition, but it would help those of us not yet attuned to = this mind-set. Below is the rationale that you ask for, but my experience is that = =93visions=94 in drafts are a source of criticism, because they are too = vague for the IETF process. There are two sides to how I think realm crossover can be achieved; only = the first is serviced by draft-vanrein-dnstxt-krb1-00: 1) Client software usually finds a server=92s DNS-name from a URL or a = NAI or similar. So it knows the host or domain name of the service; and = being a specific protocol client, it also knows the Kerberos name for = the service it is trying to use. What is missing is the realm name to = use with service. Current implementations rely on local/static settings = for that on the client machine and/or the KDC. The TXT records proposed = here enable the client to at least know what realm to ask for. 2) KDC software (or libkrb5) may then be requested to contact a realm = that it has not encountered before. It could use its PKINIT certificate = to authenticate as a client to the remote KDC, otherwise using the = normal PKINIT exchange, to get a cross-realm krbtgt. The parties may = validate the PKINIT certificates through DANE and DNSSEC. The shared = secret between the parties may be created with PKINIT's Diffie-Hellman = exchange, so it has Perfect Forward Secrecy. The second part is likely to raise policy questions (under what = conditions to trust a remote realm) and may introduce a need for = =93reliability levels=94, but it helps that Kerberos is only about = authentication, not authorisation. The potential result is very good; = it makes Kerberos authentication possible between domains that have not = explicitly been coupled. > "The client can determine the ID-TGS by various means outside this = discussion, for example it could be included in DNS information.=94 Yes, and setting such things in DNS are advised on = http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Mappin= g-Hostnames-onto-Kerberos-Realms but at the same time the advise is not to rely on such things from = unsecure DNS. My I-D simply proposes a way to reliably extract the = information from DNS, using DNSSEC to reliably authenticate the data = found. Thanks for your response, Rick van Rein OpenFortress= From nobody Mon Oct 20 06:35:57 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288761A874C for ; Mon, 20 Oct 2014 06:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.693 X-Spam-Level: ** X-Spam-Status: No, score=2.693 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxrBVGIEgaz5 for ; Mon, 20 Oct 2014 06:35:52 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE141A87AF for ; Mon, 20 Oct 2014 06:32:50 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9KDWk05005719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Oct 2014 15:32:47 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EF2CBFC0-BEF6-4314-A85F-51DE512F15F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Rick van Rein In-Reply-To: <5441416B.20306@mit.edu> Date: Mon, 20 Oct 2014 15:32:44 +0200 Message-Id: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pODPzmK0wn3GruWJzalfXBJ6-oU Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 13:35:55 -0000 --Apple-Mail=_EF2CBFC0-BEF6-4314-A85F-51DE512F15F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Greg, Thank you very much for your detailed feedback. I agree with most, but a few of your remarks are not immediately clear. > * This design uses new enctypes so that the subkey field of the AP-REQ > and AP-REP can be repurposed for DH negotiation. This is a surprise =97 you probably view my use of the subkey field as a protocol squeezed into it, whereas I see it as (half) a key traveling in = the one field that seems to be destined for that purpose. Am I wrong, or = just looking at the same thing in a different manner? > This approach requires > the KDC to keep track of which servers support the new feature, and > makes secure opportunistic negotiation of DH impossible. Opportunism is possible; a client can just send an attempt and hope for the best; but a MITM may reject it and cause the client to downgrade to skip its PFS desire. The have-kdh flag exists, and is stored along with other ticket policy settings, to indicate that such a downgrade = indicates a problem. I am open to suggestions to approach this in another way. As long as a MITM between client and server is not able to suppress PFS. > An alternative > design would use authorization data for the DH parameters--see RFC = 4537 > for an analog. We might still want a ticket option as a hint, since > client implementations might be reluctant to add DH parameters to = every > AP-REQ. This design change also removes the need to abuse the RFC = 3961 > enctype number space, but might have a negative impact on the path = away > from the replay cache. So, you are proposing to use the authorization-data as a generic =93typed = hole=94 , and ignore the name and descriptions that hint towards other uses. I = suppose this largely depends on the view whether the proposal abuses the subkey = field. But I don=92t see how this could work; authorization-data is part of the = enc-part, which is encrypted in a key known to KDC and the endpoint for which the ticket is destined. So it would not be possible for the client and = service to create a DH-based key between the two of them. The subkey is located in the Authenticator, which is constructed by the = client and the service as part of the AP-REQ and AP-REP messaging. This means that a subkey may be set by these parties, without involving the KDC, = and that is the distribution of decryption power that I am hoping to = establish. Don=92t hesitate to correct me if my reading of the specs is wrong! > * DH parameter negotiation as described in section 4.2 does not seem > workable. The AP-REQ/AP-REP exchange does not allow multiple round = trips. I didn=92t realise. Negotiation is a luxoury item, so it is no problem = to remove it. TLS can do without it, so there ought to be no real inconvenience. > * Derivation of the RFC 3961 key from the DH value seems unspecified. > PKINIT has to deal with this, so we shouldn't have to reinvent the = wheel > (unless the PKINIT methodology doesn't work with ECDH for some = reason). Indeed. I am still in the conceptual phase :) but will add this of = course. I agree that PKINIT is a good source for reuse. > * The draft uses a hybrid of ASN.1 and RFC 5246 notation for its = formal > type specifications. If we want to use TLS representations of DH > parameters, we should stick to its notation completely. PKINIT uses > ASN.1 and CMS representations instead; for the moment I will reserve > judgment on which approach would be easier to implement. Yes; you caught the traces from my learning process, which started out = from the intention to create a TLS-KDH mode, and which made it logical to do a similar thing in Kerberos itself. In retrospect, I agree that this is = not the best description. And, since TLS already has to deal with both syntaxes / representations, that has no decisive impact; ASN.1 is = probably a good form for this indeed, as it overlaps Kerberos5 and TLS. My one concern is that all the private key variables that are available to both Kerberos5 and TLS will be present. I shall fix this. > * Section 5 says "When requesting a principal ticket, a supporting > implementation SHOULD send an KDC-REQ message including the have-kdh > ticket flag." KDC-REQ messages do not contain ticket flags; they > contain KDC options, which are not protected in AS-REQs. I see no > reason why the client should need to indicate support for DH for the = KDC > to set the ticket flag, and what you describe here allows a trivial > downgrade attack against the AS exchange. I think I read that the KDC will never return flags that were not = requested as flags / options in the request. Are you saying that the KDC should = be specified to always set the have-kdh ticket flag for supporting = principals, without being asked for it? > Editorially, the phrase > "principal ticket" does not mean anything to me, and this whole > discussion seems out of place in a section titled "Impact on GSS-API=94.= OK. > * Is there a compelling reason to specify DH as well as ECDH, or would > it be better to just specify ECDH? My preference is to specify only = ECDH. Hardly =97 I=92m only trying to not force a decision. If most of us = want to drop =93Primal=94 DH then I=92d love to go that way. Playing around on keylength.com, the RFC 3766 requirements demand 256 bit sym.keys to be matched by 15489 bit Primal DH keys (other = estimations require 3000-ish bits). I=92m fairly certain nobody wants to send such = keys from their software. Mind you, this is for protection up to the year 2245, which we=92re not = yet zooming in on. But if nobody pleas for Primal DH, then I agree it can = go. > * Is it better to allow the client to propose a wide range of ECDH > parameters, or only a specific narrow set? My initial preference is = to > allow only a narrow set, but I don't have a lot of implementation > experience backing that up. I also don't know the current state of = CFRG > recommendations on ECDH. Opinions are welcome. I am hesitant to put down very specific requirements in a document that may live for a long time. Some things are best left to the daily routine of building. A mid-way could be to = state a few algorithms as =93current=94 algorithms, that is at the time of = publication. The future should be free to develop any way it needs to, I think. > Editorial review is likely premature at this point, but I did notice = [=85] Thank you! Best wishes, -Rick --Apple-Mail=_EF2CBFC0-BEF6-4314-A85F-51DE512F15F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlRFDv8ACgkQFBGpwol1RgbglwCeMboLcBhhuorsWajXvdKmzyLc 4TkAn2vKocLYnwxJsnXfixkJsTd3xjrU =vifu -----END PGP SIGNATURE----- --Apple-Mail=_EF2CBFC0-BEF6-4314-A85F-51DE512F15F6-- From nobody Mon Oct 20 09:12:39 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0191A03A5 for ; Mon, 20 Oct 2014 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM0lbn10-S-7 for ; Mon, 20 Oct 2014 09:12:31 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822D11A0047 for ; Mon, 20 Oct 2014 09:12:28 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-02-5445346bc71d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 71.07.13180.B6435445; Mon, 20 Oct 2014 12:12:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9KGCQoV000437; Mon, 20 Oct 2014 12:12:26 -0400 Received: from [18.100.8.65] ([18.100.8.65]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9KGCO7K025436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 12:12:25 -0400 Message-ID: <54453468.6000005@mit.edu> Date: Mon, 20 Oct 2014 12:12:24 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Rick van Rein References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6noptt4hpisH2tqMXRzatYLJ6+usfm wOSxZMlPJo8N/5rYApiiuGxSUnMyy1KL9O0SuDJOHzrMVLBfu2LeuV/MDYyPlboYOTkkBEwk rrTeYoawxSQu3FvP1sXIxSEkMJtJoqm7gRXC2cgosf7kXXaQKiGBlUwSr6Yqg9i8AmoS65tW g8VZBFQltq1pYwOx2QSUJdbv38oCYosKhEmcbL7FDlEvKHFy5hOwuIiAhsTnX1OB6jk4mAXU JXbuZgYxhQXSJT7u8IBYO4lRovPTa0aQOKeAs8TSA+YgncwCehI7rv9ihbDlJZq3zmaewCg4 C8mCWUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyM4eF2UdzD+ Oah0iFGAg1GJh3eHmUuIEGtiWXFl7iFGSQ4mJVHei0auIUJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeBVUgHK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8y4yBGgWL UtNTK9Iyc0oQ0kwcnCDDeYCGZ4HU8BYXJOYWZ6ZD5E8xKkqJ85qDJARAEhmleXC9sOTyilEc 6BVhXh+QKh5gYoLrfgU0mAlo8OcNLiCDSxIRUlINjLLPOwV8WwTP2YT2Xiue9TJR/HXGIl2O fXNz95xY9iVmqeCK04XuO0JlPvnP1NCbdk2uTDdK7Rzj1Y95L+e9k3lo+3zutG6pTe6rlHay fRHSaRSbnFE9t2lJSE/Knr2lBv1VLY3bavz2L4xQfPJ/uqLwuQMfHLvOfVKSnXHVNKlzCsPl hEM33iuxFGckGmoxFxUnAgB+gEpYCQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZqLzwhMYTcffWhJOH-huxc0q5tU Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:12:35 -0000 On 10/20/2014 09:32 AM, Rick van Rein wrote: >> * This design uses new enctypes so that the subkey field of the AP-REQ >> and AP-REP can be repurposed for DH negotiation. > > This is a surprise — you probably view my use of the subkey field as a > protocol squeezed into it, whereas I see it as (half) a key traveling in the > one field that seems to be destined for that purpose. Am I wrong, or just > looking at the same thing in a different manner? There's nothing objectively wrong with repurposing the subkey field, but that is definitely what is going on. "Half a key" (or more accurately, material needed to negotiate a key via DH or ECDH) is not the same as an RFC 3961 key. For an example of the difference, note that in your proposed protocol the AP-REP must be encrypted in the ticket session key even though the AP-REQ contained a subkey field. >> This approach requires >> the KDC to keep track of which servers support the new feature, and >> makes secure opportunistic negotiation of DH impossible. > > Opportunism is possible; a client can just send an attempt and hope for > the best; but a MITM may reject it and cause the client to downgrade to > skip its PFS desire. The have-kdh flag exists, and is stored along with > other ticket policy settings, to indicate that such a downgrade indicates > a problem. As you say, trying it and downgrading is not secure--and is also impossible since AP-REP/AP-REQ doesn't allow multiple round trips. Relying on KDC configuration is not opportunistic. Thus, secure opportunistic negotiation is impossible under this proposal. > So, you are proposing to use the authorization-data as a generic “typed hole” , > and ignore the name and descriptions that hint towards other uses. I suppose > this largely depends on the view whether the proposal abuses the subkey field. RFC 4537 also uses authorization-data as a typed hole. There is lots of precedent for this in the Kerberos protocol, though more often with padata than with authdata. I am not making any argument from elegance; I am only discussing deployment properties. Requiring the KDC to keep track of server software capabilities is not friendly to deployment. (This requirement is already present in Kerberos whenever a new RFC 3961 enctype is introduced. But we should not multiply the issue if we don't have to.) > But I don’t see how this could work; authorization-data is part of the enc-part, > which is encrypted in a key known to KDC and the endpoint for which the > ticket is destined. So it would not be possible for the client and service to > create a DH-based key between the two of them. There is an authorization-data field in Authenticator. It is used by RFC 4537. There is no authorization-data field in AP-REP or EncAPRepPart, so the DH response would have to be shoehorned into subkey, or we would have to extend EncAPRepPart with a new ASN.1 field. I would prefer extending the ASN.1 sequence, but there are arguments both ways. We do have precedent for extending an ASN.1 sequence with knowledge that the other party supports the extension: we added encryped padata to EncKDCRepPart in RFC 6806. Regardless, at this point the server knows that the client supports DH, so the choice does not affect any deployment properties. >> * Section 5 says "When requesting a principal ticket, a supporting >> implementation SHOULD send an KDC-REQ message including the have-kdh >> ticket flag." KDC-REQ messages do not contain ticket flags; they >> contain KDC options, which are not protected in AS-REQs. I see no >> reason why the client should need to indicate support for DH for the KDC >> to set the ticket flag, and what you describe here allows a trivial >> downgrade attack against the AS exchange. > > I think I read that the KDC will never return flags that were not requested > as flags / options in the request. Are you saying that the KDC should be > specified to always set the have-kdh ticket flag for supporting principals, > without being asked for it? Short answer: yes, if we wind up using a have-kdc ticket flag in the final protocol. I am not sure what you read. RFC 4120 section 2 states, "Most flags may be requested by a client when the ticket is obtained; some are automatically turned on and off by a Kerberos server as required." This flag would be in the latter category. The same section states, "With the exception of the INVALID flag, clients MUST ignore ticket flags that are not recognized," so there is no compatibility issue with the KDC setting a new flag without indication of client support. > Hardly — I’m only trying to not force a decision. If most of us want to > drop “Primal” DH then I’d love to go that way. I have heard this called "Integer DH." I have nothing to add to your comments on this, except to note that NIST curves vs. Curve25519 and similar may also become an issue. While I am responding, I have more to say on the issue of reply cache avoidance. The initial proposal states that a server does not need to use a replay cache if it sees an AP-REQ with a DH Authenticator, because it knows that any server using that Authenticator cannot help but create a unique subkey in its response. Unfortunately, this is not enough; a server also needs to know that any server using the Authenticator will actually use the subkey to protect the data stream, and that it won't accept messages from the client transmitted using the ticket session key. From nobody Mon Oct 20 11:18:10 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271BB1A87A9 for ; Mon, 20 Oct 2014 11:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8SwlYPwjfda for ; Mon, 20 Oct 2014 11:18:03 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A727D1A8AF6 for ; Mon, 20 Oct 2014 11:16:59 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-d2-5445519a4eea Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 50.8E.09603.A9155445; Mon, 20 Oct 2014 14:16:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9KIGvmg016827; Mon, 20 Oct 2014 14:16:57 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9KIGtej014559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Oct 2014 14:16:56 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9KIGs0a003363; Mon, 20 Oct 2014 14:16:54 -0400 (EDT) Date: Mon, 20 Oct 2014 14:16:54 -0400 (EDT) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <54453468.6000005@mit.edu> Message-ID: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrTsr0DXE4MA+EYujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGX8mLaUreA8S8WU7zvYGxhvMncxcnJICJhI dH3fyAZhi0lcuLceyObiEBKYzSSxrO0nlLORUeLO1fvMEM4hJomtp/6xQDgNjBJ/Vs9iBeln EdCWmLBwFzuIzSagIjHzDcRcEQENic+/pgLZHBzMAm4Sf39xg4SFBdIldh7ZwgRicwqoSzzc 8BXM5hVwlDi14QcjxPy1jBJ7e6aDJUQFdCRW75/CAlEkKHFy5hMwm1lAS2L59G1QtqPE1tmr GScwCs1CUjYLSdksJGULGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBAU3 u4vqDsYJh5QOMQpwMCrx8O4wcwkRYk0sK67MPcQoycGkJMp73M81RIgvKT+lMiOxOCO+qDQn tfgQowQHs5IIr4IKUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYL3 fgBQo2BRanpqRVpmTglCmomDE2Q4D9DwFpAa3uKCxNzizHSI/ClGXY6Wpre9TEIsefl5qVLi vAtAigRAijJK8+DmwJLSK0ZxoLeEeeeCVPEAExrcpFdAS5iAlnze4AKypCQRISXVwJi01qgw uoV3Z+9SNvnf5w+ezCqd7S994MnMkgW3vPw/caYsD0n/lhuTGS97RUbD95Xh6nW72jLiGuKv V5cwNlX+qpSS/WiTe8DFWnSn4KL5a84c7to79SeTxfz5//7Pnfs4We4bx4mNfdMqv8/8ZXLH SXDt/zOBq1erNdzZvn3mZD/XN+XZ2aVKLMUZiYZazEXFiQCnhQCxJQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/HEvhA--Wd89rg86vDVvl-gpKcHo Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:18:07 -0000 Are there any places where extension could put DH parameters other than the subkey field and dedicated authdata? It will be good to get forward secrecy for kerberos, but we should make sure to do a full anaylsis before we choose what path to follow. Some minor things: I would probably want to tweak the introduction a bit, regarding use cases across the Internet being "extreme", and being used "mainly" on intranets. I also understand that "Perfect Forward Secrecy" is something of a term of art, but prefer just "Forward Secrecy" as being perhaps more accurate. -Ben From nobody Mon Oct 20 11:48:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97B81A9085 for ; Mon, 20 Oct 2014 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHpqXR9U56An for ; Mon, 20 Oct 2014 11:47:56 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6E81A9073 for ; Mon, 20 Oct 2014 11:47:50 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-02-544558d52ab9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 4C.EC.27750.5D855445; Mon, 20 Oct 2014 14:47:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9KIlhPd023968; Mon, 20 Oct 2014 14:47:43 -0400 Received: from [18.100.8.65] ([18.100.8.65]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9KIlfiV026587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 14:47:42 -0400 Message-ID: <544558CC.8050709@mit.edu> Date: Mon, 20 Oct 2014 14:47:40 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Benjamin Kaduk , Rick van Rein References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nons1wjXE4NV+aYujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGV8urqWueCYSMWPXX+ZGxgfC3QxcnJICJhI zGnvZoewxSQu3FvP1sXIxSEkMJtJYuPh5awQzkZGiSvnfzCCVAkJrGSSeHPFHMTmFVCT2D3t JFicRUBV4uz2PawgNpuAssT6/VtZQGxRgTCJk8232CHqBSVOznwCFhcR8JB482cyUD0HB7OA usTO3cwgprBAusTHHR4Qax8zSmxc+JANpJxTwEniTPtKsFZmAT2JHdd/sULY8hLNW2czT2AU nIVkwywkZbOQlC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mil5pSuokRFL6ckjw7 GN8cVDrEKMDBqMTDu8PMJUSINbGsuDL3EKMkB5OSKO//UNcQIb6k/JTKjMTijPii0pzU4kOM EhzMSiK8CipAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd66cKBG waLU9NSKtMycEoQ0EwcnyHAeoOFzQGp4iwsSc4sz0yHypxgVpcR5xUESAiCJjNI8uF5YennF KA70ijBvAkgVDzA1wXW/AhrMBDT48wYXkMEliQgpqQZG7ylt762SbfceaGt71LFy7hdh7uOZ WgUqp6/esju+LZrZqv/CoTUzP1855VbFLForsH8WS5zbRIV3pRdyk6IqDq2KZOrhSuk2UX+U E1FbtlEmPLTShM04ijVla1pge67AvopP3/hX1l6a+TZ1YvkRo7d/ovYJfftUUWgs4vxId9XE CUdX+vUpsRRnJBpqMRcVJwIAr3Hg5goDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pe080HiDkxhnUoxd9fCQcCX1nQ4 Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:47:58 -0000 On 10/20/2014 02:16 PM, Benjamin Kaduk wrote: > Are there any places where extension could put DH parameters other than > the subkey field and dedicated authdata? It will be good to get forward > secrecy for kerberos, but we should make sure to do a full anaylsis before > we choose what path to follow. There are no other fields which look appropriate, so I think the only other option is extending the AP-REQ or Authenticator ASN.1 sequences--most likely Authenticator, so the attacker can't downgrade by stripping out the extra field. We generally do not extend RFC 4120 ASN.1 sequences without an indication of support by the other party; those sequences are not marked as extensible, so an implementation is within its rights to throw a decoding error--although I think existing implementations tend to just ignore the extra fields. Rick's proposal does contain an indication of support, but since the indication of support comes from a third party, we need to worry about graceful recovery in case it's wrong. Here's what happens in each of the three options if the client tries to use it against an old server: * Repurposed subkey: old servers won't recognize the new enctype and will respond with an error (I think a generic error because the only appropriate specific code is scoped to the KDC for some reason). * Authenticator authdata in an IF-RELEVANT container: old servers will ignore the authdata and will respond using the subkey (or ticket session key if no subkey was specified) without doing DH. The client can take this as a secure indication that the server doesn't actually support DH. * Extended ASN.1 sequence: theoretically, servers might throw a decoding error and discard the request without an error response. In practice, servers will ignore the new field and will respond using the subkey or ticket session key, which the client can take as a secure indication that the server doesn't support DH (assuming it was the Authenticator sequence which was extended). As I mentioned previously, the last time we wanted to extend the AP-REQ exchange (for enctype negotiation, RFC 4537), we used the authenticator authdata. I wasn't involved in that decision, but the reasoning seems sound. Extending Authenticator also poses some implementation issues for MIT krb5. When we added encrypted padata (RFC 6806), we extended the public krb5_enc_kdc_rep_part structure because it didn't appear in any public APIs. krb5_authenticator does appear in a few public APIs; we might still be able to get away with extending the structure, but it's less clear. From nobody Tue Oct 21 01:38:33 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378251A01F9 for ; Tue, 21 Oct 2014 01:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUUWvyTlAq0g for ; Tue, 21 Oct 2014 01:38:29 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3431F1A03A6 for ; Tue, 21 Oct 2014 01:31:23 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9L8VIio017030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Oct 2014 10:31:19 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <544558CC.8050709@mit.edu> Date: Tue, 21 Oct 2014 10:31:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37912FFA-7C0A-4CCB-9F97-C757EC8794D8@openfortress.nl> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> <544558CC.8050709@mit.edu> To: Benjamin Kaduk , Greg Hudson X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sG7KbZFgQ-39Vb1oBIF_YqRfKo8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 08:38:31 -0000 Hi, >> Are there any places where extension could put DH parameters other = than >> the subkey field and dedicated authdata? It will be good to get = forward >> secrecy for kerberos, but we should make sure to do a full anaylsis = before >> we choose what path to follow. >=20 > There are no other fields which look appropriate, so I think the only > other option is extending the AP-REQ or Authenticator ASN.1 > sequences--most likely Authenticator, so the attacker can't downgrade = by > stripping out the extra field. I am closing in on this option too, using AD-IF-RELEVANT as a signed but easily ignored extension. It means that opportunistic connection attempts will work, and that no unsigned errors can be inserted by an attacker to force a downgrade. Pros: - opportunistic KRB5-KDH - no need for a ticket flag have-kdh - KDC does not need to change - administrator does not need to administer have-kdh flags Cons: - perform a DH calculation on every outgoing attempt - possible complexity due to pregenerated DH and/or reuse of unused DH - still need to find a location for the DH response =97 subkey could = work > * Repurposed subkey: old servers won't recognize the new enctype and > will respond with an error (I think a generic error because the only > appropriate specific code is scoped to the KDC for some reason). So this automatically leads to renegotiation, which isn=92t possible, = and so to the have-kdh flag stored in the KDC; also because the error is not signed and so not trustworthy. > * Authenticator authdata in an IF-RELEVANT container: old servers will > ignore the authdata and will respond using the subkey (or ticket = session > key if no subkey was specified) without doing DH. The client can take > this as a secure indication that the server doesn't actually support = DH. Discussed above. > * Extended ASN.1 sequence: theoretically, servers might throw a = decoding > error and discard the request without an error response. In practice, > servers will ignore the new field and will respond using the subkey or > ticket session key, which the client can take as a secure indication > that the server doesn't support DH (assuming it was the Authenticator > sequence which was extended). This one involves the most redefinition work, and provides the least certainty of backward compatibility. > As I mentioned previously, the last time we wanted to extend the = AP-REQ > exchange (for enctype negotiation, RFC 4537), we used the = authenticator > authdata. I wasn't involved in that decision, but the reasoning seems > sound. Pragmatic, yes. > Extending Authenticator also poses some implementation issues for MIT > krb5. When we added encrypted padata (RFC 6806), we extended the = public > krb5_enc_kdc_rep_part structure because it didn't appear in any public > APIs. krb5_authenticator does appear in a few public APIs; we might > still be able to get away with extending the structure, but it's less = clear. Sounds like a FUD scenario in getting it adopted; and we need both ends = to support DH to get it going. My money is on the authorization_data in the AP-REQ authenticator, and on the subkey in the AP-REP message. Thanks, -Rick= From nobody Tue Oct 21 03:13:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB2E1A026A for ; Tue, 21 Oct 2014 03:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.093 X-Spam-Level: ** X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv6TCLFl7hCl for ; Tue, 21 Oct 2014 03:13:25 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9581A01AA for ; Tue, 21 Oct 2014 03:13:24 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9LADKlx088864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Oct 2014 12:13:21 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: Date: Tue, 21 Oct 2014 12:13:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EMrphplgVbgd8ryNgYqy1gR_0ZY Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 10:13:26 -0000 Hello Benjamin, > I would probably want to tweak the introduction a bit, regarding use = cases > across the Internet being "extreme", and being used "mainly" on = intranets. I removed these parts, as they don=92t add much but fluff. I changed it = to: Kerberos5 lends itself well to infrastructure-supported mutual authentication. It also provides facilities to authenticate across = realm boundaries, in which case the control over the network infrastructure = used is often distributed. In such distributed-control scenario's, it is attractive to=85 > I also understand that "Perfect Forward Secrecy" is something of a = term of > art, but prefer just "Forward Secrecy" as being perhaps more accurate. No problem, it=92s the same AFAIK. Will change in the next version. Thanks, -Rick= From nobody Tue Oct 21 04:01:48 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FE51A0636 for ; Tue, 21 Oct 2014 04:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.093 X-Spam-Level: ** X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amZWOdIP_gd4 for ; Tue, 21 Oct 2014 04:01:45 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2611A1A12 for ; Tue, 21 Oct 2014 04:01:12 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9LB18rx070661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Oct 2014 13:01:09 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <54453468.6000005@mit.edu> Date: Tue, 21 Oct 2014 13:01:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <036EFA82-1165-40EE-B05D-1B0D5B2F65B7@openfortress.nl> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oMdPYd2lUl-yrMyOkiXF0w8VO2k Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 11:01:46 -0000 Hello Greg and others, 1. Replay cache avoidance 2. Security implications > While I am responding, I have more to say on the issue of reply cache > avoidance. The initial proposal states that a server does not need to > use a replay cache if it sees an AP-REQ with a DH Authenticator, = because > it knows that any server using that Authenticator cannot help but = create > a unique subkey in its response. Unfortunately, this is not enough; a > server also needs to know that any server using the Authenticator will > actually use the subkey to protect the data stream, and that it won't > accept messages from the client transmitted using the ticket session = key. This was indeed specified; does the following text address your concern? After both AP-REQ and AP-REP have been processed, and their joint = meaning in the table above indicates that a shared secret can be constructed, = then both parties MUST derive that shared secret and continue to communicate = using that, employing the encryption type specified in the AP-REQ message's subkey = field, notably the etype2 subtype. The one thing not covered here is replay of the AP-REP; but the will not = yield the same AP-REQ and not the same DH-session-key if the server generates a = fresh DH offer for each AP-REP, so the continued application protocol cannot = be replayed. Therefore, I see no risk of falsely accepting a session. The fact that an AP-REQ is produced for mutual authentication could have = two security drawbacks that I can see: * The server might become an oracle of some kind; though nothing = specific can be asked; the ap-options seems to be open for variation but it = hardly seems interesting; the ticket is a variable spot, and perhaps multiple requests with other tickets could be used to establish access for those tickets. * The server could become the target of a DoS attack on computational power, by making it compute lots and lots of DH offers. The permissible time window for AP-REQ acceptance defines how long such an attack could last; this time would also max out the distribution time in case = of a DDoS attack, which constrains that risk to tightly connected bots. = There is no risk of an amplification-type attack on bandwidth because AP-REQ is not (much) bigger than AP-REP; both include the DH offer. -Rick= From nobody Tue Oct 21 14:49:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D261A87C1 for ; Tue, 21 Oct 2014 14:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU353tXnu7uX for ; Tue, 21 Oct 2014 14:49:20 -0700 (PDT) Received: from nm45-vm7.bullet.mail.bf1.yahoo.com (nm45-vm7.bullet.mail.bf1.yahoo.com [216.109.115.78]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFAA51A87C9 for ; Tue, 21 Oct 2014 14:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413928157; bh=Kd9GGdQM6xKQeC4zGUjtybnTPxIJu0sEi9Q50CB2/o8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=IQRA6Pw/Z+sBX7znH/z1P9B68asoDv877XHd9eXdDvS3JSJyrGOKBvZ5Qct4rCTX+CLM13Em71NYWZAGRc8uFFoQE0uqaXJCWkLFexYQFLrYrfHkYPZXWoJvKLCRMMz0uhstHadRX+JBu4bKSskTVxxL2mfnzpYugFMqxy7EkkI75NVPj/ifLgvTijIPzbSSHB+tmNIeuDGVdi4s/kXzaarh0Pa5SiTL0UoR6t4N54bggq2EGObCRF2qOigDYuoFSdpkvlL2qxMFW+BXM7R9DgpR/2RcEtbe4e7+dbbuj5XaWE1wL8ZCDEB51CiYExyddVtbDquur6rmNwTMvSOWBA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=LMZODwqj4dyMCX4rOMshPB2q86HIeq3ErEUX9E469neA4i3wQfbhgDddBhOWAEgE5Pxntiec5FLwTqFG4s+Uh9lduWRqk0N7snz02x8pseEfsJVwiH0BxXm5MKidkTA25ONZH6e2FO0+bZX45JuBhMYGMyPh2kqMAFueQz+Wl6Wd7ju896lMQSzomIma4MZzQr00Y5ttKG98hudUrfW0aUVg+Lm8VwCILfG5a6i5fhCnr19n90PNvyUgZ3lmHnaWxA2cBz7mRJSc3EtRaBUnINFeqfcoAlW7IPyfR/DCSQ3Za+SHz4ZnA9lDZJysoS2tZB5msIhd8ggc77z0OZyyHw==; Received: from [98.139.215.140] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2014 21:49:17 -0000 Received: from [98.139.212.209] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2014 21:49:17 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 21 Oct 2014 21:49:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 771083.3872.bm@omp1018.mail.bf1.yahoo.com X-YMail-OSG: JgGquM0VM1mJ82ovpSts1Ke0HEeMMhkWXUk64_cLAeOBEBVJih2363QtyckbQ6k k5I8bHxt.agJygFjL0VWGx6ilgGX6PgDaLscT5YDXVrDb0a_pwKa3mhpKB6aGOFqy.KzCfEdgS2f T7upNrGeiHADNS.60jDqUqXvcozy2RWrxS5ELoLBSYeLQAkCAyE1mZ5tAX9HitU6ovEnpcxAIMG6 oFlgLOfPJ6tenYT5XHKwo4RwbOC3pR.4_n98HoEoMDIA5kTzXEdeMFd_TSgWcJCB6eNiXLe_7ua4 AYCiH9jT4SW6it5kZhfwlbr7qIB8S9gR1OIPkZDtrMnJz.lTHV4KVr6pPZwDZ1MDuOlDTw3bC.U6 FdA9NmaOm6OcBsy2PrWLPERhac8dzHdpBx9g3W03XwSRjnZ1GzUe8qPcbUv.abS4_e5ZJVw1J52C SXHSy5dWyVz8M2eqH0LlkZH1._2Ozz6rZ6fT3XFTS0V4jh25nUEVZF91.lUcRe8Qsf8G81gUQ Date: Tue, 21 Oct 2014 21:49:16 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <1994964853.467969.1413928156697.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_467968_202668909.1413928156693" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/L8DlyeLSo2FRlEq6EGk56LI6bZc Cc: "Kitten@ietf.org" Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:49:21 -0000 ------=_Part_467968_202668909.1413928156693 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Based on this and Torsten's apparent +1 should I put out a new draft? Thanks, -bill=20 On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk = wrote: =20 Sorry for the long radio silence -- the thread started quickly, and I didn't get a large block of time to digest it all until just now. Torsten -- many thanks for sending out the motivation for talking about discovery.=C2=A0 I agree that there is a real concern for getting true interoperability, but am not fully decided on where it is best to put the full description. On Thu, 16 Oct 2014, Bill Mills wrote: > Based on the discussion here I've put together softer language that > gives the right guidance but doesn't make major normative changes in the > draft. In particular, I think I would be okay with text like Bill's proposal here, noting that there will need to be discovery and registration available, and giving some guidance for how to do so, but referring to other documents rather than putting lots of detail in this document.=C2=A0 = That is, I think it is okay for this document to retain a limited scope, so long as it notes what other pieces will be required in order to implement an application that is sufficiently generic. -Ben ------=_Part_467968_202668909.1413928156693 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on this and Torsten's app= arent +1 should I put out a new draft?

Thanks,

-bill<= /div>


=
On Thursday, October 16, 2014 2:10 PM, Benjamin Kad= uk <kaduk@MIT.EDU> wrote:


Sorry for the long radio silence -- the thread started qui= ckly, and I
didn't get a large block of time to digest it= all until just now.

Torsten -- many t= hanks for sending out the motivation for talking about
di= scovery.  I agree that there is a real concern for getting true
interoperability, but am not fully decided on where it is best = to put the
full description.

On Thu, 16 Oct 2014= , Bill Mills wrote:

> Based on the = discussion here I've put together softer language that
&g= t; gives the right guidance but doesn't make major normative changes in the=
> draft.


I= n particular, I think I would be okay with text like Bill's proposal
here, noting that there will need to be discovery and registrat= ion
available, and giving some guidance for how to do so,= but referring to
other documents rather than putting lot= s of detail in this document.  That
is, I think it i= s okay for this document to retain a limited scope, so
lo= ng as it notes what other pieces will be required in order to implement
an application that is sufficiently generic.

-Ben


<= /html> ------=_Part_467968_202668909.1413928156693-- From nobody Tue Oct 21 16:14:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3FB1A8826 for ; Tue, 21 Oct 2014 16:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLjgSCf1A0-w for ; Tue, 21 Oct 2014 16:14:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8551A87DB for ; Tue, 21 Oct 2014 16:14:36 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9LNEXfO029664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Oct 2014 23:14:34 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s9LNEXq1020326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2014 23:14:33 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9LNEWYT020295 for ; Tue, 21 Oct 2014 23:14:32 GMT Received: from [10.159.70.10] (/10.159.70.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Oct 2014 16:14:32 -0700 Message-ID: <5446E8ED.6070200@oracle.com> Date: Tue, 21 Oct 2014 17:14:53 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140924 Thunderbird/17.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" References: <1994964853.467969.1413928156697.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com> In-Reply-To: <1994964853.467969.1413928156697.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com> Content-Type: multipart/alternative; boundary="------------050900050909060706050900" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/earD1OIVpRHPzozSEwnSe8u6H1g Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:14:45 -0000 This is a multi-part message in MIME format. --------------050900050909060706050900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/21/14 03:49 PM, Bill Mills wrote: > Based on this and Torsten's apparent +1 should I put out a new draft? I've volunteered to be the shepherd for this document and I have not yet submitted this draft to the IESG. So feel free to rev the draft, but I think the changes would justify another WGLC. This is based on the assumptions of what is not in scope for this draft. Shawn. -- kitten co-chair > On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk > wrote: > > > Sorry for the long radio silence -- the thread started quickly, and I > didn't get a large block of time to digest it all until just now. > > Torsten -- many thanks for sending out the motivation for talking about > discovery. I agree that there is a real concern for getting true > interoperability, but am not fully decided on where it is best to put the > full description. > > On Thu, 16 Oct 2014, Bill Mills wrote: > > > Based on the discussion here I've put together softer language that > > gives the right guidance but doesn't make major normative changes in the > > draft. > > > In particular, I think I would be okay with text like Bill's proposal > here, noting that there will need to be discovery and registration > available, and giving some guidance for how to do so, but referring to > other documents rather than putting lots of detail in this document. That > is, I think it is okay for this document to retain a limited scope, so > long as it notes what other pieces will be required in order to implement > an application that is sufficiently generic. > > -Ben > > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------050900050909060706050900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/21/14 03:49 PM, Bill Mills wrote:
Based on this and Torsten's apparent +1 should I put out a new draft?

I've volunteered to be the shepherd for this document and I have not yet submitted this draft to the IESG.  So feel free to rev the draft, but I think the changes would justify another WGLC.  This is based on the assumptions of what is not in scope for this draft.

Shawn.
--
kitten co-chair
On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:


Sorry for the long radio silence -- the thread started quickly, and I
didn't get a large block of time to digest it all until just now.

Torsten -- many thanks for sending out the motivation for talking about
discovery.  I agree that there is a real concern for getting true
interoperability, but am not fully decided on where it is best to put the
full description.

On Thu, 16 Oct 2014, Bill Mills wrote:

> Based on the discussion here I've put together softer language that
> gives the right guidance but doesn't make major normative changes in the
> draft.


In particular, I think I would be okay with text like Bill's proposal
here, noting that there will need to be discovery and registration
available, and giving some guidance for how to do so, but referring to
other documents rather than putting lots of detail in this document.  That
is, I think it is okay for this document to retain a limited scope, so
long as it notes what other pieces will be required in order to implement
an application that is sufficiently generic.

-Ben 





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

--------------050900050909060706050900-- From nobody Tue Oct 21 17:52:49 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A91E1A88CF for ; Tue, 21 Oct 2014 17:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TerMjTW1O1Ib for ; Tue, 21 Oct 2014 17:52:46 -0700 (PDT) Received: from nm41-vm9.bullet.mail.bf1.yahoo.com (nm41-vm9.bullet.mail.bf1.yahoo.com [216.109.114.138]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868081A88C6 for ; Tue, 21 Oct 2014 17:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413939165; bh=BPrIimgOkJFXBhUZnb/RMjth2TtDlu6CCrOJqnSAhys=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=HdWLdCm7+V3TcqamnTpECNHHRJ8F+dlCEPpQJ+b9u28tROIiylI8lL7t/q+ue9b1iKmmU2Zz5Zt4FTpzW299AFgmLa8UVlUeEdsAFoo7akisa0zSn0sgPdWmLg/h2YwS/PdUu69vRU1OemQUoWY1Hsdf91wMSY9DPusTelUEUwv7nLZxsRbTbOmesfXYhehR7/Hx5+9ZAuZZr5bvlDIoKN0DHKseLQ4YCb/3iyIb5MFRfjR6cyb3B9QSqzRUvWu5cshT9Jw0LAQDWVG9gbSN+lfNIguwWSFWxp+cxOF+rGgJMInh1QM9SrmEY7VVZzuifKCXnb5dP733HxQNHIz2Dg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=K61/lm87U9zFvAtqzM4yLtQYJOkeSlMx4EOAw9cCIzpT0XQizSOghmlX4ghG0nMjW+0ksqWe6DctGhOtKG5tfqEFisAZXWGSX5AFETlMNpNxEtWjVwgdcot+NyRrAybtnxNlA73TBFJn5qXL9haCJHyXDiFJXbBFj0DI7J4Uu3Mq+5YbGjervXPOY6sPjL1aj+CdTS4+utrCoYqoZDyR+Hzjxl/Be3EOrU+xtLozbzZbCakP2fTdv2Qe9IfffcdEWYWpxE9hzeG6AVNZjiXo2slpTXrkrhTUS3DjkSatY6JAvE5WCPePK3bVeTdFuKIi029UqumDB+E7s9QwN3/cpw==; Received: from [98.139.212.149] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2014 00:52:45 -0000 Received: from [98.139.215.253] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2014 00:52:45 -0000 Received: from [127.0.0.1] by omp1066.mail.bf1.yahoo.com with NNFMP; 22 Oct 2014 00:52:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 732580.25528.bm@omp1066.mail.bf1.yahoo.com X-YMail-OSG: 9W75VzcVM1nA8Oc4cuB8Hxbq2lOeb53JCyCfm1483cwSKdjbk8BHTbjKlrJoVum qRQ3fKnZ3E5hVsrt9XWZEKWX3AMzLWf7DuefN29JDT38K6DhpONGBBvQMxphQ0fXyVQh_JyRGR_i AEAD6sJhKHN5s60jnmBw60Z6573BtCcX_P4dvEc4G6MrwiAWTQRKw94738dAheuQGFFbuhygxP1_ sSgWIaiOUwT3MIDIKL5oVuOAikldN6oFrKRjEYqPU6_LvnUDTrjtCnQPy.6Wfq9Y4pmG1tl8wzoo Wg_NJMi5hV6yLzg4r3SXKYaRZbzmnzox78IwL3B7zZgHRHZ2R1uxjZ.swGVwOfqUZSrH7NZhhHYr Z7NATBgkkyhsIRIvc9BBWS_gwDSy7FZStuP43pcAEW9nfGf8Wm7tSxAuTNxvESTLhqXrCfcAzbZH bNDf.LkZNPy2H5BLnhdcOhIwsXMt_TQWovgWO7UFDK2VEb4K_QDb1zU5oFhd179Zx0NgzR5ps Received: by 66.196.81.114; Wed, 22 Oct 2014 00:52:45 +0000 Date: Wed, 22 Oct 2014 00:52:44 +0000 (UTC) From: Bill Mills To: Shawn M Emery , "kitten@ietf.org" Message-ID: <450288760.45834.1413939164862.JavaMail.yahoo@jws10666.mail.bf1.yahoo.com> In-Reply-To: <5446E8ED.6070200@oracle.com> References: <5446E8ED.6070200@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_45833_1921124152.1413939164855" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UzlyPUbkaTGZpXpS2Hdc7Mr9XP0 Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:52:48 -0000 ------=_Part_45833_1921124152.1413939164855 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable how does the inclusion of working drafts rather than finished drafts affect= the process? =C2=A0Inclusion of the dynamic registration stuff would do th= at.=20 On Tuesday, October 21, 2014 4:23 PM, Shawn M Emery wrote: =20 On 10/21/14 03:49 PM, Bill Mills wrote: =20 Based on this and Torsten's apparent +1 should I put out a new draft? =20 =20 I've volunteered to be the shepherd for this document and I have not yet s= ubmitted this draft to the IESG.=C2=A0 So feel free to rev the draft, but I= think the changes would justify another WGLC.=C2=A0 This is based on the a= ssumptions of what is not in scope for this draft. =20 Shawn. -- kitten co-chair =20 On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk wrote: =20 =20 Sorry for the long radio silence -- the thread started quickly, and I didn't get a large block of time to digest it all until just now. =20 Torsten -- many thanks for sending out the motivation for talking about discovery.=C2=A0 I agree that there is a real concern for getting true interoperability, but am not fully decided on where it is best to put the full description. =20 On Thu, 16 Oct 2014, Bill Mills wrote: =20 > Based on the discussion here I've put together softer language that > gives the right guidance but doesn't make major normative changes in the > draft.=20 =20 In particular, I think I would be okay with text like Bill's proposal here, noting that there will need to be discovery and registration available, and giving some guidance for how to do so, but referring to other documents rather than putting lots of detail in this document.=C2=A0= That is, I think it is okay for this document to retain a limited scope, so long as it notes what other pieces will be required in order to implement an application that is sufficiently generic. =20 -Ben=20 =20 =20 =20 =20 _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten =20 =20 =20 _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_45833_1921124152.1413939164855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
how does the inclusion of working drafts rather than finished drafts affect the process?  Inclusion of the dynamic registration stuff would do that.


On Tuesday, October 21, 2014 4:23 PM, Shawn M Emery <shawn.emery@oracle.com> wrote:


On 10/21/14 03:49 PM, Bill Mills wrote:
Based on this and Torsten's apparent +1 should I put out a new draft?

I've volunteered to be the shepherd for this document and I have not yet submitted this draft to the IESG.  So feel free to rev the draft, but I think the changes would justify another WGLC.  This is based on the assumptions of what is not in scope for this draft.

Shawn.
--
kitten co-chair

On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:


Sorry for the long radio silence -- the thread started quickly, and I
didn't get a large block of time to digest it all until just now.

Torsten -- many thanks for sending out the motivation for talking about
discovery.  I agree that there is a real concern for getting true
interoperability, but am not fully decided on where it is best to put the
full description.

On Thu, 16 Oct 2014, Bill Mills wrote:

> Based on the discussion here I've put together softer language that
> gives the right guidance but doesn't make major normative changes in the
> draft.


In particular, I think I would be okay with text like Bill's proposal
here, noting that there will need to be discovery and registration
available, and giving some guidance for how to do so, but referring to
other documents rather than putting lots of detail in this document.  That
is, I think it is okay for this document to retain a limited scope, so
long as it notes what other pieces will be required in order to implement
an application that is sufficiently generic.

-Ben 





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


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


------=_Part_45833_1921124152.1413939164855-- From nobody Tue Oct 21 18:04:51 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2AF1A88DE for ; Tue, 21 Oct 2014 18:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcshrrDAoMyE for ; Tue, 21 Oct 2014 18:04:48 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C852A1A88D6 for ; Tue, 21 Oct 2014 18:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413939887; bh=csDCRQAfO9t5RyW3qKPT6cMeFEZknsK2QDOdatWZPvU=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=aLd99e5E7yPt+JDSfih61YwytDKviXSlplk9RkECQsI6+Ypec826LGqGFhyIe50pPSifh6PY+rCoA5ycUJ0hxPik0uFQFSTUhH7QpTCicnSWMG1c3ZQod5opWAIFeKsjrsjW2SaOlEG2M1KkbOd6tYxHp/MKpyhB/t4LSvT0bOAfMO2hLWBGvFqLwrHFmihEEapX2eaI2gEXTEEHQ+oy4DCtAtrh4Jeba7AF3Tq7zOZFXXPuGGjnGciHCZoGdOGp+CYS4ZhazeTAOeILkjDmkuzpBfLMK5dXgvjwa8WlxYX8bAFDOsKgBvfe2Q0KCmIBAoY3Ux0mBoe4M57lvbgEAA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=LiZuvVwuw+2swBXfW/AnLb4Avdx/xCU3Zy2z0BPbDBzfr40i9yYnwatUzsJaH/+Z9fdnY9g/NHf76TAYGJqoyTSdP7gkSuAYT7lUIQqawbdgt94PR7Yrf24esuWi+GCTtSf+evrQHgDsnn25jrSbDe1x4XFLGJZDq7jTpit06YXjJ2Oc+Lzc29Nytn7XIkMS7AtydghH0cTUW7XKvmGg4jRWcxT6VilsZETpYuZ8GBblTp5PXj831v7EJGyQr3OF2kaufF5iMGwMXkCtZI3X2zhlLxHEeP4i2SjxHVnpe8RBs6GiSZS6GC5ypnViGr2bvSAg5IrJJ7YEuvgGjK7uLg==; Received: from [66.196.81.173] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2014 01:04:47 -0000 Received: from [98.139.212.204] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2014 01:04:47 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 22 Oct 2014 01:04:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 11102.60814.bm@omp1013.mail.bf1.yahoo.com X-YMail-OSG: PLmCE.kVM1m83DzqdjPXUATkLZtCzQm01v9jBnnNFfM9M5vdoDLqs78Kc3ls8x_ ko0O0RcifhJesCK31fLGCgbJQqBEzTFTW1zzp2qynGZef.KY4dm53Ostm7X9dKxluyU5PAxhRDDg yIz7oGZd318RBKpIBgErhkif1CQkf3IWGJ7lhAJnsayHIdA8VYEif76mnis5zU_.ve1k1AOIRPkG _Ge90eu3HXmP6C47TYmo12aBabxTNqvvADyP4QoWsIzF2nMpn0HNBwZhabBn2lhqmzMne1FeBk2W qRHbqDzM9l8YVc4qP6ySAI4y5unSRezGkPujgqb_2skWUf7lRWNmyy9oZkH8F6Xy663m.6JYZB_8 0M6wYnzfHx5nIZl59hrkvoVR4SSZWK4pRKHsx1HVLrSk32gLJT.JTjQTXskgxuq.kSuS50ksYwJ6 AvV9MKqPvthJrvTzJ2Ov0t5XfXV8VxWvy4Em45yP6xqvg5Lzq3r2ZMCKBenGTVBGPed9kybm3 Received: by 66.196.80.149; Wed, 22 Oct 2014 01:04:46 +0000 Date: Wed, 22 Oct 2014 01:04:45 +0000 (UTC) From: Bill Mills To: Shawn M Emery , "kitten@ietf.org" Message-ID: <1500139212.495410.1413939886061.JavaMail.yahoo@jws106113.mail.bf1.yahoo.com> In-Reply-To: <5446E8ED.6070200@oracle.com> References: <5446E8ED.6070200@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_495409_1671220060.1413939886053" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4X-o9MKtxn7KO1E69-Q2j_3H5eo Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 01:04:50 -0000 ------=_Part_495409_1671220060.1413939886053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do you have any opinion on the changes?=20 On Tuesday, October 21, 2014 4:23 PM, Shawn M Emery wrote: =20 On 10/21/14 03:49 PM, Bill Mills wrote: =20 Based on this and Torsten's apparent +1 should I put out a new draft? =20 =20 I've volunteered to be the shepherd for this document and I have not yet s= ubmitted this draft to the IESG.=C2=A0 So feel free to rev the draft, but I= think the changes would justify another WGLC.=C2=A0 This is based on the a= ssumptions of what is not in scope for this draft. =20 Shawn. -- kitten co-chair =20 On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk wrote: =20 =20 Sorry for the long radio silence -- the thread started quickly, and I didn't get a large block of time to digest it all until just now. =20 Torsten -- many thanks for sending out the motivation for talking about discovery.=C2=A0 I agree that there is a real concern for getting true interoperability, but am not fully decided on where it is best to put the full description. =20 On Thu, 16 Oct 2014, Bill Mills wrote: =20 > Based on the discussion here I've put together softer language that > gives the right guidance but doesn't make major normative changes in the > draft.=20 =20 In particular, I think I would be okay with text like Bill's proposal here, noting that there will need to be discovery and registration available, and giving some guidance for how to do so, but referring to other documents rather than putting lots of detail in this document.=C2=A0= That is, I think it is okay for this document to retain a limited scope, so long as it notes what other pieces will be required in order to implement an application that is sufficiently generic. =20 -Ben=20 =20 =20 =20 =20 _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten =20 =20 =20 _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_495409_1671220060.1413939886053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Do you have any opinion on the changes?


On Tuesday, October 21, 2014 4:23 PM, Shawn M Emery <shawn.emery@oracle.com> wrote:


On 10/21/14 03:49 PM, Bill Mills wrote:
Based on this and Torsten's apparent +1 should I put out a new draft?

I've volunteered to be the shepherd for this document and I have not yet submitted this draft to the IESG.  So feel free to rev the draft, but I think the changes would justify another WGLC.  This is based on the assumptions of what is not in scope for this draft.

Shawn.
--
kitten co-chair

On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:


Sorry for the long radio silence -- the thread started quickly, and I
didn't get a large block of time to digest it all until just now.

Torsten -- many thanks for sending out the motivation for talking about
discovery.  I agree that there is a real concern for getting true
interoperability, but am not fully decided on where it is best to put the
full description.

On Thu, 16 Oct 2014, Bill Mills wrote:

> Based on the discussion here I've put together softer language that
> gives the right guidance but doesn't make major normative changes in the
> draft.


In particular, I think I would be okay with text like Bill's proposal
here, noting that there will need to be discovery and registration
available, and giving some guidance for how to do so, but referring to
other documents rather than putting lots of detail in this document.  That
is, I think it is okay for this document to retain a limited scope, so
long as it notes what other pieces will be required in order to implement
an application that is sufficiently generic.

-Ben 





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


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


------=_Part_495409_1671220060.1413939886053-- From nobody Tue Oct 21 19:50:02 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160F41A8A6C for ; Tue, 21 Oct 2014 19:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35yUIXCeUxil for ; Tue, 21 Oct 2014 19:49:59 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 21AE21A8A6B for ; Tue, 21 Oct 2014 19:49:57 -0700 (PDT) X-AuditID: 12074422-f79436d000000c21-68-54471b543d8d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 33.10.03105.45B17445; Tue, 21 Oct 2014 22:49:56 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9M2ntIu011736; Tue, 21 Oct 2014 22:49:56 -0400 Received: from [18.101.8.130] (vpn-18-101-8-130.mit.edu [18.101.8.130]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9M2nr1A027247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 22:49:54 -0400 Message-ID: <54471B4C.3000808@mit.edu> Date: Tue, 21 Oct 2014 22:49:48 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Rick van Rein References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> <036EFA82-1165-40EE-B05D-1B0D5B2F65B7@openfortress.nl> In-Reply-To: <036EFA82-1165-40EE-B05D-1B0D5B2F65B7@openfortress.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrRsi7R5isOWMosXRzatYLJ6+usfm wOSxZMlPJo8N/5rYApiiuGxSUnMyy1KL9O0SuDL271zEVPCVs+LLsV72BsY/7F2MnBwSAiYS O9e2s0LYYhIX7q1n62Lk4hASmM0k8f7XFSYIZyOjxKIDG9khnCNMEjtaV7OBtPAKqEncereQ BcRmEVCV2Lf5HTOIzSagLLF+/1awuKhAmMTJ5lvsEPWCEidnPgGLiwhoSHz+NRVoDgcHs4C6 xM7dzCCmsEC6xMcdHhCrnjBKvLh7E6yVU8BZYsbBC2DjmQX0JHZc/8UKYctLNG+dzTyBUXAW kg2zkJTNQlK2gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6pXm5miV5qSukmRlAAs7so7WD8 eVDpEKMAB6MSD+8MDvcQIdbEsuLK3EOMkhxMSqK8xTxAIb6k/JTKjMTijPii0pzU4kOMEhzM SiK8FZxAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd4YKaBGwaLU 9NSKtMycEoQ0EwcnyHAeoOHJIDW8xQWJucWZ6RD5U4yKUuK8rZJACQGQREZpHlwvLMG8YhQH ekWYtwSknQeYnOC6XwENZgIa/HmDC8jgkkSElFQDo3Mhw4q6bx2lcubbVlTyT7sn9vDvFrOn S4zepJ9Nmnirsnr1++VvFrscOPH+bKDOI54ZUemSKb8N1ZpYwtYfc2+PdHKXyXhcuEbvz5ej jctucS70MpyllXl43W/RRY6BYvZF6WxdE0I+pZ5/80drPpv1SocTWZ9yz/X29Hep1ClJKW76 36mpr8RSnJFoqMVcVJwIAGEguVsLAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Rp5daxSYRsrV_lEDkO4c8qw7OKU Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 02:50:01 -0000 On 10/21/2014 07:01 AM, Rick van Rein wrote: >> Unfortunately, this is not enough; a >> server also needs to know that any server using the Authenticator will >> actually use the subkey to protect the data stream, and that it won't >> accept messages from the client transmitted using the ticket session key. > > This was indeed specified; does the following text address your concern? > > After both AP-REQ and AP-REP have been processed, and their joint meaning > in the table above indicates that a shared secret can be constructed, then both > parties MUST derive that shared secret and continue to communicate using that, > employing the encryption type specified in the AP-REQ message's subkey field, > notably the etype2 subtype. Not really. There is no way for the library which implements AP-REQ/AP-REP to know whether the caller is going to do anything useful with the negotiated subsession key--or whether other server implementations which receive the authenticator will do so. If negotiating a unique key in an AP exchange were sufficient to do away with replay caches, we would be able to do so without DH, since the server can pick a unique subkey in an AP-REP already, and does so whenever RFC 4121 is used. From nobody Wed Oct 22 10:59:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124BF1A9112 for ; Wed, 22 Oct 2014 10:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKqD4vpYivIn for ; Wed, 22 Oct 2014 10:59:42 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB30B1ACE97 for ; Wed, 22 Oct 2014 10:59:39 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-34-5447f08aa83d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 59.88.13180.A80F7445; Wed, 22 Oct 2014 13:59:38 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9MHxWHE026703; Wed, 22 Oct 2014 13:59:32 -0400 Received: from [18.101.8.164] (vpn-18-101-8-164.mit.edu [18.101.8.164]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9MHxUeW012406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Oct 2014 13:59:31 -0400 Message-ID: <5447F081.2070907@mit.edu> Date: Wed, 22 Oct 2014 13:59:29 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rick van Rein , Benjamin Kaduk References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> <544558CC.8050709@mit.edu> <37912FFA-7C0A-4CCB-9F97-C757EC8794D8@openfortress.nl> In-Reply-To: <37912FFA-7C0A-4CCB-9F97-C757EC8794D8@openfortress.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrtv1wT3EYMoMTYujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGW8u76LveAVV8WJs2INjOc5uhg5OSQETCQ+ TW5ig7DFJC7cWw9kc3EICcxmklj1rJMJwtnIKPHu20KozBEmicvPvzCDtPAKqEm0H37JDmKz CKhKvG2YBWazCShLrN+/laWLkYNDVCBMYupSHohyQYmTM5+wgNgiAh4S7zcfYgUpYRZQl9i5 mxnEFBZIl/i4wwNi01YmiXd7usGO4xRwlljyaiYriM0soCex4/ovKFteonnrbOYJjIKzkGyY haRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYKD10V5B+Ofg0qH GAU4GJV4eCc+cg8RYk0sK67MPcQoycGkJMq75y1QiC8pP6UyI7E4I76oNCe1+BCjBAezkghv yTugHG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBG/be6BGwaLU9NSK tMycEoQ0EwcnyHAeoOFzQWp4iwsSc4sz0yHypxgVpcR5p4MkBEASGaV5cL2w5PKKURzoFWHe DpAqHmBigut+BTSYCWjw5w0uIINLEhFSUg2M8pOE1jXP9bqu38t8L+3u9jxJBT2jp8dVHppa Ot1bc6xy39+HjYf2tSdNNsw4vb1u/zZL/kTGfiWDAOaXXBWpKys/Hk2vfcy/qStlypL6w1qC i09N2+vy5UbettP5T9OEN1/9nhTZnlQs8HTKB7kMOeFFu9eZfC/wnFR2eJK+uCTD8nm9gfpb lFiKMxINtZiLihMBMHQ1lwkDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/v3E2Z-kNkCHoc3GDqGI9v1x3pqw Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:59:44 -0000 On 10/21/2014 04:31 AM, Rick van Rein wrote: > Pros: > - opportunistic KRB5-KDH > - no need for a ticket flag have-kdh > - KDC does not need to change > - administrator does not need to administer have-kdh flags We may still need a KDC indication of KDH support, for several reasons. First, in the initial deployment, clients won't necessarily want to offer KDH without a reason to believe it will yield a benefit. Being able to try opportunistically and downgrade securely is great, but it's not always the best choice. Second, some protocols (e.g. MIT Zephyr) are sensitive to the size of the AP-REQ. The KDC may need a way to advise clients not to use KDH for those server principals. Third, we cannot assume that our initial set of ECDH algorithms will be good enough forever--at some point there will be a new set of algorithms, and further new sets beyond that. Clients will not be in a great position to gracefully upgrade to new algorithms without advice from the KDC--they would either have to make multiple KDH offers, or risk trying an algorithm that is too new and falling back to not using forward secrecy at all. A single ticket flag isn't sufficient to handle the second and third cases. Since we don't want to be introducing lots of ticket flags, I think the right vehicle is the encrypted padata field introduced in RFC 6806. From nobody Fri Oct 24 03:58:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4BD1A8A20 for ; Fri, 24 Oct 2014 03:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.093 X-Spam-Level: ** X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX9FbIdVetJq for ; Fri, 24 Oct 2014 03:57:57 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD04F1A89B5 for ; Fri, 24 Oct 2014 03:57:56 -0700 (PDT) Received: from [10.87.1.252] ([145.15.244.17]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9OAvlD4087866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Oct 2014 12:57:52 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <5447F081.2070907@mit.edu> Date: Fri, 24 Oct 2014 11:50:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> <544558CC.8050709@mit.edu> <37912FFA-7C0A-4CCB-9F97-C757EC8794D8@openfortress.nl> <5447F081.2070907@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1fTpKx5E4zCsJSIHSytvcdjunfc Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 10:57:59 -0000 Hi, =85and I thought KRB5-KDH was going to be a trivial stepping stone towards TLS-KDH ;-) Really though, knowing the protocol that embeds an exchange turns out to be a major advantage, so the TLS variation may actually be simpler. Well, that doesn=92t reduce the potential value of KRB5-KDH of course. This sort of advantage is perhaps best resolved through flags on one of the APIs, because the application can steer behaviour in a static way. This would also make it possible to enforce KDH protection if so desired by an application. > We may still need a KDC indication of KDH support, for several = reasons. Surprised=85 I was happy to have gotten rid of it. But let=92s = consider. > First, in the initial deployment, clients won't necessarily want to > offer KDH without a reason to believe it will yield a benefit. Being > able to try opportunistically and downgrade securely is great, but = it's > not always the best choice. I suppose a setting on the cilent could be used to avoid the =93wasteful=94= aspect of opportunism in early phases. But that would not be easy to control centrally; so the KDC could send it; if it were just this one thing, the solution might have been a global toggle in the KDC that switches over the entire realm. > Second, some protocols (e.g. MIT Zephyr) are sensitive to the size of > the AP-REQ. The KDC may need a way to advise clients not to use KDH = for > those server principals. This sounds awkward. RFC 4120 clearly states "The encoding of Kerberos protocol messages shall obey the Distinguished Encoding Rules (DER) of ASN.1=94, so how could it have such senstivities? Is this in fact a bug = in Zephyr? If it is, I think it should be localised rather than permitted = to spread into KDC settings and new specifications that build upon the definitions = of its predecessors =97 for instance, introduce an API flag to suppress = KDH, and cause a dependency between the app and the library version that disables library replacement without application replacement. = Alternatively, the library configuration could hold settings that flag down KDH = behaviour on buggy service names. > Third, we cannot assume that our initial set of ECDH algorithms will = be > good enough forever--at some point there will be a new set of > algorithms, and further new sets beyond that. Clients will not be in = a > great position to gracefully upgrade to new algorithms without advice > from the KDC--they would either have to make multiple KDH offers, or > risk trying an algorithm that is too new and falling back to not using > forward secrecy at all. Pondering. RFC 4537 provides a negotiation mechanism, but it doesn=92t introduce extra packets and so the client must still make its DH offers as you describe. Pondering. There generally is overlap between old and new algorithms, enabling a range of =93safe=94 choices. But if a server knows about the retraction of the security status of algorithm A while a cilent is = unaware, we=92ll be in trouble (that is, opportunism fails). Pondering. In such exceptional cases where unacceptable algorithms are tried by a negligent client, it might be notified by the server and = would have to fetch a new ticket to try again. This knowledge could not = spread though, or it would incur a risk of downgrade attack on the ciphers = used. Again, it feels best to have a list of permissible ciphers setup in the library configuration, so the operator can modify these settings, in response to security reports, which can suggest it as a quickfix. And when a new package is available, which is bound to occur soon for security trouble, then it too can be installed. Services failing to = give access would enforce this upgrading behaviour from local installations, which is a pest, but that is just what security problems are=85 a pest. There may of course be distribution mechanisms for configuration information, to make deployment more reliable. I am not sure if the KDC should be taking up on that role. > A single ticket flag isn't sufficient to handle the second and third > cases. Since we don't want to be introducing lots of ticket flags, I > think the right vehicle is the encrypted padata field introduced in = RFC > 6806. You mean a plain PA-DATA with encryption on its contents, so it is validated? Yes, the validation would be needed to avoid downgrade attacks. It is another =93pragmatic solution=94 however, and adds to = the complexity of Kerberos =97 and it requires a KDC change. I am not a fan of that style. Curious if the alternative approach above sounds agreeable to the list. Cheers, -Rick= From nobody Fri Oct 24 06:16:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85981A00B7 for ; Fri, 24 Oct 2014 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT99xG1ym_wc for ; Fri, 24 Oct 2014 06:16:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377FB1A0092 for ; Fri, 24 Oct 2014 06:16:07 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9ODG6mL019051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Oct 2014 09:16:06 -0400 Received: from willson.usersys.redhat.com (ovpn-113-127.phx2.redhat.com [10.3.113.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9ODG4wJ015079 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Oct 2014 09:16:05 -0400 Date: Fri, 24 Oct 2014 09:16:02 -0400 From: Simo Sorce To: Rick van Rein Message-ID: <20141024091602.648b43e7@willson.usersys.redhat.com> In-Reply-To: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> <544558CC.8050709@mit.edu> <37912FFA-7C0A-4CCB-9F97-C757EC8794D8@openfortress.nl> <5447F081.2070907@mit.edu> Organization: Red Hat, Inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/6wWmPg_lg1MGgpWP0C80aecDRyY Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:16:11 -0000 On Fri, 24 Oct 2014 11:50:06 +0200 Rick van Rein wrote: > Hi, >=20 > =E2=80=A6and I thought KRB5-KDH was going to be a trivial stepping stone > towards TLS-KDH ;-) >=20 > Really though, knowing the protocol that embeds an exchange turns > out to be a major advantage, so the TLS variation may actually be > simpler. Well, that doesn=E2=80=99t reduce the potential value of KRB5-K= DH > of course. >=20 > This sort of advantage is perhaps best resolved through flags on one > of the APIs, because the application can steer behaviour in a static > way. This would also make it possible to enforce KDH protection if so > desired by an application. >=20 > > We may still need a KDC indication of KDH support, for several > > reasons. >=20 > Surprised=E2=80=A6 I was happy to have gotten rid of it. But let=E2=80= =99s consider. >=20 > > First, in the initial deployment, clients won't necessarily want to > > offer KDH without a reason to believe it will yield a benefit. > > Being able to try opportunistically and downgrade securely is > > great, but it's not always the best choice. >=20 > I suppose a setting on the cilent could be used to avoid the > =E2=80=9Cwasteful=E2=80=9D aspect of opportunism in early phases. But th= at would not > be easy to control centrally; so the KDC could send it; if it were > just this one thing, the solution might have been a global toggle in > the KDC that switches over the entire realm. >=20 > > Second, some protocols (e.g. MIT Zephyr) are sensitive to the size > > of the AP-REQ. The KDC may need a way to advise clients not to use > > KDH for those server principals. >=20 > This sounds awkward. RFC 4120 clearly states "The encoding of > Kerberos protocol messages shall obey the Distinguished Encoding > Rules (DER) of ASN.1=E2=80=9D, so how could it have such senstivities? Is > this in fact a bug in Zephyr? If it is, I think it should be > localised rather than permitted to spread into KDC settings and new > specifications that build upon the definitions of its predecessors =E2=80= =94 > for instance, introduce an API flag to suppress KDH, and cause a > dependency between the app and the library version that disables > library replacement without application replacement. Alternatively, > the library configuration could hold settings that flag down KDH > behaviour on buggy service names. >=20 > > Third, we cannot assume that our initial set of ECDH algorithms > > will be good enough forever--at some point there will be a new set > > of algorithms, and further new sets beyond that. Clients will not > > be in a great position to gracefully upgrade to new algorithms > > without advice from the KDC--they would either have to make > > multiple KDH offers, or risk trying an algorithm that is too new > > and falling back to not using forward secrecy at all. >=20 > Pondering. RFC 4537 provides a negotiation mechanism, but it doesn=E2=80= =99t > introduce extra packets and so the client must still make its DH > offers as you describe. >=20 > Pondering. There generally is overlap between old and new algorithms, > enabling a range of =E2=80=9Csafe=E2=80=9D choices. But if a server know= s about the > retraction of the security status of algorithm A while a cilent is > unaware, we=E2=80=99ll be in trouble (that is, opportunism fails). >=20 > Pondering. In such exceptional cases where unacceptable algorithms > are tried by a negligent client, it might be notified by the server > and would have to fetch a new ticket to try again. This knowledge > could not spread though, or it would incur a risk of downgrade attack > on the ciphers used. >=20 > Again, it feels best to have a list of permissible ciphers setup in > the library configuration, so the operator can modify these settings, > in response to security reports, which can suggest it as a quickfix. > And when a new package is available, which is bound to occur soon for > security trouble, then it too can be installed. Services failing to > give access would enforce this upgrading behaviour from local > installations, which is a pest, but that is just what security > problems are=E2=80=A6 a pest. >=20 > There may of course be distribution mechanisms for configuration > information, to make deployment more reliable. I am not sure if > the KDC should be taking up on that role. >=20 > > A single ticket flag isn't sufficient to handle the second and third > > cases. Since we don't want to be introducing lots of ticket flags, > > I think the right vehicle is the encrypted padata field introduced > > in RFC 6806. >=20 > You mean a plain PA-DATA with encryption on its contents, so it is > validated? Yes, the validation would be needed to avoid downgrade > attacks. It is another =E2=80=9Cpragmatic solution=E2=80=9D however, and= adds to the > complexity of Kerberos =E2=80=94 and it requires a KDC change. I am not > a fan of that style. Curious if the alternative approach above sounds > agreeable to the list. To me it seems the best outcome, traditionally the KDC assists in dealing with algorithm agility, and it should do so in this case too. Note that clients can still ignore what the KDC says and use opportunistic methods that differ from advice received, but at least they will have a chance of knowing what is expected of them if the PA-DATA packet is available. The only "issue" would be if client and server are upgraded but the KDC is not notified of the new capablities, so that the KDC keeps sending to the client advice to use "weaker" algorithms only, but that is no different than having new clients and servers that can do AES today but still giving them only DES keys. Simo. --=20 Simo Sorce * Red Hat, Inc * New York From nobody Fri Oct 24 07:57:54 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9DB1A1A14 for ; Fri, 24 Oct 2014 07:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMOOsKo9Hp6K for ; Fri, 24 Oct 2014 07:57:46 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A048A1A1A0D for ; Fri, 24 Oct 2014 07:57:45 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-5e-544a68e8e75b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 46.65.23365.8E86A445; Fri, 24 Oct 2014 10:57:44 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9OEvcjB006058; Fri, 24 Oct 2014 10:57:38 -0400 Received: from [18.101.8.226] (vpn-18-101-8-226.mit.edu [18.101.8.226]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9OEvZbR028699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Oct 2014 10:57:37 -0400 Message-ID: <544A68DF.4070604@mit.edu> Date: Fri, 24 Oct 2014 10:57:35 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rick van Rein References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> <544558CC.8050709@mit.edu> <37912FFA-7C0A-4CCB-9F97-C757EC8794D8@openfortress.nl> <5447F081.2070907@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrfsiwyvEYO42IYujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGUcOOFUcEGi4uIepQbG58JdjJwcEgImEs/P rGaBsMUkLtxbz9bFyMUhJDCbSeLzn49MEM5GRomVzxoYIZwjTBIXd85hBmnhFVCTmHP6EZjN IqAqMef5XiYQm01AWWL9/q1AYzk4RAXCJKYu5YEoF5Q4OfMJ2DYRAQ2Jz7+msoHYzALuEud/ vmQEKRcWSJf4uMMDYlU7s8TmwyvA6jkFnCVebGlgh6jXk9hx/RcrhC0v0bx1NvMERsFZSFbM QlI2C0nZAkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbomermZJXqpKaWbGMHBK8m/g/HbQaVD jAIcjEo8vDdmeIYIsSaWFVfmHmKU5GBSEuUNTvYKEeJLyk+pzEgszogvKs1JLT7EKMHBrCTC ey4NKMebklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMF7OB2oUbAoNT21 Ii0zpwQhzcTBCTKcB2j4b5Aa3uKCxNzizHSI/ClGRSlx3tMgCQGQREZpHlwvLLm8YhQHekWY lwWYaoR4gIkJrvsV0GAmoMHxGzxABpckIqSkGhgT1NyDV6pqzfzXdMBmu7eebEaET9zsUrF9 xsn25prusc/f+NdHcMxYVh+g1/3qqvTEI+JC5Wnb4ydME/5S16CXvWWpYdObI8bzA73TEst4 wyuNTkrahKZd9eXa31FV9/NmMZfY2VNxJ6dlf/M2cxCXWHY66PP1+6u7PkUf6F55QDo50n9d qRJLcUaioRZzUXEiAATYWAIJAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IgX6piSrxsTwv9MVcdVwyliGeR4 Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:57:49 -0000 On 10/24/2014 05:50 AM, Rick van Rein wrote: >> A single ticket flag isn't sufficient to handle the second and third >> cases. Since we don't want to be introducing lots of ticket flags, I >> think the right vehicle is the encrypted padata field introduced in RFC >> 6806. > > You mean a plain PA-DATA with encryption on its contents, so it is > validated? No; please see RFC 6806 section 11. This field is already cryptographically protected and securely negotiated; all we would need is a way to represent support for different KDH algorithms, or to indicate that KDH is undesirable for space reasons. >> Second, some protocols (e.g. MIT Zephyr) are sensitive to the size of >> the AP-REQ. The KDC may need a way to advise clients not to use KDH for >> those server principals. > > This sounds awkward. RFC 4120 clearly states "The encoding of Kerberos > protocol messages shall obey the Distinguished Encoding Rules (DER) of > ASN.1”, so how could it have such senstivities? It's about how the authenticator is transported. In the case of Zephyr, there is a limitation of 512 bytes on the packet header, and the more space consumed by the ticket and authenticator, the less space there is for other packet header fields. Zephyr is not a particularly good protocol, but it is not the only protocol which can be negatively impacted by ticket or authenticator expansion. > Again, it feels best to have a list of permissible ciphers setup in the > library configuration, so the operator can modify these settings, in > response to security reports, which can suggest it as a quickfix. I don't understand this proposal. If there are old KDH algorithms and new ones, the client wants to use one of the new ones, but only if it thinks the server will support that. The client's library configuration doesn't know anything about the server's capabilities. It seems like you're suggesting that clients would continue to offer one of the old algorithms until an advisory comes out demonstrating that it is insecure, at which point administrators would blacklist the old algorithm. Delaying use of new algorithms until the old ones are completely broken is not a good form of algorithm agility. > There may of course be distribution mechanisms for configuration > information, to make deployment more reliable. I am not sure if > the KDC should be taking up on that role. The KDC is already responsible for negotiating RFC 3961 enctypes to the server, since the ticket session key must be understood by both the client and the server. The client presents a supported enctype list to the KDC, but the KDC simply has to know about the server's capabilities as the server isn't a party to the AS or TGS exchange. The MIT krb5 administrative tooling doesn't currently do a great job of communicating server capabilities to the KDC. And it can't do a perfect job; there isn't always exactly one implementation of Kerberos on a server, and keytabs aren't always administered from the server. So this responsibility of the KDC can sometimes be a bit painful--but it's not a new job. From nobody Fri Oct 24 09:58:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEE11A8966 for ; Fri, 24 Oct 2014 09:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojXzyq9c4M06 for ; Fri, 24 Oct 2014 09:58:52 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C45D91A8852 for ; Fri, 24 Oct 2014 09:54:57 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 864F52F4065 for ; Fri, 24 Oct 2014 09:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=jR0EA+tPd6v1nfKqxzH5I7oSU1M=; b=w+nwh1SoVhk HR/4tUmK7PTrk7CD7QG7Ixz1TUuamjW5mQnyOH2Z+IPGUc1GA0omI7QW4dD10amZ sFKd7qEAifhPe/wrF0dpKQ4kQVvt1r71QqCfzWoa4rUcRZEYIKOsCxTsyNvdMTpk kfKTm+pVaHvPj6qOEp/tfWB9ZxtypJOQ= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 338D22F4060 for ; Fri, 24 Oct 2014 09:54:57 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id q5so1683087wiv.4 for ; Fri, 24 Oct 2014 09:54:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.101.230 with SMTP id fj6mr5289683wib.70.1414169695938; Fri, 24 Oct 2014 09:54:55 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Fri, 24 Oct 2014 09:54:55 -0700 (PDT) Date: Fri, 24 Oct 2014 11:54:55 -0500 Message-ID: From: Nico Williams To: Rick van Rein , "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/x5fHitcXDagjVPqUZHAbG-qMDCw Cc: "kerberos@mit.edu" Subject: Re: [kitten] What happened to PKCROSS? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:58:53 -0000 FYI, I just submitted draft-williams-kitten-krb5-pkcross-03. It still needs some work, obviously (e.g., DANE RRset stapling). But it's closer. In particular I've added details on how a TGS can drive PKCROSS. It turns out to be quite simple... TODO: - add a new KDC error code by which a KDC can indicate that it is rejecting a foreign realm PKINIT request by a non-KDC client - add a reference(s) for DANE stapling - maybe remove all TOFU/LoF text (since it could go in a separate I-D) - ... Nico -- From nobody Fri Oct 24 10:18:57 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C4A1A87BE for ; Fri, 24 Oct 2014 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK6j3c20Nbaw for ; Fri, 24 Oct 2014 10:18:50 -0700 (PDT) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934C01A87A6 for ; Fri, 24 Oct 2014 10:18:50 -0700 (PDT) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id AC06E2627; Fri, 24 Oct 2014 19:18:48 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([127.0.0.1]) by smtp-3.sys.kth.se (smtp-3.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id efIfMMyXe7W9; Fri, 24 Oct 2014 19:18:39 +0200 (CEST) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-3.sys.kth.se (Postfix) with ESMTPS id 71D622608; Fri, 24 Oct 2014 19:18:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1414171119; bh=/bD9Lk1TuIE9vKlQI55pcjIRgLfiMsHRV0PF8XfR2k0=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=GDApOyjzHlqzHAd3Qw4oSuEGZCJ6jSlJvBaIyN9y0O/aLYXHTkrEC336DawU6e3rx 9XxgF/WCGDjF9PgByBNy5DWSz8SKj2eKgMjjCiK8e1evY2PumzzhndeVj8Pib+EZLh dT+n9Gr5ybq/K4p3sSWqCBqXIpbGtp+6RMXhGwCI= Received: from EXDB1.ug.kth.se ([169.254.1.81]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.03.0169.001; Fri, 24 Oct 2014 19:18:03 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: Simo Sorce Thread-Topic: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman Thread-Index: AQHP5YnVQFwWm76/EEmMAlCLYPlHGJw0X3iAgASIlQCAACycAIAAIskAgAAImQCAAOYfAIACMRSAgAKb7gCAADmKAIAAZSUl Date: Fri, 24 Oct 2014 17:18:02 +0000 Message-ID: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <5441416B.20306@mit.edu> <54453468.6000005@mit.edu> <544558CC.8050709@mit.edu> <37912FFA-7C0A-4CCB-9F97-C757EC8794D8@openfortress.nl> <5447F081.2070907@mit.edu> , <20141024091602.648b43e7@willson.usersys.redhat.com> In-Reply-To: <20141024091602.648b43e7@willson.usersys.redhat.com> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fSK2jxsxvqkToilX1Zi-KJ-WDMg Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 17:18:52 -0000 > 24 okt 2014 kl. 06:16 skrev Simo Sorce : >=20 > To me it seems the best outcome, traditionally the KDC assists in > dealing with algorithm agility, and it should do so in this case too. For the same reason we got ETypeInfo in GSS we can have KDC assist, but it = can't be required. Love= From nobody Fri Oct 24 12:38:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C7A1A8BC5 for ; Fri, 24 Oct 2014 12:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ct25hmm_E1cs for ; Fri, 24 Oct 2014 12:37:55 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077921A8BC0 for ; Fri, 24 Oct 2014 12:37:53 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-79-544aaa90d7ab Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 92.90.23365.09AAA445; Fri, 24 Oct 2014 15:37:52 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9OJbpBf008011; Fri, 24 Oct 2014 15:37:52 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9OJbnVB031407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Oct 2014 15:37:50 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9OJbnpD011012; Fri, 24 Oct 2014 15:37:49 -0400 (EDT) Date: Fri, 24 Oct 2014 15:37:48 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <5440248F.4080506@mit.edu> Message-ID: References: <543EA410.5000508@cisco.com> <5440248F.4080506@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrjthlVeIweEjehZHN69isfj88Dar A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJUx79NKtoILyhXXfi5kbGD8JtPFyMkhIWAi sWnXO1YIW0ziwr31bF2MXBxCArOZJP40TmKFcDYySpw+sg7KOcQkMe/YNSingVHi56lmFpB+ FgFtia2zl7OB2GwCKhIz32wEs0UEFCV+r3zLCGIzCyRINN54D7ZPWMBa4uGJDcwgNqeAusSW F4+YQGxeAUeJ/0ufgNUICThLzFq4BKxGVEBHYvX+KSwQNYISJ2c+YYGYqSWxfPo2lgmMgrOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pSuokRFKyckvw7GL8dVDrE KMDBqMTDe2OGZ4gQa2JZcWXuIUZJDiYlUd6bC71ChPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw Pl4MlONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuD1WQnUKFiUmp5a kZaZU4KQZuLgBBnOAzTcC6SGt7ggMbc4Mx0if4pRUUqcdxtIQgAkkVGaB9cLSyavGMWBXhHm jQSp4gEmIrjuV0CDmYAGx2/wABlckoiQkmpgbIxxua8ksSj8nMLjj5HyEx7/Npq55NvbRfUh s14aGERt+2th82Xm7Dzbi6fz57EdPp1abrgl+/cBdpMVjO/Y/54/8GNSj0N5w00ejrkWBvcT 96d22N5M76jf724ou0362KJY7fry/cE2VWu61ZqMJZM2VYae5ovJ3bKlYdfnTmOZQ7ZPuAvV lFiKMxINtZiLihMBQiJIpgEDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dvl_YrUvKJG8sFB6wqENZs09HB8 Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 19:38:03 -0000 Sorry for the slow response. (Everyone else, note that there's less than a week left in the WGLC.) On Thu, 16 Oct 2014, Greg Hudson wrote: > I am confused about the paragraph beginning "Extra security context > tokens can also be emitted if...". This is not a scenario I'm familiar > with. This came from my reading of the last paragraph of section 1.2.1.2 of RFC 2743, where the normative requirement is conditional on the requested flags input to GSS_Init_sec_context(). Looking at it again, I see an alternate reading which is normative on mechanism specifications to disallow single-token context establishment when optional features are present. So maybe this is not an actual scenario. In any case, I agree that this is not a something of practical concern. > On that note, some (most?) protocols do not have a means of transmitting > extra context tokens; I guess implementations of those protocols don't > have to worry about receiving them, so won't need guidance. Right. We highly discourage the use of deletion tokens, which is the only place where process_context_token is likely to arise, so applications basically don't need to care about it. > I am not convinced that "These resources may be non-local to the current > process" is a realistic concern for GSS applications. RFC 2743 does speculate about """using interprocess tokens as a means to reference local interprocess communication facilities (protected by other means) rather than storing the context data directly within the tokens.""" (for export_sec_context tokens), admitting the possibility of resources attached to GSS objects which are non-local to the current process. I don't know of any implementations using that freedom, but it does seem pretty clear as something permitted by the spec. > The example code includes but doesn't use any asserts. My local version of send_token and receive_token have asserts in them, but I should remove the header from the published document, thanks. > GSS_C_EMPTY_BUFFER initializers might be more correct and elegant than > memsets. That's a good point; fixed in my local tree. The declaration spills out to one variable per line due to the line length limitations of the RFC format, but it's still a net shrinkage. > Here are a few editorial comments: > > * I found this a little confusing: "For the first call to each routine > in the loop, the major status code from the previous call to > GSS_Init_sec_context() or GSS_Accept_sec_context() should be taken as > GSS_S_CONTINUE_NEEDED." I believe this is aimed at the > sanity-checking/input validation sections, which use text like "for > example, if the initiator's previous call to GSS_Init_sec_context() > returned GSS_S_COMPLETE." But I don't think it is really needed. There is text in 2.7 about "the previous call to GSS_Init_sec_context() returned GSS_S_CONTINUE_NEEDED" for which the text you find confusing would be applicable. I think previous revisions of this draft had more such places. Having looked again, I agree that it is not really needed; I've removed it from my working copy. > * The example code contains "must not directly cause termination of the > process (i.e., by errx())" in two places. I would suggest removing the > parentheticals. As it stands, I have to wonder if "i.e." is being used > to mean "for example," which is incorrect. Removing the parentheticals seems fine, I'll do that. (And yes, the "i.e." are wrong.) > * "Upon completion of security context negotiation, the initiator must > verify that the values of the [...] flags from the last call to > GSS_Init_sec_context() corresponding to the requested flags." This is > not grammatically correct. s/corresponding/correspond/ is the big braino on my part, but I also added a "the" before "security context negotiation" for kicks. > * The document borders on overuse of parentheticals--something I have to > fight in my own writing. Some of the parentheticals may be too > important to be included as parentheticals; some others could probably > be omitted. I went through and changed several of them (mostly just converting to comma-offset phrases). I don't think I removed any, though... There was one spot where I had to reorder things and reword a bit so that it still makes sense (about using the context before negotiation is complete). The updates I've made are visible on my github repo, https://github.com/kaduk/gssdoc/commits/master . -Ben From nobody Fri Oct 24 14:33:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CA31A1B84 for ; Fri, 24 Oct 2014 14:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yXgxhFR-OVq for ; Fri, 24 Oct 2014 14:33:38 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C15151A0461 for ; Fri, 24 Oct 2014 14:33:38 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 7E0AABBA06A; Fri, 24 Oct 2014 14:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=FGNNqdNepcu6JP orRooSWdPe+cE=; b=kXf6fVFQqQh5IeqDJVRnmIFajv9ea2dW+lARfRj5osx8GF E3vlrddUIyQN4H6usgPb2ysAUgd2pjyH2Ld4MJLsejZzz5eM64h13gW2j0G2bjQ/ tWrOlUlTHDDeHXVzmvoc+1GrZwtcLdPK16BzmCXi33hmpeJxKTSNk3TR15dtM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 279ACBBA06C; Fri, 24 Oct 2014 14:33:38 -0700 (PDT) Date: Fri, 24 Oct 2014 16:33:37 -0500 From: Nico Williams To: Rick van Rein Message-ID: <20141024213333.GA6185@localhost> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3-la6bty3ZNGiH6FOffmNh3sTKA Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:33:39 -0000 On Sat, Oct 11, 2014 at 09:30:16PM +0200, Rick van Rein wrote: > I just posted a new I-D that introduces a DH subkey mechanism for Kerberos. IMO we should adopt a work item for this feature. I'm not sure yet what's the best design. My notes: - overloading enctype with DH is tempting, but we need to be careful to avoid a cartesian product of {DH curves} x {traditional enctypes} - if the KDC has the service's public DH key(s) then it can send it as the session key for the ticket when the client offers the corresponding enctype - if the KDC knows the services' supported DH curves but not its public keys then... we need to extend KDC-REP to convey this info - if the KDC knows the services' supported DH curves then it might as well know the service's public keys too! - knowing the service's supported DH enctypes the client can then use the subkey field in the Authenticator to convey its DH public key (but watch out for cartesian explosion) - the service can convey its public key (or a new one, if the KDC knew its long-term one) using the subkey field of the AP-REP (but again, cartesian explosion) BUT, if the service doesn't send its pubkey this way then we need to extend AP-REP. - for proper PFS we need one more message after the AP-REP - for proper PFS we need a DH exchange in the AP exchange; it's not enough that the KDC knows the service's DH public keys - just because we want proper PFS doesn't mean we must do a full DH exchange in every AP exchange: we could do something like TLS resumption: the service should return a short-lived Ticket (minted by the service) Let's call this "fast re-auth tickets". Other uses include: - PAC/CAMMAC compression: the service caches the PAC/CAMMAC and returns a smaller Ticket for future AP exchanges. - Caching of service-side state (e.g., when the KDC-minted Ticket didn't have a PAC/CAMMAC and the service wanted one and doesn't want to cache it). (IMO this is not a good idea. It's the reverse of the previous item.) - fast re-auth tickets imply a need for extra round-trips for error recovery, but we needed this for other reasons anyways, so we might as well do it - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS Clearly it'd be best to not overload subkey, and therefore not overload enctype. Clearly we need: - a three-message AP exchange option - an extra round-trip option - an AP-REP extension (like authz-data in Authenticator, but in the other direction) - a KDC-REP body enc-part extension (for conveying things like services' known DH public keys) - extensions to fit in the new slots to convey public DH keys, and an authz-data for the same purpose in the Authenticator - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS Nico -- From nobody Fri Oct 24 14:37:48 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212E41A1B85 for ; Fri, 24 Oct 2014 14:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf8_RjdTXaoT for ; Fri, 24 Oct 2014 14:37:44 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F21A0461 for ; Fri, 24 Oct 2014 14:37:44 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 905F3318065; Fri, 24 Oct 2014 14:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= resent-from:resent-date:resent-message-id:resent-to:date:from:to :cc:subject:message-id:references:mime-version:content-type: in-reply-to; s=cryptonector.com; bh=FGNNqdNepcu6JPorRooSWdPe+cE= ; b=wXwt+vXcgGNGt/nnsSjC1yAUKX5PUQEc53Vyo7ZQ4h6zUb0NDdNQQgArKPoQ twTGcuu9JIINU7CYFezmPf1K5OiGbLfgJvhczuqZWNJHg0XbrFsErsNWSCit/vKD h7jfng9bLq01yA2oMARSh1ovupKpKestl4PEODHqLT6s+qE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 4AB4631805D; Fri, 24 Oct 2014 14:37:44 -0700 (PDT) Resent-From: Nico Williams Resent-Date: Fri, 24 Oct 2014 16:37:43 -0500 Resent-Message-ID: <20141024213743.GB6185@localhost> Resent-To: rick@openfortress.nl, kitten@ietf.org Date: Fri, 24 Oct 2014 16:33:35 -0500 From: Nico Williams To: Rick van Rein Message-ID: <20141024213333.GA6185@localhost> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3-la6bty3ZNGiH6FOffmNh3sTKA Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:37:46 -0000 On Sat, Oct 11, 2014 at 09:30:16PM +0200, Rick van Rein wrote: > I just posted a new I-D that introduces a DH subkey mechanism for Kerberos. IMO we should adopt a work item for this feature. I'm not sure yet what's the best design. My notes: - overloading enctype with DH is tempting, but we need to be careful to avoid a cartesian product of {DH curves} x {traditional enctypes} - if the KDC has the service's public DH key(s) then it can send it as the session key for the ticket when the client offers the corresponding enctype - if the KDC knows the services' supported DH curves but not its public keys then... we need to extend KDC-REP to convey this info - if the KDC knows the services' supported DH curves then it might as well know the service's public keys too! - knowing the service's supported DH enctypes the client can then use the subkey field in the Authenticator to convey its DH public key (but watch out for cartesian explosion) - the service can convey its public key (or a new one, if the KDC knew its long-term one) using the subkey field of the AP-REP (but again, cartesian explosion) BUT, if the service doesn't send its pubkey this way then we need to extend AP-REP. - for proper PFS we need one more message after the AP-REP - for proper PFS we need a DH exchange in the AP exchange; it's not enough that the KDC knows the service's DH public keys - just because we want proper PFS doesn't mean we must do a full DH exchange in every AP exchange: we could do something like TLS resumption: the service should return a short-lived Ticket (minted by the service) Let's call this "fast re-auth tickets". Other uses include: - PAC/CAMMAC compression: the service caches the PAC/CAMMAC and returns a smaller Ticket for future AP exchanges. - Caching of service-side state (e.g., when the KDC-minted Ticket didn't have a PAC/CAMMAC and the service wanted one and doesn't want to cache it). (IMO this is not a good idea. It's the reverse of the previous item.) - fast re-auth tickets imply a need for extra round-trips for error recovery, but we needed this for other reasons anyways, so we might as well do it - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS Clearly it'd be best to not overload subkey, and therefore not overload enctype. Clearly we need: - a three-message AP exchange option - an extra round-trip option - an AP-REP extension (like authz-data in Authenticator, but in the other direction) - a KDC-REP body enc-part extension (for conveying things like services' known DH public keys) - extensions to fit in the new slots to convey public DH keys, and an authz-data for the same purpose in the Authenticator - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS Nico -- From nobody Fri Oct 24 14:58:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13571A06FD for ; Fri, 24 Oct 2014 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaoDhMMR0Enl for ; Fri, 24 Oct 2014 14:58:23 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD3E1A870D for ; Fri, 24 Oct 2014 14:58:23 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 47574200B9987; Fri, 24 Oct 2014 14:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KTfx1Eew+4GNJp 4StiqNRRUQFy0=; b=ZN1wiW7xrowXyfjhWwW2hyXBzdwjP68O9p16Y0OrWCbl/J Y+aWX9SpbnsOeZADxNZh1DbxcYetqbh6uk+Gmd5M7GHVEXYE8rSCUINoHi2RSc5Q ReUCM2OlpF2Do82e8FndnBowWCFPlJKWpQpW51crk7VW2hIEPYit0GgBohZ6Q= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id ECF1120024944; Fri, 24 Oct 2014 14:58:21 -0700 (PDT) Date: Fri, 24 Oct 2014 16:58:21 -0500 From: Nico Williams To: Rick van Rein Message-ID: <20141024215820.GC6185@localhost> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141024213333.GA6185@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DgwGT73cRzr83uUR090PbxFl_Cc Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:58:24 -0000 On Fri, Oct 24, 2014 at 04:33:37PM -0500, Nico Williams wrote: > My notes: A couple more points: - when PFS is not needed then we can still use a single round trip, even in the case that the KDC didn't know the service's public keys or supported curves: C->S: AP-REQ w/ client's DH pubkey(s) (for one or more curves) and list of enctypes S->C: AP-REP w/ service's DH pubkey for the selected curve, + an indication of which enctype was selected this way we also get fallback to not-DH if the service doesn't support it. > - overloading enctype with DH is tempting, but we need to be careful to > avoid a cartesian product of {DH curves} x {traditional enctypes} That's what TLS does. Let's not repeat that mistake. Nico -- From nobody Fri Oct 24 15:05:54 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309B71A90B5 for ; Fri, 24 Oct 2014 15:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiLWfgDz1lcm for ; Fri, 24 Oct 2014 15:05:51 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFF41A90B0 for ; Fri, 24 Oct 2014 15:05:51 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 09F1C1006D; Fri, 24 Oct 2014 15:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5QtyA6YtjNfZNi 0jrcMpDiA+8RA=; b=g5RAwh47X+5MUG8t5LaIZznKE/zcUdRDiiyC3tl8EExeZz NR4ssXN31RG1YViNcJVN/y9ziYPO+9IwHiz3L46DNnoxfyQJAhoAoGgdhpEAPWQm qrhlZBpvSgBNCvoEGBoDBJRcCfEcj/RGauW5QTJU5TVFEZs+odOg5VB7oFbHA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id BB7D410060; Fri, 24 Oct 2014 15:05:50 -0700 (PDT) Date: Fri, 24 Oct 2014 17:05:50 -0500 From: Nico Williams To: Rick van Rein Message-ID: <20141024220547.GD6185@localhost> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141024213333.GA6185@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZUHXaHtngRHyozxqS3Zw5aQYtSs Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 22:05:53 -0000 I should also add that having KDCs know services' public keys is not a crazy idea. I've been wanting to build a DH-based service keying system where the KDC stores the services public keys and _caches_ the DH shared secret keys in the principal database. Services keep their private keys and realms' public keys and _cache_ their DH shared secret keys. I'm sure you can all see advantages to doing this... For example, recovery from KDC principal database compromise mostly involves distributing new public keys for the compromised realm, at least for service keys (client principal keying is another story, but PKINIT helps there). FYI, Roland Dowdeswell has a Kerberos administration system that uses DH (ECDH) to key services, and even supports multi-party DH for keying clusters (atomically!). Storing service public keys in the KDC is not very farfetched at all. Nico -- From nobody Fri Oct 24 15:08:59 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFED1AC3A6 for ; Fri, 24 Oct 2014 15:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNarI4K5OkTp for ; Fri, 24 Oct 2014 15:08:48 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAA11ABD35 for ; Fri, 24 Oct 2014 15:08:48 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-96-544acdee047f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 81.18.28565.EEDCA445; Fri, 24 Oct 2014 18:08:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9OM8kog020942; Fri, 24 Oct 2014 18:08:46 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9OM8iaA015951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Oct 2014 18:08:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9OM8iLo029879; Fri, 24 Oct 2014 18:08:44 -0400 (EDT) Date: Fri, 24 Oct 2014 18:08:44 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <54402CAC.3010209@mit.edu> Message-ID: References: <54402CAC.3010209@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixG6novv+rFeIwa1eJoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/O/Z8wFO/gqTl2+yNzAeJC7i5GTQ0LARGL353OMELaYxIV7 69m6GLk4hARmM0msP30ZytnIKHG5bT6Uc4hJ4uC5+YwQTgOjxMTTV1hA+lkEtCX6n29iBbHZ BFQkZr7ZyAZiiwgoSvxe+RZsB7OAsMT6czOYQWxhAUOJ5xN+A8U5ODgF1CUWPJcBMXkFHCU6 FkqAVAgJxEismzwNbKKogI7E6v1TwDbxCghKnJz5hAViopbE8unbWCYwCs5CkpqFJLWAkWkV o2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGUFBySvLuYHx3UOkQowAHoxIPr8Fs zxAh1sSy4srcQ4ySHExKoryfT3uFCPEl5adUZiQWZ8QXleakFh9ilOBgVhLh3bANKMebklhZ lVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMFrCYw+IcGi1PTUirTMnBKENBMH J8hwHqDh+86ADC8uSMwtzkyHyJ9iVJQS580GSQiAJDJK8+B6YUnjFaM40CvCvC4gK3iACQeu +xXQYCagwfEbPEAGlyQipKQaGEuOsEnvnn8hwH7uvNdTmgr907asze8ueG9od710bu7xqE2h 5wLZqmfIOb+bKH7TqHXNpTti30sev5XVZT6hHLe4U0r/RIDBGp6IlaJ1em4rn3t0SyQE+8rX LU74Wfln64rpbS6+jIyJKReu9B/8s+z90VOPP7+sCS5nmSTuuPa/fXmmc1PtHyWW4oxEQy3m ouJEAO0d+KP1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wnVMDMyyZqxgvlYAwoAfrGy9k8o Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-iakerb-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 22:08:52 -0000 On Thu, 16 Oct 2014, Greg Hudson wrote: > "tickts" is a typo. > > "Yes, the tags start at 1" might be more professionally stated as "Note > that the tag numbers start at 1." Thanks, patched in my local branch. > "Since the GSS-API acceptor can act as a Kerberos acceptor, it always > has an associated Kerberos realm." This does not follow. To be a > Kerberos acceptor, all you need are some keys to decrypt AP-REQ > authenticators with. You might have keys from multiple realms. There > should be guidance on what to do if the acceptor has no default realm. Well, it has at least one realm that it knows exists. (I guess it need not strictly speaking know where the KDCs for that realm are...) This case where the client needs to resolve an enterprise name but doesn't have a local realm may not be terribly common, so it might be okay to just fail the GSS negotiation at this point. Alternately, the acceptor could pick an arbitrary realm it can accept tickets from. The latter seems to allow things to work in more cases than the former, and I don't think it would make any cases worse than the former, so I'll probably go with the latter. > "(including the generic token framing of the GSSAPI-Token type from > [RFC4121])" should reference RFC 2743, shouldn't it? In 2743, the corresponding type is InitialContextToken, which is why I made that choice. Looking more carefully, it also has SubsequentContextToken ::= innerContextToken ANY so maybe that's less of an issue than I thought. And 4121 refers back to section 3.1 of 2743 as the normative source of the framing, "illustrated by the following pseudo-ASN.1 structures", so I think you're right that 2743 is the right reference. So, "including the generic token framing of the InnerContextToken type from [RFC 2743]", then? -Ben From nobody Sat Oct 25 09:49:32 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC12A1A0383 for ; Sat, 25 Oct 2014 09:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47z_ndmNiDZa for ; Sat, 25 Oct 2014 09:49:29 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C1C1A0072 for ; Sat, 25 Oct 2014 09:49:28 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-75-544bd4977d79 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.56.23365.794DB445; Sat, 25 Oct 2014 12:49:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9PGnQHH000592 for ; Sat, 25 Oct 2014 12:49:27 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9PGnPQJ018451 for ; Sat, 25 Oct 2014 12:49:26 -0400 From: Greg Hudson To: kitten@ietf.org Date: Sat, 25 Oct 2014 12:49:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUixCmqrDv9ineIwetvEhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv3JG9gLbgpVrF/yi7WB8SxfFyMnh4SAicTSHT1sELaYxIV7 64FsLg4hgdlMEisOrGKHcI4zSuxc95oJwulgkrh/qIsdpIVNQFli/f6tLCC2iICwxO6t75hB bGGg+OmmI6wgNouAqsTGrc/A6nkFDCVOb9/IAmELSpyc+QTMZhbQkrjx7yXTBEaeWUhSs5Ck FjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10cvNLNFLTSndxAgOD0n+HYzfDiodYhTgYFTi 4a1g8w4RYk0sK67MPcQoycGkJMornAQU4kvKT6nMSCzOiC8qzUktPsQowcGsJML79QJQjjcl sbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgvfSZaBGwaLU9NSKtMycEoQ0 EwcnyHAeoOF8V0CGFxck5hZnpkPkTzEqSonztoM0C4AkMkrz4Hph8fuKURzoFWHe3yBVPMDY h+t+BTSYCWhw/AYPkMEliQgpqQZG5QyzinPLGa2VS28yJR/zl09Lvnes7YXdP7E9S/fyPd6W cGz/Onb9Gz8SfJ4vep9T+cieMX7qA6vjR/YEzhM/Ij1D6OTraTMufak7Jdja1KCscjdpl+fh PEnOKes6TZ518/NmVr+2SZvs+aHv4a1qx4WbdGI25zbe5X6lpq70JFbh7arFk9mfK7EUZyQa ajEXFScCAC816866AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UWxvvpA7ZbMdnwZ1bn5i-6ad-dA Subject: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 16:49:30 -0000 While working on creating test vectors for CAMMAC using asn1c, I noticed into three issues with the ASN.1 module. Two are just matters of form, but the third will affect the encoding if we decide to change it. I believe we're at a slightly awkward stage of the workflow for this draft, but at least we are still before IETF last call. 1. The ASN.1 module needs IMPORTS declarations for the RFC 4120 types it uses. I have submitted a pull request to Tom's github repository with the necessary import statements. 2. There is no OID in the module declaration. I don't know how important this is in practice, but all of the other Kerberos-related ASN.1 modules I looked at have OIDs. 3. Verifier is defined as an untagged CHOICE with just one initial choice: Verifier ::= CHOICE { mac Verifier-MAC, ... } The last time we used this kind of extensibility was PA-FX-FAST-REQUEST in RFC 6113: PA-FX-FAST-REQUEST ::= CHOICE { armored-data [0] KrbFastArmoredReq, ... } While armored-data has an explicit [0] context tag, Verifier's mac field does not. Therefore, the Verifier-MAC will appear in the DER encoding of Verifier with just its usual sequence tag (universal 0x10). On the positive side, the lack of a context tag here typically saves four bytes per CAMMAC (two for each Verifier). If we never add additional choices to Verifier, the unused extensibility costs us nothing on the wire; the DER encoding looks just like it would if we had directly used Verifier-MAC within AD-CAMMAC. But if we do add additional Verifier choices, there is an implementation constraint. We would likely use context tags for subsequent choices, as it would be an ASN.1 violation to simply add another field with a sequence type. The ASN.1 decoder for Verifier would need to be able to process either a context tag or universal sequence tag. The current MIT krb5 ASN.1 implementation can handle this (we don't make assumptions that choices use context tags; we just match the tag we read against the expected tag of each choice in turn), but I don't know about other implementations. My current preference is to leave this alone, but I wanted to make sure it was discussed explicitly in the working group and doesn't just slip through. Apologies if we discussed this before. From nobody Sun Oct 26 14:19:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CA71A1A3A for ; Sun, 26 Oct 2014 14:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foRmfibKjAhE for ; Sun, 26 Oct 2014 14:19:12 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D851A19F1 for ; Sun, 26 Oct 2014 14:19:10 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-b5-544d654d0222 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A1.1A.09603.D456D445; Sun, 26 Oct 2014 17:19:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9QLJ8AU013806; Sun, 26 Oct 2014 17:19:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9QLJ6wi021627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Oct 2014 17:19:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9QLJ6Mw022116; Sun, 26 Oct 2014 17:19:06 -0400 (EDT) Date: Sun, 26 Oct 2014 17:19:06 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nruub6hti8G43p8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfLhF9aCyaIV+/f9Z21gXCrQxcjJISFgInFhXR8rhC0mceHe erYuRi4OIYHZTBLbH7xjgXA2Mkp8mr6PCcI5xCSx9ccdqLIGRokPLWuZQPpZBLQlvvT1sYHY bAIqEjPfbASzRQQUJX6vfMsIYjMLCEusPzeDGcQWFjCQeL6xkx3E5hQwkli+YjbYHF4BR4lp Jy4DxTmAFhhK9P5MBwmLCuhIrN4/hQWiRFDi5MwnLBAjtSSWT9/GMoFRcBaS1CwkqQWMTKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0LfRyM0v0UlNKNzGCw9JFdQfjhENKhxgFOBiVeHh/LPIJ EWJNLCuuzD3EKMnBpCTK2xfpGyLEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhLfeDCjHm5JYWZVa lA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTB65wC1ChYlJqeWpGWmVOCkGbi4AQZ zgM03A+khre4IDG3ODMdIn+KUVFKnDcRJCEAksgozYPrhaWNV4ziQK8I85qAVPEAUw5c9yug wUxAg42m+YAMLklESEk1MPp6h+XWi+e/fVzREWKx4U9olHbSPOODV5pmB2qsWMR19fiK7U2y T9YsVxXjKlfTXqDGmXXFRUrs2/TF/FcLDvPxPcmfcCaEN3VDSVZq1mfpvn/3bW0kc4qzCows PshxT2XT8SqLUDoyV2Xnc/b9rUk3zkpK5qyxcdy9Z+vOzIOtFqfcN370U2Ipzkg01GIuKk4E AAR/dZ72AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3eK0o1fdnCOVJZRJ2P-8BtfEd5A Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 21:19:15 -0000 On Sat, 25 Oct 2014, Greg Hudson wrote: > While working on creating test vectors for CAMMAC using asn1c, I noticed > into three issues with the ASN.1 module. Two are just matters of form, > but the third will affect the encoding if we decide to change it. I > believe we're at a slightly awkward stage of the workflow for this > draft, but at least we are still before IETF last call. Thanks for bringing these up. > 2. There is no OID in the module declaration. I don't know how > important this is in practice, but all of the other Kerberos-related > ASN.1 modules I looked at have OIDs. What OID arc(s) could we use? > 3. Verifier is defined as an untagged CHOICE with just one initial > choice: > > Verifier ::= CHOICE { > mac Verifier-MAC, > ... > } > > The last time we used this kind of extensibility was PA-FX-FAST-REQUEST > in RFC 6113: > > PA-FX-FAST-REQUEST ::= CHOICE { > armored-data [0] KrbFastArmoredReq, > ... > } > > While armored-data has an explicit [0] context tag, Verifier's mac field > does not. Therefore, the Verifier-MAC will appear in the DER encoding > of Verifier with just its usual sequence tag (universal 0x10). > > On the positive side, the lack of a context tag here typically saves > four bytes per CAMMAC (two for each Verifier). If we never add > additional choices to Verifier, the unused extensibility costs us > nothing on the wire; the DER encoding looks just like it would if we had > directly used Verifier-MAC within AD-CAMMAC. > > But if we do add additional Verifier choices, there is an implementation > constraint. We would likely use context tags for subsequent choices, as > it would be an ASN.1 violation to simply add another field with a > sequence type. The ASN.1 decoder for Verifier would need to be able to > process either a context tag or universal sequence tag. The current MIT > krb5 ASN.1 implementation can handle this (we don't make assumptions > that choices use context tags; we just match the tag we read against the > expected tag of each choice in turn), but I don't know about other > implementations. > > My current preference is to leave this alone, but I wanted to make sure > it was discussed explicitly in the working group and doesn't just slip > through. Apologies if we discussed this before. Do we have any data about whether the Heimdal and Microsoft decoders could handle this situation? It would feel aesthetically unclean to end up in a future situation where a CHOICE has one choice without a context tag and the rest do, but I am as-yet undecided just how bad that is. -Ben From nobody Sun Oct 26 14:33:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3E1A1AAC for ; Sun, 26 Oct 2014 14:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6tHrdDrQhgX for ; Sun, 26 Oct 2014 14:33:20 -0700 (PDT) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2921A1AA6 for ; Sun, 26 Oct 2014 14:33:19 -0700 (PDT) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 2A63A25E9; Sun, 26 Oct 2014 22:33:17 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([127.0.0.1]) by smtp-3.sys.kth.se (smtp-3.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C9sFMlIiIz-P; Sun, 26 Oct 2014 22:33:13 +0100 (CET) X-KTH-Auth: lha [2620:149:4:f01:39de:3315:4204:b8a3] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1414359193; bh=KybtUTbpZF91+Sspu4BDcQd5RIGmv8UqPLZLq4/tMYw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=abqNL/aOcLlNrt9unnDhRfhvYauXnRctwnqVvy4bORFPI3MZYgqNyi0oLi8G0B5BW qHm7j2O6xlNOj0ayDg7YXY4UeCu3infcdIYYn0JRwgNeqIa6f37NZC++guTHf3mowQ +ostrX/VpPRXkUgdMwF/5ZIeDjWqBsiiW6wrEb3g= X-KTH-mail-from: lha@kth.se Received: from [IPv6:2620:149:4:f01:39de:3315:4204:b8a3] (unknown [IPv6:2620:149:4:f01:39de:3315:4204:b8a3]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id F236F25DD; Sun, 26 Oct 2014 22:33:10 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E6227C0-33DF-4AC4-AEB1-BE922C436960" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2052.1\)) From: =?utf-8?Q?Love_H=C3=B6rnquist_=C3=85strand?= In-Reply-To: Date: Sun, 26 Oct 2014 14:33:08 -0700 Message-Id: <6B90B50B-682C-47CC-9FEC-DC4187ACA33E@kth.se> References: To: Benjamin Kaduk X-Mailer: Apple Mail (2.2052.1) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CbUWljxyY9N82lDB_TtyOAFZAcg Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 21:33:23 -0000 --Apple-Mail=_4E6227C0-33DF-4AC4-AEB1-BE922C436960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 26 okt 2014 kl. 14:19 skrev Benjamin Kaduk : >=20 > On Sat, 25 Oct 2014, Greg Hudson wrote: >=20 >> While working on creating test vectors for CAMMAC using asn1c, I = noticed >> into three issues with the ASN.1 module. Two are just matters of = form, >> but the third will affect the encoding if we decide to change it. I >> believe we're at a slightly awkward stage of the workflow for this >> draft, but at least we are still before IETF last call. >=20 > Thanks for bringing these up. >=20 >> 2. There is no OID in the module declaration. I don't know how >> important this is in practice, but all of the other Kerberos-related >> ASN.1 modules I looked at have OIDs. >=20 > What OID arc(s) could we use? >=20 >> 3. Verifier is defined as an untagged CHOICE with just one initial >> choice: >>=20 >> Verifier ::=3D CHOICE { >> mac Verifier-MAC, >> ... >> } >>=20 >> The last time we used this kind of extensibility was = PA-FX-FAST-REQUEST >> in RFC 6113: >>=20 >> PA-FX-FAST-REQUEST ::=3D CHOICE { >> armored-data [0] KrbFastArmoredReq, >> ... >> } >>=20 >> While armored-data has an explicit [0] context tag, Verifier's mac = field >> does not. Therefore, the Verifier-MAC will appear in the DER = encoding >> of Verifier with just its usual sequence tag (universal 0x10). >>=20 >> On the positive side, the lack of a context tag here typically saves >> four bytes per CAMMAC (two for each Verifier). If we never add >> additional choices to Verifier, the unused extensibility costs us >> nothing on the wire; the DER encoding looks just like it would if we = had >> directly used Verifier-MAC within AD-CAMMAC. >>=20 >> But if we do add additional Verifier choices, there is an = implementation >> constraint. We would likely use context tags for subsequent choices, = as >> it would be an ASN.1 violation to simply add another field with a >> sequence type. The ASN.1 decoder for Verifier would need to be able = to >> process either a context tag or universal sequence tag. The current = MIT >> krb5 ASN.1 implementation can handle this (we don't make assumptions >> that choices use context tags; we just match the tag we read against = the >> expected tag of each choice in turn), but I don't know about other >> implementations. >>=20 >> My current preference is to leave this alone, but I wanted to make = sure >> it was discussed explicitly in the working group and doesn't just = slip >> through. Apologies if we discussed this before. >=20 > Do we have any data about whether the Heimdal and Microsoft decoders = could > handle this situation? >=20 > It would feel aesthetically unclean to end up in a future situation = where > a CHOICE has one choice without a context tag and the rest do, but I = am > as-yet undecided just how bad that is. Heimdal compiler handles this fine, the first tag/element needs to be = unique though for the old c-code backend, the new template behaves like = MIT (try to parse each branch of the CHOICE). Love --Apple-Mail=_4E6227C0-33DF-4AC4-AEB1-BE922C436960 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
26 okt 2014 kl. 14:19 skrev Benjamin Kaduk <kaduk@mit.edu>:

On Sat, 25 Oct 2014, Greg Hudson = wrote:

While working on creating test vectors for CAMMAC using = asn1c, I noticed
into three issues with the ASN.1 module. =  Two are just matters of form,
but the third will = affect the encoding if we decide to change it.  I
believe we're at a slightly awkward stage of the workflow for = this
draft, but at least we are still before IETF last = call.

Thanks for bringing these = up.

2. There is no OID in the module declaration.  I = don't know how
important this is in practice, but all of = the other Kerberos-related
ASN.1 modules I looked at have = OIDs.

What OID arc(s) could we = use?

3. Verifier is defined as an untagged CHOICE with just = one initial
choice:

  Verifier =             ::= =3D CHOICE {
        mac =            Verifier= -MAC,
        ...  }

The last time we = used this kind of extensibility was PA-FX-FAST-REQUEST
in = RFC 6113:

  PA-FX-FAST-REQUEST = ::=3D CHOICE {
      armored-data [0] = KrbFastArmoredReq,
      ...
  }

While armored-data = has an explicit [0] context tag, Verifier's mac field
does = not.  Therefore, the Verifier-MAC will appear in the DER = encoding
of Verifier with just its usual sequence tag = (universal 0x10).

On the positive side, the = lack of a context tag here typically saves
four bytes per = CAMMAC (two for each Verifier).  If we never add
additional choices to Verifier, the unused extensibility = costs us
nothing on the wire; the DER encoding looks just = like it would if we had
directly used Verifier-MAC within = AD-CAMMAC.

But if we do add additional = Verifier choices, there is an implementation
constraint. =  We would likely use context tags for subsequent choices, as
it would be an ASN.1 violation to simply add another field = with a
sequence type.  The ASN.1 decoder for Verifier = would need to be able to
process either a context tag or = universal sequence tag.  The current MIT
krb5 ASN.1 = implementation can handle this (we don't make assumptions
that choices use context tags; we just match the tag we read = against the
expected tag of each choice in turn), but I = don't know about other
implementations.

My current preference is to leave this alone, but I wanted to = make sure
it was discussed explicitly in the working group = and doesn't just slip
through.  Apologies if we = discussed this before.

Do we have any data about whether the Heimdal = and Microsoft decoders could
handle this = situation?

It would feel = aesthetically unclean to end up in a future situation where
a CHOICE has one choice without a context tag = and the rest do, but I am
as-yet undecided just how = bad that is.

Heimdal= compiler handles this fine, the first tag/element needs to be unique = though for the old c-code backend, the new template behaves like MIT = (try to parse each branch of the CHOICE).

Love


= --Apple-Mail=_4E6227C0-33DF-4AC4-AEB1-BE922C436960-- From nobody Sun Oct 26 17:57:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967341A1BA2 for ; Sun, 26 Oct 2014 17:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l2goGhzG11Q for ; Sun, 26 Oct 2014 17:57:23 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B1C1A1B98 for ; Sun, 26 Oct 2014 17:57:21 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-70-544d98707849 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id EC.37.23365.0789D445; Sun, 26 Oct 2014 20:57:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9R0vJUw031638; Sun, 26 Oct 2014 20:57:20 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9R0vH5V013519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Oct 2014 20:57:19 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9R0vHDf019239; Sun, 26 Oct 2014 20:57:17 -0400 (EDT) Date: Sun, 26 Oct 2014 20:57:17 -0400 (EDT) From: Benjamin Kaduk To: Shawn M Emery In-Reply-To: <5440B05B.9040408@oracle.com> Message-ID: References: <53D138AC.60702@isode.com> <5440B05B.9040408@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrlswwzfE4OIqOYujm1exWPS9PsTu wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGWsmeFY0MxR8Wl2VAPjTLYuRk4OCQETiRN3 tzJD2GISF+6tB4pzcQgJzGaSaNx7jh3C2cgosXPhWlaQKiGBQ0wSC28lQSQaGCXeNl4GS7AI aEucuP6IHcRmE1CRmPlmI9gKEQEtiRsNHUwgNrOAsMT6czPA1gkL5EhMvzUZLM4JVLNqz3oW EJtXwBHojGVQy1wkDrUsArNFBXQkVu+fAlUjKHFy5hMWiJlaEsunb2OZwCg4C0lqFpLUAkam VYyyKblVurmJmTnFqcm6xcmJeXmpRbomermZJXqpKaWbGEFhyinJv4Px20GlQ4wCHIxKPLwW hb4hQqyJZcWVuYcYJTmYlER5q3qBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4RfOBcrwpiZVV qUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKEry204EaBYtS01Mr0jJzShDSTByc IMN5gIa7gtTwFhck5hZnpkPkTzEqSonzqoMkBEASGaV5cL2wNPKKURzoFWFeVZAqHmAKgut+ BTSYCWiw0TQfkMEliQgpqQbGMFeV4lmBk/9Xf9IujI+Ywv7KTu5qRtTRkzlSyt5L0j/ssVox /4L/jEX1hvdu+G82O+A/+eDfB0zbavXuJ7SUJzKUujzYeJXbyfe8efACZUaf3/oTs4RsNtz6 ICdtl+h4QluNKeNUT9B1ra/XDG91Ne846Bd1JFZmd1jfQ4uutYwh1hc3CNsqsRRnJBpqMRcV JwIAMFKQcP4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/SLvEfgKk_ZHSSRkhQTL1hFvkBKM Cc: kitten@ietf.org Subject: Re: [kitten] Some test registrations according to draft-ietf-kitten-gssapi-extensions-iana-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:57:26 -0000 On Fri, 17 Oct 2014, Shawn M Emery wrote: > > Could folks please review the example registry that we would like to include > in the draft-ietf-kitten-gssapi-extensions-iana draft? > > Thanks, > > Shawn. > -- > On 07/24/14 10:47 AM, Alexey Melnikov wrote: > > > > Bindings: C > > Registration type: Instance > > Object Type: Context-Flag > > Symbol Name: GSS_C_DELEG_FLAG > > Binding of: deleg_state or deleg_req_flag > > Constant Value/Range: 1 > > Description: On output (if set): Delegated credentials are available > > via the delegated_cred_handle > > parameter of GSS_Accept_sec_context/GSS_Init_sec_context. Er, GSS_Init_sec_context does not have a delegated_cred_handle argument. Otherwise, these look fine to me. -Ben > > On input (if set): requests delegation of access rights. > > Registration Rules: N/A > > Reference: RFC 2744 > > Expert Reviewer: Kitten WG > > Expert Review Notes: > > Status: Registered > > Obsoleting Reference: N/A From nobody Mon Oct 27 00:14:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9C11A89C6 for ; Mon, 27 Oct 2014 00:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdA06eaC55bC for ; Mon, 27 Oct 2014 00:14:24 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 664821A89C7 for ; Mon, 27 Oct 2014 00:14:22 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 37DD4318072 for ; Mon, 27 Oct 2014 00:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=p6nyTexANpTNEaJxyjq0GqF1nog=; b=BXDBauJByFn w+lwHBNhXZYAFdn2OuCo+XqYXqfnbTXwpcy05vxlOE+RvVUqcOa5qakb1A/ayFzo /Chug5+8wI/9rK5S6ES9o8h1zUNKivNmdx7sQiluAwOjvI52LQbG6knSADYEoWAy FbUrws4s6wkpn/jEcKEg0Xp7muk4IgnI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id F2E57318064 for ; Mon, 27 Oct 2014 00:14:21 -0700 (PDT) Date: Mon, 27 Oct 2014 02:14:21 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141027071420.GB14215@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7_wWbKDolhmD43d94Na863F-oZw Subject: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 07:14:25 -0000 I'm dropping the LoF/TOFU business for now. It should go into a separate I-D. This simplifies the PKCROSS I-D a fair bit. Update just submitted. Nico -- From nobody Mon Oct 27 00:17:08 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086921A89C6 for ; Mon, 27 Oct 2014 00:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7b9LJwheG0Q for ; Mon, 27 Oct 2014 00:17:06 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8E21A89C7 for ; Mon, 27 Oct 2014 00:17:06 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id DF8AB2AC06E; Mon, 27 Oct 2014 00:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=2gc/EYcg9wUDDRC9uzOK1jgI6fY=; b=dIvkuEI2pd2 tMxtLL5m+G8l4jBrdvQiwBt0jodBL83n5H2v/bJ5XtPfI2mUNdJJJlKXl1kyuT44 VAhOmoAUf8rdktAuLFtRc/aucwRPmV81SP0Ir5S2T/qu7ixafAAAcGW7ZDk0+JAL tjZjrSDaLiMQ2p8xFOllR7eOG7zuyid8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id A75D62AC064; Mon, 27 Oct 2014 00:17:05 -0700 (PDT) Date: Mon, 27 Oct 2014 02:17:05 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141027071704.GC14215@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kzeFP1WBodBNG3fQ80N-pn3MGwM Subject: [kitten] Kerberos extra round trips I-D revised X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 07:17:07 -0000 ----- Forwarded message from internet-drafts@ietf.org ----- A new version of I-D, draft-williams-kitten-krb5-extra-rt-02.txt has been successfully submitted by Nicolas Williams and posted to the IETF repository. Name: draft-williams-kitten-krb5-extra-rt Revision: 02 Title: Negotiation of Extra Security Context Tokens for Kerberos V5 Generic Security Services Mechanism Document date: 2014-10-27 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-williams-kitten-krb5-extra-rt-02.txt Status: https://datatracker.ietf.org/doc/draft-williams-kitten-krb5-extra-rt/ Htmlized: http://tools.ietf.org/html/draft-williams-kitten-krb5-extra-rt-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-kitten-krb5-extra-rt-02 Abstract: This Internet-Draft proposes an extension to the Kerberos V5 security mechanism for the Generic Security Services Application Programming Interface (GSS-API) for using extra security context tokens in order to recover from certain errors. Other benefits include: user-to-user authentication, authenticated errors, replay cache avoidance, and others. ----- End forwarded message ----- From nobody Mon Oct 27 08:20:02 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8D21A888E for ; Mon, 27 Oct 2014 08:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwXoNuPEM0qL for ; Mon, 27 Oct 2014 08:19:16 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA321ACDE8 for ; Mon, 27 Oct 2014 08:19:11 -0700 (PDT) X-AuditID: 1209190e-f79d46d000003643-83-544e626eca8e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 38.47.13891.E626E445; Mon, 27 Oct 2014 11:19:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9RFJ4Qe026459; Mon, 27 Oct 2014 11:19:04 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RFJ2Mf025890; Mon, 27 Oct 2014 11:19:03 -0400 From: Tom Yu To: Benjamin Kaduk References: Date: Mon, 27 Oct 2014 11:19:02 -0400 In-Reply-To: (Benjamin Kaduk's message of "Sun, 26 Oct 2014 17:19:06 -0400") Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixG6nopuX5BdisHm3ksXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0fjqBnvBPuaKPxuvMDcwPmDqYuTkkBAwkVh7biErhC0mceHe erYuRi4OIYHZTBITVv1hhnA2Mkp8enCNCcJ5wyixY/lVdpAWNgFpieOXd4GNEhFQklh8toUN xGYGGjvv5A9GEFtYwEDi+cZOsHohgUyJ1TNXMoPYLAKqEo8WnGIFGcop0MIoMfHxbrAGXgFd iVUHloPdxCPAIbH3zglWiLigxMmZT1ggFmhJ3Pj3kmkCo8AsJKlZSFILGJlWMcqm5Fbp5iZm 5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5iBAUgpyTfDsavB5UOMQpwMCrx8E4o9g0RYk0sK67M PcQoycGkJMo7NdYvRIgvKT+lMiOxOCO+qDQntfgQowQHs5II76kAoBxvSmJlVWpRPkxKmoNF SZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTv0kSgRsGi1PTUirTMnBKENBMHJ8hwHqDht0Fq eIsLEnOLM9Mh8qcYdTlamt72Mgmx5OXnpUqJ814EKRIAKcoozYObA0scrxjFgd4S5q0GqeIB Jh24Sa+AljABLTGa5gOypCQRISXVwDiRjXm/f/UX3+UfchbZip9VvObDWrK5RKx/TdyPW69D 5svLbxfMmsO4uoHvSILtozcLBEXfdS+VuPzOofGenPDmz1vb09SbfwppB028KzYt64mKeOnD c0sckst87z7/dXbFKzWXj9bHjvC4a9+5+SxhU7GO4ZOJO+5Muqi+a/UB9Y2qz99xFGxUYinO SDTUYi4qTgQAqj71n/cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/M4UMK6vBIOCylMYVtKAVhYrEbE8 Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:19:18 -0000 Benjamin Kaduk writes: > It would feel aesthetically unclean to end up in a future situation where > a CHOICE has one choice without a context tag and the rest do, but I am > as-yet undecided just how bad that is. I think we might have talked about this, but am not certain. I think omitting a context tag on the first branch of the CHOICE is probably harmless and saves some bytes in the encoding in the common case. From nobody Mon Oct 27 08:25:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CC11A8897 for ; Mon, 27 Oct 2014 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcHLlWQSpBvv for ; Mon, 27 Oct 2014 08:25:23 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1A41A888E for ; Mon, 27 Oct 2014 08:25:22 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-42-544e63e16060 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id CC.A8.28565.1E36E445; Mon, 27 Oct 2014 11:25:21 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9RFPG0A008927; Mon, 27 Oct 2014 11:25:16 -0400 Received: from [18.101.8.220] (vpn-18-101-8-220.mit.edu [18.101.8.220]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RFPEkw028284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 11:25:15 -0400 Message-ID: <544E63DA.2030102@mit.edu> Date: Mon, 27 Oct 2014 11:25:14 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <54402CAC.3010209@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrfsw2S/EoOGGjcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8f3aHLaC3RwVN3t72RsY77B1MXJySAiYSJxf+J0RwhaTuHBv PVCci0NIYDaTxNcNz5kgnI2MEm/mHmOHcI4wSfRvOMQM0sIroCZxa2ozC4jNIqAq0dGyFSzO JqAssX7/VqA4B4eoQJjE1KU8EOWCEidnPgErFxFQklh8tgXsCmYBYYkL2/eygtjCAoYSzyf8 ZoTYNYlRYvXDDrCZnAJOEt0dk6Ea9CR2XP/FCmHLS2x/O4d5AqPgLCQ7ZiEpm4WkbAEj8ypG 2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTSTYzgcJXk3cH47qDSIUYBDkYlHt4Jxb4h QqyJZcWVuYcYJTmYlER5p8b6hQjxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4T0VAJTjTUmsrEot yodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgnZIE1ChYlJqeWpGWmVOCkGbi4AQZ zgM0vBekhre4IDG3ODMdIn+KUVFKnPdiIlBCACSRUZoH1wtLJ68YxYFeEebNA2nnAaYiuO5X QIOZgAYbTfMBGVySiJCSamCM4GANkdyeHjtp16yETE3n0IMyqyK+PC5XNItetXnygrTOYKFb C59db8lz2a6w0+6C9+QNkXduPRMyT+ItrTy3VkuNaferjEs9CS832/7Mk3lQMSlpymaT2R3i kYGLgjsk6s8JJ688cqvs3tFjP6z1Wh7ucdvV0lanPkn4Xiv3wRL+dw7bsyOUWIozEg21mIuK EwHdIzYCAgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Nro0czY4sM8LJJzFAuSx4XIRmV0 Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-iakerb-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:25:25 -0000 On 10/24/2014 06:08 PM, Benjamin Kaduk wrote: > Well, it has at least one realm that it knows exists. (I guess it need > not strictly speaking know where the KDCs for that realm are...) This > case where the client needs to resolve an enterprise name but doesn't have > a local realm may not be terribly common, so it might be okay to just fail > the GSS negotiation at this point. Alternately, the acceptor could pick > an arbitrary realm it can accept tickets from. The latter seems to allow > things to work in more cases than the former, and I don't think it would > make any cases worse than the former, so I'll probably go with the latter. As an implementor, I would generally want to just call krb5_get_default_realm() and return an error if that fails. But the RFC should say what error to return. (I don't think MIT krb5 currently implements this part of IAKERB, since it wasn't present in the earlier draft that we used.) > So, "including the generic token framing of the InnerContextToken type > from [RFC 2743]", then? I think that's right. From nobody Mon Oct 27 10:26:57 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BB01A6FF6 for ; Mon, 27 Oct 2014 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbiRh4aqo_Q7 for ; Mon, 27 Oct 2014 10:26:53 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CF2121A0187 for ; Mon, 27 Oct 2014 10:26:53 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 8BEFF67406A for ; Mon, 27 Oct 2014 10:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CV5mAHx3Ep8e2K+8At2u cFHU348=; b=fS+f5rR04vGA51SGjATr8229ECkM/sgxd6Z9/2BcYdseQljVciSV /EEOiX6fdNMyzDGQY7nSmUrEULe2ZbSKKelv5ma0m18/LTCtfMwIq6oZrw3q+S4Z IfnqEpmc+cEs224nypCMhTkNb7KWRTPorqFmMPeWJQHoDGeDnwyy8Ek= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 2EAAF674059 for ; Mon, 27 Oct 2014 10:26:52 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ex7so7061956wid.6 for ; Mon, 27 Oct 2014 10:26:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.190.130 with SMTP id gq2mr23652954wjc.18.1414430811528; Mon, 27 Oct 2014 10:26:51 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Mon, 27 Oct 2014 10:26:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Oct 2014 12:26:51 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/QjuBdPfRA6rMbLeTLI1oT59tQnk Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-iakerb-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:26:54 -0000 The best counter-measure against attacks on DNS SRV RR lookups is to use FAST for the AS exchange, and preferably for TGS exchanges as well. Nit: section 6 is slightly incorrect as to not using FAST: it doesn't expose PA-ENC-TIMESTAMP if... it's not used because the client uses -say- PKINIT. Nico -- From nobody Mon Oct 27 10:28:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E1C1A016B for ; Mon, 27 Oct 2014 10:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c5NxUoP96pC for ; Mon, 27 Oct 2014 10:28:18 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9F51A1A25 for ; Mon, 27 Oct 2014 10:28:14 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 9D4C4BBA13F for ; Mon, 27 Oct 2014 10:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5JUqLEqgSGut5kRAxmEu ronnPpQ=; b=IZ08YjMqNcXzX+mMDaDf+WG8GBTTbSW3pEupRhAsIzS0XpXDVHg8 g3veMSJbLPShk/LeoDnlmv4I9NOpCrMqGB3bHUI2sR9FuzRlnXDoDkXEp//scCsv tKRNWQRbrCjidvc/K4VInlsyw7POXL9GMLxg1mChcw94+PKBLSLfTQA= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 86B74BBA0BC for ; Mon, 27 Oct 2014 09:30:16 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id z12so3598776wgg.9 for ; Mon, 27 Oct 2014 09:30:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.240.68 with SMTP id vy4mr24076060wjc.36.1414427415263; Mon, 27 Oct 2014 09:30:15 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Mon, 27 Oct 2014 09:30:15 -0700 (PDT) In-Reply-To: <544E63DA.2030102@mit.edu> References: <54402CAC.3010209@mit.edu> <544E63DA.2030102@mit.edu> Date: Mon, 27 Oct 2014 11:30:15 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4BsWLdK52hG3iWjocMbqsyXJbak Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-iakerb-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:28:19 -0000 On Mon, Oct 27, 2014 at 10:25 AM, Greg Hudson wrote: > On 10/24/2014 06:08 PM, Benjamin Kaduk wrote: >> Well, it has at least one realm that it knows exists. (I guess it need The only methods of determining an acceptor's realm, available to an IAKERB initiator, are: - referrals, starting with either or all of (in sequence) the client principal's realm, or any other realm that the initiator might have knowledge of - a resolver-style "search" of domain-style realms for a given hostname (presumably with FAST for each TGS exchange to protect the integrity of KRB-ERRORs) Note that the KRB_AP_ERR_IAKERB_KDC_NOT_FOUND and KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE errors cannot be protected. If this error results during a resolver-style search, the initiator should stop searching. Question: presumably KRB_AP_ERR_IAKERB_* do not terminate the security context exchange, and GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED in those cases? Although there should probably be a maximum number of context tokens that the acceptor is willing to exchange, past which it will need to return GSS_S_FAILURE, and then how is _that_ communicated to the initiator?? (It might have been nice to have DNS TXT/whatever RRs for determining target host principals' realms, and to proxy DNS[SEC] lookups in IAKERB. However, that seems like a lot of work.) >> not strictly speaking know where the KDCs for that realm are...) This >> case where the client needs to resolve an enterprise name but doesn't have >> a local realm may not be terribly common, so it might be okay to just fail >> the GSS negotiation at this point. Alternately, the acceptor could pick >> an arbitrary realm it can accept tickets from. The latter seems to allow >> things to work in more cases than the former, and I don't think it would >> make any cases worse than the former, so I'll probably go with the latter. I agree: the latter. > As an implementor, I would generally want to just call > krb5_get_default_realm() and return an error if that fails. But the RFC > should say what error to return. Hmmm. Is there a standard notion of "default realm"? We've seen a number of cases where there's no configured default realm, where an acceptor might have keys for principals in multiple realms, and so on. I'd rather say that the initiator can use a zero-length realm to indicate "I don't know where to send this" and the acceptor should substitute a realm of its choice. If the acceptor has many realms... then the above question once more arises as to how we know when a KRB-ERROR denotes that GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED versus when it returns GSS_S_FAILURE. > (I don't think MIT krb5 currently implements this part of IAKERB, since > it wasn't present in the earlier draft that we used.) Sure, but we're designing a protocol as much as documenting reality :) >> So, "including the generic token framing of the InnerContextToken type >> from [RFC 2743]", then? > > I think that's right. *sigh* Sure. Nico -- From nobody Mon Oct 27 11:14:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5671A038C for ; Mon, 27 Oct 2014 11:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6k-M9QJCHtv for ; Mon, 27 Oct 2014 11:14:00 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0661A0194 for ; Mon, 27 Oct 2014 11:14:00 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-37-544e8b665991 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 28.D7.28565.66B8E445; Mon, 27 Oct 2014 14:13:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9RIDwRZ001750; Mon, 27 Oct 2014 14:13:58 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RIDupZ026969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Oct 2014 14:13:57 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9RIDtAT027816; Mon, 27 Oct 2014 14:13:55 -0400 (EDT) Date: Mon, 27 Oct 2014 14:13:55 -0400 (EDT) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> Message-ID: References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-652476996-1414430734=:27826" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrZvW7RdisP+MlcXRzatYLJ6+usfm wOSxZMlPJo8N/5rYApiiuGxSUnMyy1KL9O0SuDIOdh9mKTjBW9HQ+patgXECdxcjJ4eEgIlE w4zpTBC2mMSFe+vZuhi5OIQEZjNJPPnwngXC2cgoce/HcSYI5xCTxJKVX5ghnAZGic4lu1lA +lkEtCUm7tjKBmKzCahIzHyzEcwWEdCQ+PxrKpjNLCAssf7cDGYQW1jATmL75a3sIDangLPE of8Qd/AKOErM+tLJCmILCThJnPj+FiwuKqAjsXr/FBaIGkGJkzOfsEDMDJBY8+kkM4TtKNH8 5BX7BEahWUjKZiEpm4WkDMLWkbg5YzEbhK0tcf9mGxtMTd/U6cwLGNlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Rrp5WaW6KWmlG5iBEeJJO8OxncHlQ4xCnAwKvHwTij2DRFiTSwrrsw9xCjJ waQkypte4BcixJeUn1KZkVicEV9UmpNafIhRgoNZSYT3QBpQjjclsbIqtSgfJiXNwaIkzrvp B1+IkEB6YklqdmpqQWoRTFaGg0NJgndaF1CjYFFqempFWmZOCUKaiYMTZDgP0PDtIDW8xQWJ ucWZ6RD5U4yKUuK8W0ESAiCJjNI8uF5YEnvFKA70ijDvJZAqHmAChOt+BTSYCWiw0TQfkMEl iQgpqQZG7qOnzNlKNxyKX/fk+9nvr9ZLbhbumryJ94tORVLLlHea6zgq+7lmzND8yMMmOul2 yt5KP/dpbzPnSHywdP194WvVhXmpETPvdVSe83f8/0x7m9rxt6W+ez7cUClJvrfwmSmXv4ah 9443u+7mXl7K2Ojt5t1q+nBezYZQt1KWkKCGe5/EjPodlFiKMxINtZiLihMBCLJTFT0DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lGz1SijD9cgu_rq1uaC0TCGh10E Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:14:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-652476996-1414430734=:27826 Content-Type: TEXT/PLAIN; charset=ISO-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Sun, 19 Oct 2014, Rick van Rein wrote: > Hello, > > After a discussion on kerberos@mit.edu about the TXT records that never m= ade it into a standard, we realised that the recent success of DNSSEC provi= des a new opportunity for this dnsname-to-realmname mapping. Below is a pr= oposal to that end. > > Title: Finding the Kerberos Realm of a Service in DNS > Draft: draft-vanrein-dnstxt-krb1-00 > Location: http://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/ > > This is part of my endeavour to move Kerberos towards realm crossover, fo= r which finding a service=A2s realmname can be all but trivial. > > Any comments on this are highly appreciated! It might be good to also solicit feedback from the DNS types; I'm not actually sure if that means dnsop@ietf.org or somewhere else. (I am not a DNS type, so my comments will be limited in scope.) In section 4, does "the client MUST dismiss any DNS responses that are not Insecure, Bogus or Indeterminite" have an extra 'not'? I don't really understand the case-mapping text in the second paragraph of section 6.1 (there don't seem to be any examples that use it). Also in 6.1, I don't think the phrase "it is useless to lookup a Kerberos ticket for ftp.example.com" is a valid use of "kerberos ticket". "multilple" is a typo -Ben ---559023410-652476996-1414430734=:27826-- From nobody Mon Oct 27 11:48:35 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259611A8A72 for ; Mon, 27 Oct 2014 11:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePIkgPy3DSmS for ; Mon, 27 Oct 2014 11:48:09 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB791ACEDE for ; Mon, 27 Oct 2014 11:46:27 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-54-544e9302875e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id AA.84.09603.2039E445; Mon, 27 Oct 2014 14:46:26 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9RIkP7M006649; Mon, 27 Oct 2014 14:46:26 -0400 Received: from [18.101.8.220] (vpn-18-101-8-220.mit.edu [18.101.8.220]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RIkNBB007482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 14:46:24 -0400 Message-ID: <544E92FF.605@mit.edu> Date: Mon, 27 Oct 2014 14:46:23 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams , Rick van Rein References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> In-Reply-To: <20141024213333.GA6185@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrcs02S/E4PlMOYujm1exWJy6doTN 4umre2wOzB4vT51j9Fiy5CeTx4Z/TWwBzFFcNimpOZllqUX6dglcGSu2XGAsOMZRcXHmMtYG xldsXYycHBICJhIbzi9lhbDFJC7cWw8U5+IQEpjNJPFt3x5GCGcjo8TMvYfYIZwjTBJ9F6Yy g7TwCihJHH7RA9bOIqAqsejtdTCbTUBZYv3+rSxdjBwcogJhElOX8kCUC0qcnPmEBcQWEYiQ mLl8JytICbOAusTO3cwgprBAusTHHR4gppBAisS54xIgxZwCehKHp1wCm80MZO+4/gvKlpdo 3jqbeQKj4Cwk82chKZuFpGwBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXQu93MwSvdSU0k2M oHBmd1HdwTjhkNIhRgEORiUe3gnFviFCrIllxZW5hxglOZiURHndJvqFCPEl5adUZiQWZ8QX leakFh9ilOBgVhLhPZAGlONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQ kuC9DjJUsCg1PbUiLTOnBCHNxMEJMpwHaPhfkBre4oLE3OLMdIj8KUZFKXFeZpCEAEgiozQP rheWbl4xigO9Isx7C6SKB5iq4LpfAQ1mAhpsNM0HZHBJIkJKqoGxc1L165r0P4nGhy9Yqek+ +PPaSNw2oqM4YLZIo3ztkVK3SRFpDA/8qhW+1tcca7sw3a+fXWgJa0ZdZ95dyQd6T/51fMrb +Cpd6E7TPS21gHpR7uPHf/rNyRQ97LOes6pO40ABb9NDp5efvmgYGXzKOnO+vjl3XV2lvRhv Xsy7UyEWH49lJCmxFGckGmoxFxUnAgB5E3vwEgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fiYIeh3lxvI08rVPvXz1eE-FVqQ Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:48:11 -0000 On 10/24/2014 05:33 PM, Nico Williams wrote: > - if the KDC knows the services' supported DH curves then it might as > well know the service's public keys too! I don't follow this step. If the KDC knows the server's "DH public key" (g^y for integer DH), that implies that the server is going to use the same "DH private key" (y) for as long as the KDC is giving out that key. But forward secrecy depends on discarding private keys often enough that a future compromise of either party doesn't give access to the private key used for past exchanges. You can reuse a private key for multiple exchanges, but you can't keep using it for longer than you generally expect sessions to last (i.e. at most hours, not days or weeks). My understanding is that Rick's entire purpose here is to get forward secrecy in AP exchanges. Synchronizing public keys between servers and KDCs would seem to harm that goal. It's much easier (although still not trivial) to keep the KDC informed of algorithm support than it is to keep the KDC informed of a frequently-changing public key. From nobody Mon Oct 27 12:14:51 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41641A890A for ; Mon, 27 Oct 2014 12:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60OVLrEbyR4P for ; Mon, 27 Oct 2014 12:14:16 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911D31A89B9 for ; Mon, 27 Oct 2014 12:13:50 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-8e-544e996d2e1b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 27.0E.23365.D699E445; Mon, 27 Oct 2014 15:13:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9RJDmff028567; Mon, 27 Oct 2014 15:13:49 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RJDk0m017968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Oct 2014 15:13:48 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9RJDk4i005232; Mon, 27 Oct 2014 15:13:46 -0400 (EDT) Date: Mon, 27 Oct 2014 15:13:46 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141024213333.GA6185@localhost> Message-ID: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nops70y/E4FaznMXRzatYLE5dO8Jm 8fTVPTYHZo+Xp84xeixZ8pPJY8O/JrYA5igum5TUnMyy1CJ9uwSujK+X/zIXnOau+L/oHGMD YyNnFyMnh4SAicSyRX1sELaYxIV764FsLg4hgdlMEjdv72WBcDYySlxvOsAI4Rxikvj6az07 hNPAKHGpbwkjSD+LgLbEsvMP2UFsNgEViZlvNoLNFRHQlLg+bymYzSzgK/Hv5xkmEFtYIF1i 55EtYDangJ7E4SmXWLsY2Tl4BRwlXuR3MXIAjU+ROHdcAqRAVEBHYvX+KSwgNq+AoMTJmU9Y IAZqSSyfvo1lAqPgLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6OVmluilppRu YgSFLqck/w7GbweVDjEKcDAq8fBaFPqGCLEmlhVX5h5ilORgUhLldZvoFyLEl5SfUpmRWJwR X1Sak1p8iFGCg1lJhPdAGlCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaD Q0mCt3gGUKNgUWp6akVaZk4JQpqJgxNkOA/Q8NMgNbzFBYm5xZnpEPlTjIpS4rxLQRICIImM 0jy4XlhqecUoDvSKMO8KkCoeYFqC634FNJgJaLDRNB+QwSWJCCmpBsaYiEhVp6nxdWUph16p t+5e/YDFulfnp/nSfVvWP5cXOha263qp2MlUI19N83W/u4wvlcYzdUxsYUwvk6medPX13ZP2 2778Pbj6mnN5xaT38lU6xqF3n8SrClc8jzZ9tLk7LvF0lCjHs5m52+7/f9mqV25vFKKwetVf WZUou560xl2dawpsPJVYijMSDbWYi4oTAWvNLGUIAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/iA33UAgwyygKGJsiogfw4IOgVos Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 19:14:22 -0000 Cherry-picking minor notes... On Fri, 24 Oct 2014, Nico Williams wrote: > On Sat, Oct 11, 2014 at 09:30:16PM +0200, Rick van Rein wrote: > > I just posted a new I-D that introduces a DH subkey mechanism for Kerberos. > > IMO we should adopt a work item for this feature. [Puts on chair hat] Noted, thanks. [takes off chair hat] > - if the KDC knows the services' supported DH curves but not its public > keys then... we need to extend KDC-REP to convey this info I think it might be very complicated to try to manage this information in the KDB. > - just because we want proper PFS doesn't mean we must do a full DH > exchange in every AP exchange: we could do something like TLS > resumption: the service should return a short-lived Ticket (minted by > the service) > > Let's call this "fast re-auth tickets". Other uses include: This has the potential to be a pretty heavyweight protocol/code modification. I'm not sure that we have the collective energy to do so (comparatively, TLS has a lot more effort focused on it). > - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS forward secrecy relies on both parties discarding the ephemeral values; I'm not sure that the GSSAPI will be able to effectively enforce that. (Not that we shouldn't have a flag to request this sort of thing and indicate that it was used, just that such a ret_flag may not be as strong a guarantee as we want.) -Ben From nobody Mon Oct 27 12:29:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCAC1AD244 for ; Mon, 27 Oct 2014 12:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceHMP5dNBaPW for ; Mon, 27 Oct 2014 12:28:45 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 013381AD0D1 for ; Mon, 27 Oct 2014 12:28:43 -0700 (PDT) X-AuditID: 12074422-f79436d000000c21-34-544e9ceadac2 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 12.70.03105.AEC9E445; Mon, 27 Oct 2014 15:28:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9RJSgmI030625; Mon, 27 Oct 2014 15:28:42 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RJSe3Y023740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Oct 2014 15:28:41 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9RJSdjB007115; Mon, 27 Oct 2014 15:28:39 -0400 (EDT) Date: Mon, 27 Oct 2014 15:28:39 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <450288760.45834.1413939164862.JavaMail.yahoo@jws10666.mail.bf1.yahoo.com> Message-ID: References: <5446E8ED.6070200@oracle.com> <450288760.45834.1413939164862.JavaMail.yahoo@jws10666.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1392203321-1414438119=:27826" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixG6novt6jl+Iwf+LzBZHN69iseh7fYjd 4lvXdWYHZo8lS34yeXx8eovFY9asw0wBzFFcNimpOZllqUX6dglcGS9+9LAXbGGvOLt4J1MD YydbFyMnh4SAicTKPYugbDGJC/fWA9lcHEICs5kknh6cxQjhbGSUaFl9mRXCOcQk0bLgE1Sm gVHiy+N3LCD9LALaElsPT2YFsdkEVCRmvtkINIuDQ0RAXaL5uzdImFkgQuL9je9gJcICuRJv /71gB7E5BcIlLl09wgJSzivgKLF3lylIWEigRKJz0WtGEFtUQEdi9f4pYJt4BQQlTs58AlbO LBAocfp27ARGwVlIMrMQMrPA9qpLHPh0kRHC1pa4f7ONbQEjyypG2ZTcKt3cxMyc4tRk3eLk xLy81CJdU73czBK91JTSTYzgQHdR2sH486DSIUYBDkYlHt4Jxb4hQqyJZcWVuYcYJTmYlER5 3Sb6hQjxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4T2QBpTjTUmsrEotyodJSXOwKInzbvrBFyIk kJ5YkpqdmlqQWgSTleHgUJLgrZ4N1ChYlJqeWpGWmVOCkGbi4AQZzgM0fB5IDW9xQWJucWY6 RP4Uoy5HS9PbXiYhlrz8vFQpcYhBAiBFGaV5cHNgCeoVozjQW8K8lSBVPMDkBjfpFdASJqAl RtN8QJaUJCKkpBoYuQV7xRL8Hu9d8VBx6oGQvguqwbx7/fkrzy+RDa5703zY0ivx0tHLPmzb f2uJT/nwal6sY1t4J6vzlfxd3+Zm6r77erW5KXn1tPfps/7F19191hK88PB8ja/uG0LmfGmQ PivQMe/2ddtZP2ufa70I3HrUWyBCy7GxvYJRS+iE30Wu7blTDRffU2Ipzkg01GIuKk4EAOlZ 5t0rAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/iZmWdC7ElwP-UpO3s8iym2uFqRY Cc: "kitten@ietf.org" Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 19:28:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1392203321-1414438119=:27826 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 21 Oct 2014, Bill Mills wrote: > how does the inclusion of working drafts rather than finished drafts > affect the process? =C2=A0Inclusion of the dynamic registration stuff wou= ld > do that. To some extent it depends on the specifics; if I understand correctly, in the general case, if draft A makes a normative reference to draft B, then draft A can be approved by the IESG for publication, but does not get actually published by the RFC Editor until draft B is also approved, so they get published in the same batch. Such a dependency wouldn't necessarily hold up our WG work on it. -Ben ---559023410-1392203321-1414438119=:27826-- From nobody Mon Oct 27 12:31:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D491AD070 for ; Mon, 27 Oct 2014 12:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf6J8Hmx7dt3 for ; Mon, 27 Oct 2014 12:31:24 -0700 (PDT) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA7191AD244 for ; Mon, 27 Oct 2014 12:31:24 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id s9RJVNHi005631 for ; Mon, 27 Oct 2014 12:31:24 -0700 Received: from vpn-135-70-102-204.vpn.swst.att.com ([135.70.102.204]) by maillennium.att.com (mailgw1) with ESMTP id <20141027193123gw100r93bne>; Mon, 27 Oct 2014 19:31:23 +0000 X-Originating-IP: [135.70.102.204] Message-ID: <544E9D89.5060704@att.com> Date: Mon, 27 Oct 2014 15:31:21 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> <53D18F6F.1060204@att.com> <53E47603.3080302@oracle.com> <53E58D77.1020100@att.com> <20140809110713.0955eff3@latte.josefsson.org> In-Reply-To: <20140809110713.0955eff3@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EZu4GlubBX6t0ZAm6xm6FYTD53U Subject: [kitten] draft-hansen-scram-sha256-02 posted X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 19:31:29 -0000 I've updated draft-hansen-scram-sha256. I left the minimum iteration count at 4096. I left it as IESG review. I would like to send this to the Security ADs, who have previously indicated that one of them would be willing to support it. This process would go smoother if there were a document shepherd. Is anyone on this mailing list willing to act as document shepherd? Tony From nobody Mon Oct 27 13:04:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20031A03E1 for ; Mon, 27 Oct 2014 13:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZdLSOs7ETa9 for ; Mon, 27 Oct 2014 13:03:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711111A03A4 for ; Mon, 27 Oct 2014 13:03:37 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9RK3aUW003806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 27 Oct 2014 16:03:36 -0400 Received: from willson.usersys.redhat.com (ovpn-113-127.phx2.redhat.com [10.3.113.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9RK3YRl013554 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 Oct 2014 16:03:35 -0400 Date: Mon, 27 Oct 2014 16:03:32 -0400 From: Simo Sorce To: Greg Hudson Message-ID: <20141027160332.6adefb08@willson.usersys.redhat.com> In-Reply-To: <544E92FF.605@mit.edu> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> <544E92FF.605@mit.edu> Organization: Red Hat, Inc MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/270kj16IpmM51VXWnB6lmEoUfzk Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:03:40 -0000 On Mon, 27 Oct 2014 14:46:23 -0400 Greg Hudson wrote: > On 10/24/2014 05:33 PM, Nico Williams wrote: > > - if the KDC knows the services' supported DH curves then it might > > as well know the service's public keys too! > > I don't follow this step. If the KDC knows the server's "DH public > key" (g^y for integer DH), that implies that the server is going to > use the same "DH private key" (y) for as long as the KDC is giving > out that key. But forward secrecy depends on discarding private keys > often enough that a future compromise of either party doesn't give > access to the private key used for past exchanges. You can reuse a > private key for multiple exchanges, but you can't keep using it for > longer than you generally expect sessions to last (i.e. at most > hours, not days or weeks). > > My understanding is that Rick's entire purpose here is to get forward > secrecy in AP exchanges. Synchronizing public keys between servers > and KDCs would seem to harm that goal. It's much easier (although > still not trivial) to keep the KDC informed of algorithm support than > it is to keep the KDC informed of a frequently-changing public key. Same understanding here. Storing the keys in the KDB, not only would be a problem management-wise it would strongly weaken the very feature we are after (Forward Secrecy) by forcing the Service to keep private keys stored somewhere as the service will now have to be able to address the case where the service is restarted but the client has already obtained the hint from the KDC. Ideally a server running in a single server should be able to keep keys only in memory and regenerate them when restarted. Of course there needs to also be a way to store and even share among peer services the same private key for those cases where clustering is desired, but that's out of the scope of this ID I would think. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Mon Oct 27 13:27:37 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29E81AD468 for ; Mon, 27 Oct 2014 13:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMEv1SadadEF for ; Mon, 27 Oct 2014 13:27:20 -0700 (PDT) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C8F1AD46C for ; Mon, 27 Oct 2014 13:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414441639; bh=mid6G4QeFL/p6o2M+eQbjWMRaqbLkn9QRwkynj7Hp4I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=dhfIiNnrBtPNFryjbHTWnM018C1PiChvnUqmKbpNoOp4bbhSb0qmfqPbehHtYIXQ4X5omz4cEpMzfTOs+DS6YrWUVcLCOA+cUplldJx4zCsWa5DTVxMEBZ1wlS2rZdegwJ7QkkFcfaeu03PybLLK2cQi2t/khh5OX8r2RpPDyO0njf+/++bZiBRP6PvY3HPGiyn+Fq7ETA+DmZHTWThW2vqB39tmLd9WNzQFILfxaofmSTA36DMyM6F3ydvveUZBHaVaW4uCxIbsr2UkAZMRsuJROTlMIkRxyCXedWQKHbkUllWY5EhSyyDSkPbO85tsfPVPuLlg8SyBt37xZd5WDA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=MCnP4AFuxB7CR95+AKlnlWCVJX96kK0ovzhaUdxe7HVUu8MLVFJXf7zLNkFP4XUtgRMqFfztUIIuLbLWCdw+uLNyIc0SAcCbSVc9UER6CgHFDTfbGl/JkTTmcz2koKAVDrp6ANgxz6zi7ruk9dc7FOUjtRmVr0RODWu/WIa5D3fUe7CZ1+7vvOLLqtPVk5HtKj3ByCDGSOYZqkaRpjoW8XEy6fOS0Vs4SoOhH0vpp20pY1FuuOCY9GT/hthqZKme3VR4fjpiFO4ZHFct+FAqDiug9NX/KUixKt+mowWN8nJhmbLqUCilz6xl4bxwOCKALwZRyB5UQqoFHfZRhltk3Q==; Received: from [98.139.214.32] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2014 20:27:19 -0000 Received: from [98.139.212.193] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2014 20:27:19 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 27 Oct 2014 20:27:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 596994.86650.bm@omp1002.mail.bf1.yahoo.com Received: by 66.196.81.104; Mon, 27 Oct 2014 20:27:19 +0000 Date: Mon, 27 Oct 2014 20:27:18 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <284214904.880089.1414441638762.JavaMail.yahoo@jws10669.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_880088_2100220007.1414441638759" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cYbT5he_2spDl_2WqYFKUfznqy8 Cc: "kitten@ietf.org" Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:27:22 -0000 ------=_Part_880088_2100220007.1414441638759 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it fair to say the discovery docs are informative rather than normative?= =C2=A0I think so because they are SHOULD rathe rthan MUST.=20 On Monday, October 27, 2014 12:28 PM, Benjamin Kaduk w= rote: =20 On Tue, 21 Oct 2014, Bill Mills wrote: > how does the inclusion of working drafts rather than finished drafts > affect the process? =C2=A0Inclusion of the dynamic registration stuff wou= ld > do that. To some extent it depends on the specifics; if I understand correctly, in the general case, if draft A makes a normative reference to draft B, then draft A can be approved by the IESG for publication, but does not get actually published by the RFC Editor until draft B is also approved, so they get published in the same batch.=C2=A0 Such a dependency wouldn't necessarily hold up our WG work on it. -Ben ------=_Part_880088_2100220007.1414441638759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is it fair to say the discovery docs a= re informative rather than normative?  I think so because they are SHO= ULD rathe rthan MUST.


On Monday, October 27,= 2014 12:28 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:

On Tue, 21 Oct 2014, Bill Mill= s wrote:

> how does the inclusion o= f working drafts rather than finished drafts
> affect = the process?  Inclusion of the dynamic registration stuff would
> do that.

To some exte= nt it depends on the specifics; if I understand correctly, in
the general case, if draft A makes a normative reference to draft B, t= hen
draft A can be approved by the IESG for publication, = but does not get
actually published by the RFC Editor unt= il draft B is also approved, so
they get published in the= same batch.  Such a dependency wouldn't
necessarily= hold up our WG work on it.
<= br clear=3D"none">
-Ben


------=_Part_880088_2100220007.1414441638759-- From nobody Mon Oct 27 13:33:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5B11AD48C for ; Mon, 27 Oct 2014 13:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71xTsYsIHTAE for ; Mon, 27 Oct 2014 13:33:10 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 79B0D1AD451 for ; Mon, 27 Oct 2014 13:33:10 -0700 (PDT) X-AuditID: 12074422-f79436d000000c21-ee-544eac0547d3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 86.C5.03105.50CAE445; Mon, 27 Oct 2014 16:33:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9RKX9RP019616; Mon, 27 Oct 2014 16:33:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RKX7Y5015213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Oct 2014 16:33:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9RKX7sF015064; Mon, 27 Oct 2014 16:33:07 -0400 (EDT) Date: Mon, 27 Oct 2014 16:33:07 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141027071420.GB14215@localhost> Message-ID: References: <20141027071420.GB14215@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrMu2xi/EoCfX4ujmVSwWp64dYXNg 8nh56hyjx5IlP5kCmKK4bFJSczLLUov07RK4MprXf2YtaGWtmDZ/OWsD4zfmLkZODgkBE4kj S9ezQ9hiEhfurWfrYuTiEBKYzSSx5uVdJghnI6PEyy3TmSGcQ0wSVz81skM4DYwSk5aeYwHp ZxHQljh6cRoTiM0moCIx881GNhBbREBT4vq8pWA2s4CwxPpzM8B2CwsESLxtvg/WyymgL/F5 1VGwO3gFHCW6O68xgthCAnoSfye8AJspKqAjsXr/FBaIGkGJkzOfsEDM1JJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIClV2F6UdjD8PKh1i FOBgVOLhnVDsGyLEmlhWXJl7iFGSg0lJlPf+fL8QIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8 B9KAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErwMq4EaBYtS01Mr 0jJzShDSTBycIMN5gIY/WAUyvLggMbc4Mx0if4pRl6Ol6W0vkxBLXn5eqpQ470+QIgGQoozS PLg5sBTzilEc6C1h3r8gVTzA9AQ36RXQEiagJUbTfECWlCQipKQaGK2dbbh5F2/otOw7Wciy 5ZLKq3cdK5cKnljGfrTgz2S716zNy1LWhUcti5Uw1F5c48fxpFJm8SX3pq2Ljkz1Sdqoum1W x3Tl8phvh+VubKu/8vLequdzGXZ+tD582zAk7NdsNq2JK45OtlA688VI6VhnoH/KHZuzlfzz fmcwxv0XYzDdO23O6U1KLMUZiYZazEXFiQDHoJH+DAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/clbN7j4pGRfLOGyanz6RB8ud3UM Cc: kitten@ietf.org Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:33:13 -0000 On Mon, 27 Oct 2014, Nico Williams wrote: > > I'm dropping the LoF/TOFU business for now. It should go into a > separate I-D. This simplifies the PKCROSS I-D a fair bit. > > Update just submitted. "hierarchical trust hierarchies" is a bit redundant. > [[anchor2: QUESTION: Should the PKINIT request in step #3 be required > to be used within a FAST tunnel?]] Er, what sort of FAST tunnel is possible? Anonymous PKINIT from the same certificate being used here? That doesn't seem to add much value. I don't have anything else that jumped out at me reading the diff from -02 to -04, but didn't do a full review. -Ben From nobody Mon Oct 27 13:36:37 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143EA1AD4A3 for ; Mon, 27 Oct 2014 13:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz8c35wBniEM for ; Mon, 27 Oct 2014 13:36:01 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EF61AD495 for ; Mon, 27 Oct 2014 13:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2375; q=dns/txt; s=iport; t=1414442156; x=1415651756; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=s19M84v1MxftEP0Xi7Ptd1U2D1gLYEf0yr4R22PNIiE=; b=bYUw2+NcyawZYoK1i6kvbhtczbArfcCF/Cy3kurlKVex+WoQxicMOuWn Ch1QpowZYp7H6oZOxzpcj0AoAr6B1DNgyxcLEHxnbg3IqQfIAayhdqJT6 XC/LcWC34ZXG0INAg2L5hEfHk+2OzzvXHnrArped0M6xR/H+GF9Wf7zPY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAIyrTlStJA2G/2dsb2JhbABcDoMAVFgEgwLKLwqGeVQCgR4WAX2EAgEBAQMBAQEBIA8BOwoBBQsLDgoCAgUWCwICCQMCAQIBFTAGAQwBBQIBAYg0CQ22aJR0AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBLI8pMweCd4FUBYtkimuBd4Ubh2yOQoIAHhaBBF9NgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406592000"; d="scan'208";a="90794347" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 27 Oct 2014 20:35:55 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9RKZtUe007855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 20:35:55 GMT Received: from [10.129.24.59] (10.129.24.59) by xhc-rcd-x15.cisco.com (173.37.183.89) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 27 Oct 2014 15:35:55 -0500 Message-ID: <544EACAA.6070506@cisco.com> Date: Mon, 27 Oct 2014 14:35:54 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bill Mills , Benjamin Kaduk References: <284214904.880089.1414441638762.JavaMail.yahoo@jws10669.mail.bf1.yahoo.com> In-Reply-To: <284214904.880089.1414441638762.JavaMail.yahoo@jws10669.mail.bf1.yahoo.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.59] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Lo_6ViBtpEmHr3Sc65nvaBzbGP0 Cc: "kitten@ietf.org" Subject: Re: [kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:36:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/27/14, 2:27 PM, Bill Mills wrote: > Is it fair to say the discovery docs are informative rather than > normative? I think so because they are SHOULD rathe rthan MUST. > > /me doffs hat SHOULD means "do it unless you understand unless you have a good reason (and understand the consequences) to not do it." To me, that would mean you have to understand the "it", to know if you understand have a good reason (and understand the consequences) to not follow the SHOULD. If you have to understand something, then which (to me) means it's normative. The decision on whether or not a reference is normative can't be based on whether its publication is impacted, but on if it's important to understand the referenced material before one can implement the given specification. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > On Monday, October 27, 2014 12:28 PM, Benjamin Kaduk > wrote: > > > On Tue, 21 Oct 2014, Bill Mills wrote: > >> how does the inclusion of working drafts rather than finished >> drafts affect the process? Inclusion of the dynamic registration >> stuff would do that. > > To some extent it depends on the specifics; if I understand > correctly, in the general case, if draft A makes a normative > reference to draft B, then draft A can be approved by the IESG for > publication, but does not get actually published by the RFC Editor > until draft B is also approved, so they get published in the same > batch. Such a dependency wouldn't necessarily hold up our WG work > on it. > > > -Ben > > > > > _______________________________________________ Kitten mailing > list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUTqyqAAoJEDWi+S0W7cO1+c8IAKVWhWJWlsW7U6NkaoCD8ZV1 0cVeNPaU3XWrwEIhc1BGK5DccmJuc+725tR5F9RxPFJRUJAlotwbBFXc7wVGK05D nDjqm3SDVl3kq0l7ZvNry2g24QV0iAkB0MljZhMlJPxRAGZEpz98/9yLSTtdN6G5 oWpWo/9xdyGaALstVdaFzrRHidPu7Sqk9UZdrjWiFB5NHniqqU3bdQDZPhOxxSD5 rWT2hW6qKYepl4rh9nTxfV139scKzWfcTV+BRnb/UKPqzcqzH49cuDus43BMJMd5 x7AXpBlmSliohpnepL2/irtv5IKiOFUb9R3mpI2EH7OqKWfYlDmwR98jKMbFNHw= =kxu6 -----END PGP SIGNATURE----- From nobody Mon Oct 27 13:40:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D497E1A1A59 for ; Mon, 27 Oct 2014 13:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laKhHnl5R0Sf for ; Mon, 27 Oct 2014 13:39:34 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B53F61A011E for ; Mon, 27 Oct 2014 13:39:34 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 5997E584059; Mon, 27 Oct 2014 13:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ay1KF8u11Xaxud 8lAWxPsovcfa4=; b=wQ20uS5suy5RgCxo7KC6+ujNkDmaubceQvt/MKkukC/mGE AM5w5cUvZN8hqN8hiR+NjLtQXCoASGYaw2LvF4QhNsXZwuNBqOzZDE4xNwLiOAHf DuZUUuC5mBNtgRfktU+T2la7AAKre+Bu5yDILGsaeSLDYDlwPxJs0RTfOgedA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id D71A5584057; Mon, 27 Oct 2014 13:39:33 -0700 (PDT) Date: Mon, 27 Oct 2014 15:39:33 -0500 From: Nico Williams To: Matt Miller Message-ID: <20141027203931.GA16952@localhost> References: <543EA410.5000508@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543EA410.5000508@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/HxJzy7ymiuk5m2CNcpHTflV5Izs Cc: Kitten WG , Kitten Chairs Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:39:37 -0000 > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-00 Comments: - In some places you add non-RFC2119 language to what RFC2743 says (e.g., which arguments to GSS_Init/Accept_sec_context() must stay the same during an exchange). Should we be updating RFC2743 here, and just aim for the Standards track (and use RFC2119 language)? (There is the risk that this I-D will have mistakes that we don't want to make normative, but those would be errata.) - "Such a security context allows for mutual authentication of the two..." Strictly speaking it allows for authentication of either party to the other. Speaking of "mutual authentication" here is probably not a good idea: there are two very different meanings of "mutual authentication"; readers are bound to be confused. - s/confidential or integrity-protected/confidentiality and\/or integrity-protected/ - Add a paragraph break just before "The number of tokens which must be exchanged..." - Add "Security context tokens are exchanged synchronously, one at a time; the initiator sends the initial context token." just before that sentence. Might as well also point out that the only asynchronously exchanged security context tokens are: - error tokens sent by one side to another than had just returned GSS_S_COMPLETE (and an output token, the one that elicits the error) - security context deletion tokens (which are obsoleted and, therefore, best not mentioned) Mentioning these very basic aspects of GSS context token exchanges early on should be very useful to the reader. It's quite handy for me to always keep this in mind when coding a GSS security context token exchange loop; it should be for others too, I think. - We should say, in the intro, something about the expectation that the application will add such things as: - authentication + authorization success/failure messages - token framing - ...described in a single specification... Er, do we want application protocols using GSS to reference this document normatively? If so this should aim to be on the Standards track. Or perhaps we want them to reference RFC2743 _and_ this one? - s/scattered in many different places/scattered about/. - Section 2, last sentence/para: I'm not sure that this is needed at all. Where you discuss GSS_Init/Accept_sec_context() you generally talk about the first call anyways (e.g., section 2.4, first sentence). - Section 2.1. Perhaps initiators wanting anonymity should also GSS_Acquire_cred() for a desired_name of GSS_C_NT_ANONYMOUS name type. This was never clear in RFC2743. Alternatively, having a credential handle for an anonymous name, must anon_req_flag be set? Consider an API that takes a credential handle from a caller and then uses it to initiate security context tokens. If the implementation of the API needs to inquire the credential to see if it's for a GSS_C_NT_ANONYMOUS desired_name... that could get annoying. My theory is that anon_req_flag is for use when a non-anonymous [e.g., perhaps a default] credential handle is used by the caller. Otherwise, if the credential handle is for an anon name then anon_req_flag is not / should not need to be set! Conversely, an API that wants anonymity but doesn't know if the given credential handle would obtain it... MUST set anon_req_flag. - "If the major status code is GSS_S_CONTINUE_NEEDED and the output_token is empty, ..." Are there examples of such implementations? Are there bindings other than C where this could not be handled as proposed? - s/if an appropriate channel/if an appropriate application-protocol message (or transport operation, e.g., TCP close)/ - Section 2.3, what is a "synchronous TCP channel"? - Section 2.3, the key thing to note is that GSS tokens are NOT self-delimiting. Therefore the application must always provide framing. (Some of us want a req_flag/ret_flag for requesting self-framing by the mechanism. It'd be quite handy for some mechanisms and protocols. E.g., the old Globus SSL mechanism, which *is* SSL/TLS on the wire when the tokens are sent with no additional framing.) - Section 2.3, "the application protocol must provide some means by which the GSS context tokens can be identified" -- in particular: their _length_ (and start location in a stream/message) must be identified. - Section 2.3, perhaps there should be a list of things the application protocol must provide: - per-message token framing - security context token framing - optional authentication/authorization status message (optional because for some protocols GSS security context establishment is always sufficient to proceed, or because when it isn't the acceptor can simply withold the last security context token [though I'd not recommend that]) - Error handling is completely optional. Applications can send or not send error tokens. Applications can "close the connection" when the transport is connection-oriented. Applications can even stop responding to peers. There's probably no need to discuss security context deletion tokens (since they are obsolete). Framing is needed even when there is no multiplexing. A list like this seems likely to be easier to read than prose. Most of this is applicable to both, the initiator and the acceptor, therefore a new section slotted before the current 2.2 or 2.3, with the above content (wordsmithed) would be convenient. - Section 2.3, first para, remove the last sentence. It's difficult to parse and adds little (especially if a list of requirements as above is provided). - Section 2.4, second para: this applies to the initiator and acceptor equally. Can we refactor this out? After all, the GSS_Step_sec_context() extension would be all about doing just that. Might as well do it here in the prose too. - Section 2.6, last para is redundant (repeats instructions given earlier). - "...should assume that the [peer's] state is invalid..." is an odd construction. Is there a difference between "time out" and "the peer's state is invalid"? - Section 2.8, should there be a maximum number of loop iterations? No! There shouldn't be, at least not a constant one. If a maximum is used, it should be configurable. - Section 3, don't list the req_flags that must remain fixed. Say that all of them must. Remember, we can (and probably will) add new flags. Alternatively say "and any future new req_flags". - Section 3, last para, both, the initiator and acceptor receive these (and future) ret_flags. Might as well merge this paragraph with the text from two paragraphs earlier. (See above comment about refactoring common parts.) - Section 3.1, first para, last sentence: this is a bit of an exageration. Applications should do whatever is appropriate as to prot_ready per-message tokens' lack of replay protection. While we're at it, the intention in RFC2743 was that protection services can't be counted as applied to prot_ready per-message tokens until after the security context is fully established. Which means that prot_ready per-message tokens: - don't get effective confidentiality and/or integrity protection until full security context establishment; - never get replay detection services, not at the time that they are consumed (since this would potentially require a replay cache on acceptors and possibly even initiators for some mechs, and to my knowledge no implementations use a replay cache for prot_ready per-message tokens), and not at some point later when the security context is fully establised (since it'd be too late then to report errors about specific already-consumed per-message tokens). - Section 3.1, last para. See above. - Section 3.2, page 9, second para (I think that's the third para), error context tokens can arise in more common cases: - initiator sent the last token and was GSS_S_COMPLETE but the acceptor rejects that token (e.g., Kerberos w/o mutual auth, with any of many common Kerberos errors, and even application authorization errors) A three-message Kerberos exchange (e.g., see draft-williams-kitten-krb5-extra-rt) would also run into this. - acceptor sent the last token and was GSS_S_COMPETE but the initiator rejects that token. Calling these cases "rare" is asking for trouble. The thing that is rare is the "optional to implement" thing, and a) that never happens now, b) it's no different than any other error that could happen as mentioned above. (Once upon a time we had export restrictions on crypto, and as a result some implementations shipped an RFC1964 implementation without confidentiality protection, and this could cause an error token to be sent back when the initiator hadn't requested mutual auth, this is true. Well, maybe it didn't even produce an error token -- this was fifteen years ago, with code long since obsolete, and I doubt anyone will check the specifics now.) - Section 3.2, last para: the best advice to give as to asynchronous (i.e., unexpected) security context tokens, is that the application must always act as though they terminate the security context, even when they don't. We should deprecate the optional-to-implement thing that led you to write this. - Section 4: - There is no need to use GSS_ERROR() to handle major status codes from gss_init/accept_sec_context() because the is never a success or continue needed case with other supplemental codes or any error codes. Always use equality comparison for gss_init/ accept_sec_context() major status codes to check for complete/continue_needed status. Moreover, it's best to discourage use of GSS_ERROR(). Its use with gss_unwrap() major status codes has led to a number of security vulnerabilities in protocoles that were trying to make an octet stream. GSS_ERROR() is only ever of use to applications using an unreliable datagram transport, or to applications that have no need for replay and/or out-of-sequence detection services from the GSS-API (e.g., ONC RPC doesn't, even when running over TCP). - The sample code doesn't do what the prose says as to empty output tokens when one is expected... - The while loop should probably be a do while loop. - There is no need to memset(&name_buf, 0, sizeof(name_buf)); - memset() to zero doesn't work on architectures where the zero-valued pointer isn't the all-zero bit pattern. - The major status of gss_import_name() should be checked. - Why not mention authorization (use a stub function) and application-level status message in do_acceptor()? - This: } else { /* This situation is forbidden by RFC 2743. Bail out. */ warnx("major not complete or continue but not error\n"); goto cleanup; } would be an internal error, not behavior forbidden by RFC2743, because you break out of the loop in this case before ever getting here. You should either assert() or ignore this. - What about mentioning the possible need to check -on the acceptor side- the name of the acceptor as used by the initiator? That's a gss_inquire_context() call to get the name of the acceptor, then a gss_compare_name() function call (or any of the other methods of comparing names given in RFC2743). Nico -- From nobody Mon Oct 27 13:45:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE9E1A1B8A for ; Mon, 27 Oct 2014 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq1Uw_GucZPZ for ; Mon, 27 Oct 2014 13:45:27 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8001A1B05 for ; Mon, 27 Oct 2014 13:45:27 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 507B02005D113; Mon, 27 Oct 2014 13:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=H4HMqNZq6xPkxc qWf2idGn/6tWo=; b=sbQj6/3KG1vhimwhJiz8yyo3FhiT1iGq+3uCX8hivbc06F IE3F4Ck2c5LtVs6U1QGYonHT7ZwefJHBaaACyF2jkbj16d5gJFzKb9dLpK7Gud5A GuhLJmAjh2JtWhLFEenNifvRqi5G6Ii57hZ55KGoJpFPERsxJw+0r6QforBr4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id F01A42005D107; Mon, 27 Oct 2014 13:45:26 -0700 (PDT) Date: Mon, 27 Oct 2014 15:45:26 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20141027204525.GB16952@localhost> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> <544E92FF.605@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544E92FF.605@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nKK89rcvRKLH5Kup8KEFfwE2SXw Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:45:28 -0000 On Mon, Oct 27, 2014 at 02:46:23PM -0400, Greg Hudson wrote: > On 10/24/2014 05:33 PM, Nico Williams wrote: > > - if the KDC knows the services' supported DH curves then it might as > > well know the service's public keys too! > > I don't follow this step. If the KDC knows the server's "DH public key" > (g^y for integer DH), that implies that the server is going to use the > same "DH private key" (y) for as long as the KDC is giving out that key. Indeed. > But forward secrecy depends on discarding private keys often enough > that a future compromise of either party doesn't give access to the > private key used for past exchanges. You can reuse a private key for DH isn't only about forward secrecy, and it can be used both, with ephemeral keys, and with long-term keys. > multiple exchanges, but you can't keep using it for longer than you > generally expect sessions to last (i.e. at most hours, not days or weeks). It'd be possible to have the KDC know a service's long-term public DH key *and* for the service to also use an ephemeral public key in the AP exchange to obtain PFS if either it or the initiator demand it. Storing a public key would be useful for the other reasons that I gave. But mostly I was exploring the design space in my comments. Nico -- From nobody Mon Oct 27 13:48:52 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCD31A876E for ; Mon, 27 Oct 2014 13:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHOwYpz6lj_E for ; Mon, 27 Oct 2014 13:48:30 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 70A351ACE45 for ; Mon, 27 Oct 2014 13:48:30 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 417FE27BC06B; Mon, 27 Oct 2014 13:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tBshXqhtsb3DIu DHpUrBfWDrOgY=; b=mKyBqr68NmqVBtl8laVx5czqkTnOQdlPPIdXaeQCsat869 lYMJEp0zStQC0bHlJVvFxPwNXL2nVT896x5BFHbaYSWPQ65iykIv2Mj8hHWDxG89 YgWkSXzxyUGd08zTEo68ZIZ9/Lpg6DMK4mRtTeQTBWR896lZxRJ0JVR9r+muA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id DD71927BC064; Mon, 27 Oct 2014 13:48:29 -0700 (PDT) Date: Mon, 27 Oct 2014 15:48:27 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141027204825.GC16952@localhost> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Oilj3jMFpHZ7leJsYBSljFZGSrk Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:48:31 -0000 On Mon, Oct 27, 2014 at 03:13:46PM -0400, Benjamin Kaduk wrote: > On Fri, 24 Oct 2014, Nico Williams wrote: > > - if the KDC knows the services' supported DH curves but not its public > > keys then... we need to extend KDC-REP to convey this info > > I think it might be very complicated to try to manage this information in > the KDB. It's hardly any worse than managing symmetric long-term keys. Again, I was exploring the design space. > > - just because we want proper PFS doesn't mean we must do a full DH > > exchange in every AP exchange: we could do something like TLS > > resumption: the service should return a short-lived Ticket (minted by > > the service) > > > > Let's call this "fast re-auth tickets". Other uses include: > > This has the potential to be a pretty heavyweight protocol/code > modification. I'm not sure that we have the collective energy to do so > (comparatively, TLS has a lot more effort focused on it). Perhaps. > > - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS > > forward secrecy relies on both parties discarding the ephemeral values; > I'm not sure that the GSSAPI will be able to effectively enforce that. Why not? > (Not that we shouldn't have a flag to request this sort of thing and > indicate that it was used, just that such a ret_flag may not be as strong > a guarantee as we want.) Why not? I mean, either the mechanism does what it was asked for and doesn't lie, or it doesn't do what it was asked for and... doesn't lie. A lying mechanism could lie about all sorts of things, and it'd just be a bug, and therefore outside the scope of the spec. Nico -- From nobody Mon Oct 27 13:56:43 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9EE1AD4CA for ; Mon, 27 Oct 2014 13:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjwuCWDGDQgX for ; Mon, 27 Oct 2014 13:56:18 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5A51AD4C6 for ; Mon, 27 Oct 2014 13:56:18 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) with Microsoft SMTP Server (TLS) id 15.1.6.9; Mon, 27 Oct 2014 20:56:16 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) with mapi id 15.01.0006.000; Mon, 27 Oct 2014 20:56:16 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: Comments requested on draft-short-pkinit-freshness-00 Thread-Index: Ac/yJtbghGzsElT3RuOdLMFKYwVjJg== Date: Mon, 27 Oct 2014 20:56:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB212; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(189002)(50986999)(76482002)(54356999)(86362001)(101416001)(21056001)(77096002)(16236675004)(19617315012)(99396003)(92566001)(2501002)(120916001)(4396001)(122556002)(33646002)(40100003)(110136001)(15202345003)(80022003)(86612001)(46102003)(87936001)(20776003)(31966008)(561944003)(107886001)(2351001)(107046002)(229853001)(19625215002)(76576001)(230783001)(106356001)(108616004)(74316001)(19300405004)(97736003)(2656002)(64706001)(19580395003)(85306004)(95666004)(99286002)(15975445006)(105586002)(85852003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB212; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_c235472b16354eacb66aa49c22a34243BL2PR03MB212namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/NOpGXwzKdwJMDoyKenkKjaYrppo Subject: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:56:24 -0000 --_000_c235472b16354eacb66aa49c22a34243BL2PR03MB212namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Debated email vs draft on this. Since I wasn't going to make the MIT or IET= F meetings (thus someone else will be there), it seemed like a draft would = easier to discuss via email. A few years back there was a discussion about the DH freshness issue, so th= is is a proposal transmitting data to ensure freshness: https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/ Thanks, Michiko Short | Program Manager | OS Security --_000_c235472b16354eacb66aa49c22a34243BL2PR03MB212namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Debated email vs draft on this. Since I wasn’t= going to make the MIT or IETF meetings (thus someone else will be there), = it seemed like a draft would easier to discuss via email.

 

A few years back there was a discussion about the DH= freshness issue, so this is a proposal transmitting data to ensure freshne= ss:

 

https://datatracker.ietf.org/doc/draft-short-pkin= it-freshness/

 

 

 

Thanks,

Michiko Short | Program Manager | OS Security

 

--_000_c235472b16354eacb66aa49c22a34243BL2PR03MB212namprd03pro_-- From nobody Mon Oct 27 13:59:14 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168C21AC424 for ; Mon, 27 Oct 2014 13:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFomTAYA3vtl for ; Mon, 27 Oct 2014 13:58:49 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEE41AD4CE for ; Mon, 27 Oct 2014 13:58:35 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 2F7F020058D86 for ; Mon, 27 Oct 2014 13:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PWqfm/e8hxruI9qFgy9K tnRHNMg=; b=DpioOdyXMNN3kl1j1Y9hzJx8sAr7sGPqhk1yd37rWyad1vru1UHB 3w6xw/szKBpJgiMYfYgrMAqVexlxKQsgqjBNiI1OqUMf6zJoUePe+SpoH0mK5oHh lWQ5NZUJTAT/6XBwFkQX4MKB5B87HRopqnqU5cGsWix6jdUWSpri210= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id D8C5520058D84 for ; Mon, 27 Oct 2014 13:58:34 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so4063024wib.7 for ; Mon, 27 Oct 2014 13:58:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.94.9 with SMTP id cy9mr4921135wjb.117.1414443513625; Mon, 27 Oct 2014 13:58:33 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Mon, 27 Oct 2014 13:58:33 -0700 (PDT) In-Reply-To: References: <20141027071420.GB14215@localhost> Date: Mon, 27 Oct 2014 15:58:33 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RYHga9XdjVyNLE0qZgO8Dy1CSTg Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:58:50 -0000 On Mon, Oct 27, 2014 at 3:33 PM, Benjamin Kaduk wrote: > On Mon, 27 Oct 2014, Nico Williams wrote: >> I'm dropping the LoF/TOFU business for now. It should go into a >> separate I-D. This simplifies the PKCROSS I-D a fair bit. >> >> Update just submitted. >> [[anchor2: QUESTION: Should the PKINIT request in step #3 be required >> to be used within a FAST tunnel?]] > > Er, what sort of FAST tunnel is possible? Anonymous PKINIT from the same > certificate being used here? That doesn't seem to add much value. It's always possible to add one more anon PKINIT tunnel... :) The point is to protect the client's identity (certificate). > I don't have anything else that jumped out at me reading the diff from -02 > to -04, but didn't do a full review. There's no urgency, of course. But I would like to request that KITTEN adopt this and, more importantly, draft-williams-kitten-krb5-extra-rt. Nico -- From nobody Mon Oct 27 14:02:54 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440CC1AD504 for ; Mon, 27 Oct 2014 14:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NOYDqBzZIvL for ; Mon, 27 Oct 2014 14:02:29 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D551AD502 for ; Mon, 27 Oct 2014 14:02:28 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-b7-544eb2e39432 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id D7.F5.23365.3E2BE445; Mon, 27 Oct 2014 17:02:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9RL2RMs023376; Mon, 27 Oct 2014 17:02:27 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RL2PNQ025978; Mon, 27 Oct 2014 17:02:26 -0400 From: Tom Yu To: Greg Hudson References: Date: Mon, 27 Oct 2014 17:02:25 -0400 In-Reply-To: (Greg Hudson's message of "Sat, 25 Oct 2014 12:49:25 -0400") Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixCmqrPt4k1+IQcc7C4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/OSw8wFi7gqjh5pYmtgnMrRxcjJISFgIrH1ewsLhC0mceHe erYuRi4OIYHZTBJbbixmBkkICWxklLj+RBsi8YZR4vW5frAONgFpieOXdzGB2CICihLPVs0F izMLiEqcW3eEFcQWFjCQeL6xk72LkQOo2VCi92c6SJhFQFXiyqS7bCA2p0ChxP9J98B28Qro Suy995QdxOYR4JQ4u38PK0RcUOLkzCdQ47Ukbvx7yTSBUWAWktQsJKkFjEyrGGVTcqt0cxMz c4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgkNPkn8H47eDSocYBTgYlXh4LQp9Q4RYE8uKK3MP MUpyMCmJ8jJs9AsR4kvKT6nMSCzOiC8qzUktPsQowcGsJMJ7IA0ox5uSWFmVWpQPk5LmYFES 5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwbsAZKhgUWp6akVaZk4JQpqJgxNkOA/Q8BcgNbzF BYm5xZnpEPlTjIpS4ryCIAkBkERGaR5cLyw1vGIUB3pFmJcLmCiEeIBpBa77FdBgJqDBRtN8 QAaXJCKkpBoYHTe6zZ/ZcvGWaLiRVbH6O/lJ/FPLJp62Sex/sSLhvNWV8lKplhTuiba71Dt4 dnLPuCV3Wm/HR6m+zKwDe+Qt161N2ThxYaDkwQ9Tjrz+9L2RSer24m9XuKtXL7ctlpw6rZyn Snlb9aZgJdH8zd2/s9dJ7rns1FQRMPmp3Qlhy9pCodDj36eaKbEUZyQaajEXFScCAIE1HG/o AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pV1oz55EmCjukIkIfs-0Apq8VFE Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:02:32 -0000 Greg Hudson writes: > While working on creating test vectors for CAMMAC using asn1c, I noticed > into three issues with the ASN.1 module. Two are just matters of form, > but the third will affect the encoding if we decide to change it. I > believe we're at a slightly awkward stage of the workflow for this > draft, but at least we are still before IETF last call. > > 1. The ASN.1 module needs IMPORTS declarations for the RFC 4120 types it > uses. I have submitted a pull request to Tom's github repository with > the necessary import statements. Thanks. I'll incorporate this in the next revision, if the chairs think it's acceptable to make this change at this point in the process. > 2. There is no OID in the module declaration. I don't know how > important this is in practice, but all of the other Kerberos-related > ASN.1 modules I looked at have OIDs. I think it varies; if the specification provides an ASN.1 module (as opposed to a fragment of a module), it seems that there is often a module OID. Interestingly enough, the RFC 6113 module OID conflicts with the OID of the module that I'm using to register OIDs under the IETF KerberosV5 arc, so I would want to check for other potential conflicts before assigning an OID to the module for CAMMAC. From nobody Mon Oct 27 14:27:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD081AD595 for ; Mon, 27 Oct 2014 14:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYHyW6FvaYmH for ; Mon, 27 Oct 2014 14:26:29 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA7B1AD572 for ; Mon, 27 Oct 2014 14:25:57 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-04-544eb864197c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E8.EF.13180.468BE445; Mon, 27 Oct 2014 17:25:56 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9RLPt0L026006; Mon, 27 Oct 2014 17:25:55 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RLPr9O002142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Oct 2014 17:25:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9RLPqaZ021612; Mon, 27 Oct 2014 17:25:52 -0400 (EDT) Date: Mon, 27 Oct 2014 17:25:52 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141027204825.GC16952@localhost> Message-ID: References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> <20141027204825.GC16952@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrJuywy/EYO4hdoujm1exWJy6doTN 4umre2wOzB4vT51j9Fiy5CeTx4Z/TWwBzFFcNimpOZllqUX6dglcGU+vdjEWXOKsWHfhM2sD 4z32LkZODgkBE4kr+/+yQdhiEhfurQeyuTiEBGYzSax694sRJCEksJFRYtk3c4jEISaJXfN2 M0I4DYwS52dsBWtnEdCW+P7pOFgHm4CKxMw3G8HiIgKaEtfnLQWzmQV8Jf79PMMEYgsLpEvs PLIFzOYU0Jd4efEScxcjBwevgKPE7vvKEPP3Mkq83LScBaRGVEBHYvX+KWA2r4CgxMmZT1gg ZmpJLJ++jWUCo+AsJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrp5WaW6KWmlG5i BIUvu4vyDsY/B5UOMQpwMCrx8FoW+oYIsSaWFVfmHmKU5GBSEuW13OoXIsSXlJ9SmZFYnBFf VJqTWnyIUYKDWUmE90AaUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoND SYL3+zagRsGi1PTUirTMnBKENBMHJ8hwHqDhfttBhhcXJOYWZ6ZD5E8xKkqJ8/aANAuAJDJK 8+B6YenlFaM40CvCvCYg7TzA1ATX/QpoMBPQYKNpPiCDSxIRUlINjBU8HWy3w7a1a7j6pMjy T3z4ZpfWdd8JfbvqQj/N6ps7gdH7dub5tnuh+b8ffNYy5TBoePY86HOKW8CyxcfWtn2UYtwU e1JnTnmA7Ls54qsmzPgXL3vD8Fi75pJbGppSU4z3VF+YX3KJqeGn+Jq2ROb2llv6ZabxnH5+ ezfcThL4E+jzzVc3V4mlOCPRUIu5qDgRACCJKmcKAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/xwEUZ91J4wblhfqrAUVWXNhtPQ8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:26:35 -0000 On Mon, 27 Oct 2014, Nico Williams wrote: > On Mon, Oct 27, 2014 at 03:13:46PM -0400, Benjamin Kaduk wrote: > Again, I > was exploring the design space. Sure; I'm just saying what comes to mind as a result of that exploration :) > > > - for GSS we need a new req_flag/ret_flag for requesting/signalling PFS > > > > forward secrecy relies on both parties discarding the ephemeral values; > > I'm not sure that the GSSAPI will be able to effectively enforce that. > > Why not? Thinking harder, the actual ephemeral values should not be needed after security context establishment (just the derived keys), so okay, yes, the implementations can guarantee that the ephemeral values are freed then. Of course, the context's keys will need to remain around as long as the context is valid, and if a sloppy long-running application fails to destroy the security context, those keys used to encrypt actual messages on the context might still be resident in memory if that machine got hacked at some point in the future. So, it's the "other endpoint might fail to destroy the security context" bit that can't be enforced reliably. "Maybe we should say 'forward secrecy', not 'perfect forward secrecy'." -Ben From nobody Mon Oct 27 14:33:14 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5368B1AD5AD for ; Mon, 27 Oct 2014 14:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0Wvlkcz8tFK for ; Mon, 27 Oct 2014 14:33:09 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1F71AD5EB for ; Mon, 27 Oct 2014 14:31:33 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 31A0B1B4059; Mon, 27 Oct 2014 14:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=SAqcsZgbiZwxAs JnxTBgmVPgP8o=; b=fx2EJxr02QxW15mnpnpvKtVxVzPavJfIlfmW6KXF+vVy6J H9YOSAU/tjFMx54Xrk6UCkhNvDud6hTbLCwbxOlaQd+5vT+rcjArcbVvoHoFsDTX xi9jJzuWD5id6eIbP5iSRDHR4ehYtFTmaa1L6kdKxEf4+3AoYInpezGiniKCc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id BFFFA1B4057; Mon, 27 Oct 2014 14:31:32 -0700 (PDT) Date: Mon, 27 Oct 2014 16:31:32 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141027213130.GA17213@localhost> References: <16764AFA-1D80-4431-A16F-17D49396082B@openfortress.nl> <20141024213333.GA6185@localhost> <20141027204825.GC16952@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/9sbhV9pf7rJsG7YcIXOH3ctvuEw Cc: "kitten@ietf.org" Subject: Re: [kitten] Draft Action: KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:33:10 -0000 On Mon, Oct 27, 2014 at 05:25:52PM -0400, Benjamin Kaduk wrote: > On Mon, 27 Oct 2014, Nico Williams wrote: > > > > - for GSS we need a new req_flag/ret_flag for > > > > requesting/signalling PFS > > > > > > forward secrecy relies on both parties discarding the ephemeral > > > values; I'm not sure that the GSSAPI will be able to effectively > > > enforce that. > > > > Why not? > > Thinking harder, the actual ephemeral values should not be needed > after security context establishment (just the derived keys), so okay, > yes, the implementations can guarantee that the ephemeral values are > freed then. Of course, the context's keys will need to remain around > as long as the context is valid, and if a sloppy long-running > application fails to destroy the security context, those keys used to > encrypt actual messages on the context might still be resident in > memory if that machine got hacked at some point in the future. So, > it's the "other endpoint might fail to destroy the security context" > bit that can't be enforced reliably. "Maybe we should say 'forward > secrecy', not 'perfect forward secrecy'." Right. Also, without re-keying we really depend on the app to re-key if it wants to guarantee forward secrecy for some past communications. (We could, perhaps, have PFS re-keying piggybacked on per-message tokens. It's doable, but I'm not sure that it's worth doing. There are many other things I'm certain are worth doing, and we have limited energy.) Note though that there is value is allowing what-should-be- ephemeral keys to be re-used a few times -performance value- without losing much in terms of protection. But this requires a bit of care to prevent accidental symmetric key re-use, something like a small counter/nonce. Nico -- From nobody Mon Oct 27 14:44:26 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA201A007B for ; Mon, 27 Oct 2014 14:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrCGBodVtCa0 for ; Mon, 27 Oct 2014 14:44:19 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6961A00D7 for ; Mon, 27 Oct 2014 14:43:29 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-4c-544ebc80be47 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 56.74.18723.08CBE445; Mon, 27 Oct 2014 17:43:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9RLhRCf027891; Mon, 27 Oct 2014 17:43:27 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RLhPx1007696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Oct 2014 17:43:26 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9RLhOJr023798; Mon, 27 Oct 2014 17:43:24 -0400 (EDT) Date: Mon, 27 Oct 2014 17:43:24 -0400 (EDT) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixCmqrNuwxy/E4MwLPoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr48OT6WwFO7grpm5bz9LA+JOji5GTQ0LARGLG5xfsELaYxIV7 69m6GLk4hARmM0kcePSYCcLZyCjx9EUXM4RziEli0cPvjBBOA6PEvrsvmUD6WQS0JbYvmg5m swmoSMx8s5ENxBYRkJQ49uQ8UDcHB7OAkcSFXxkgYWEBA4nnGzvBVnMK6EncO/GUEcTmFXCU ONN8AcwWEgiW+H1vJjOILSqgI7F6/xQWiBpBiZMzn4DZzAJaEsunb2OZwCg4C0lqFpLUAkam VYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGEFhye6isoOx+ZDSIUYBDkYlHt4J xb4hQqyJZcWVuYcYJTmYlER53+70CxHiS8pPqcxILM6ILyrNSS0+xCjBwawkwuu1AyjHm5JY WZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBu2I3UKNgUWp6akVaZk4JQpqJ gxNkOA/Q8HaQGt7igsTc4sx0iPwpRkUpcd6Hu4ASAiCJjNI8uF5Y2njFKA70ijBvPkg7DzDl wHW/AhrMBDTYaJoPyOCSRISUVAPj1B/T4m52GBxOvTU3JT1tgYmO+VGhhS9eHrD8LPn26O+8 +/XXtntnPik7dD/2aoLGlpLew53iNuFlfid790WX3gi6OmPaj+6Y0k7JAzJCrf4/dK3Y6vOW L3T4r1jzPEVG66RPuHzu8q2sLpk/dpxpuG/TztvHz2X52t8mIXnbPYG85ce6Z1cosRRnJBpq MRcVJwIAvjSgqvYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EzZlWzSGos8WHmm-Tg5DWasGEpE Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:44:22 -0000 On Mon, 27 Oct 2014, Tom Yu wrote: > Greg Hudson writes: > > > While working on creating test vectors for CAMMAC using asn1c, I noticed > > into three issues with the ASN.1 module. Two are just matters of form, > > but the third will affect the encoding if we decide to change it. I > > believe we're at a slightly awkward stage of the workflow for this > > draft, but at least we are still before IETF last call. > > > > 1. The ASN.1 module needs IMPORTS declarations for the RFC 4120 types it > > uses. I have submitted a pull request to Tom's github repository with > > the necessary import statements. > > Thanks. I'll incorporate this in the next revision, if the chairs think > it's acceptable to make this change at this point in the process. Please go ahead. > > 2. There is no OID in the module declaration. I don't know how > > important this is in practice, but all of the other Kerberos-related > > ASN.1 modules I looked at have OIDs. > > I think it varies; if the specification provides an ASN.1 module (as > opposed to a fragment of a module), it seems that there is often a > module OID. Interestingly enough, the RFC 6113 module OID conflicts > with the OID of the module that I'm using to register OIDs under the > IETF KerberosV5 arc, so I would want to check for other potential > conflicts before assigning an OID to the module for CAMMAC. Thanks for doing the investigation. -Ben From nobody Mon Oct 27 19:11:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1571A8776 for ; Mon, 27 Oct 2014 19:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCJukeI0MX8X for ; Mon, 27 Oct 2014 19:10:52 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A08B1A6FBC for ; Mon, 27 Oct 2014 19:10:52 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-bf-544efb2bced9 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 93.DB.27750.B2BFE445; Mon, 27 Oct 2014 22:10:51 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9S2AoWL022749; Mon, 27 Oct 2014 22:10:50 -0400 Received: from [18.101.8.220] (vpn-18-101-8-220.mit.edu [18.101.8.220]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9S2Al32028016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 22:10:48 -0400 Message-ID: <544EFB27.6050905@mit.edu> Date: Mon, 27 Oct 2014 22:10:47 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michiko Short , "kitten@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixG6nrqv92y/E4Mo0IYujm1exWPzr5nNg 8liy5CeTR+uOv+wBTFFcNimpOZllqUX6dglcGZdeX2Mt6GCv+LZhKXMD413WLkZODgkBE4nZ C/8zQthiEhfurWfrYuTiEBKYzSSx/8oTJghnI6PEpg9foZwjTBI/O4+ydDFycPAKqEmse5YN YrIIqEq8OqwNMohNQFli/f6tYBWiAmESU5fygIR5BQQlTs58AhYWEYiQmNsaCxIWFvCWeP90 B9gJQgKhEoveNIPZnECdp3/OB7OZBfQkdlz/xQphy0s0b53NPIFRYBaSqbOQlM1CUraAkXkV o2xKbpVubmJmTnFqsm5xcmJeXmqRrqFebmaJXmpK6SZGUIBySvLsYHxzUOkQowAHoxIPr8FD vxAh1sSy4srcQ4ySHExKorxvHgCF+JLyUyozEosz4otKc1KLDzFKcDArifB67QDK8aYkVlal FuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8O74CdQoWJSanlqRlplTgpBm4uAE Gc4DNPw3SA1vcUFibnFmOkT+FKMuR0vT214mIZa8/LxUKXHeVyBFAiBFGaV5cHNgieUVozjQ W8K860GqeIBJCW7SK6AlTEBLjKb5gCwpSURISTUwpk87MjlqEveSBWsYpCbsr5++Lkv8zu2j 0l83+AkEqt4J8dolMSlAPCVLfcmlmV4Bk4R+FUSIJDzKLVWze5byyPDRkZxqLZaYT5NYZ6lM 8uC1OcTSqLJH+kaw6paHvLdXhn4Ua58YnuWo/KOMM3txInNdlcLv6n9K/5x1b3jpfzhX+zzv zMttSizFGYmGWsxFxYkAJRB8aAcDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mcqPuW3p2YaM0DkTgVUJk0UXayI Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 02:11:02 -0000 On 10/27/2014 04:56 PM, Michiko Short wrote: > https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/ Thanks for working on this issue. I think the working group should adopt this draft. I have a few specific comments, which are editorial only: * I stumbled on the reference to "kdcToken" in section 2.2 as the concept had not yet been introduced. Some kind of indication that this is a forward reference might help. * While I don't think we have to standardize the freshness token, I have heard of realms including both MIT and Heimdal KDCs. * The first two paragraphs of the security considerations section seem to say very similar things. * The draft doesn't mention the upgrade process. I assume the plan is that KDC implementors and/or operators will just have to decide when it is reasonable to drop support for old clients which don't implement this standard. From nobody Tue Oct 28 01:32:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944BE1A1A65 for ; Tue, 28 Oct 2014 01:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdYSrjy4mCYG for ; Tue, 28 Oct 2014 01:31:21 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FC11A00AE for ; Tue, 28 Oct 2014 01:31:21 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9S8VG9N091540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Oct 2014 09:31:17 +0100 (CET) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1253 From: Rick van Rein In-Reply-To: Date: Tue, 28 Oct 2014 09:31:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40198A3C-ED75-4793-8F25-18CAFA18C074@openfortress.nl> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qgWjd0W5TCAJSh6zqJQYj5mEIic Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 08:31:25 -0000 Hi Benjamin, >> Any comments on this are highly appreciated! >=20 > It might be good to also solicit feedback from the DNS types; I'm not > actually sure if that means dnsop@ietf.org or somewhere else. (I am = not a > DNS type, so my comments will be limited in scope.) Good idea. I am a DNS type, and a DNSSEC type, but there are ones who are better for sure. > In section 4, does "the client MUST dismiss any DNS responses that are = not > Insecure, Bogus or Indeterminite" have an extra 'not=92? Well spotted! I had caught it after publication and it will be gone = next time. > I don't really understand the case-mapping text in the second = paragraph of > section 6.1 (there don't seem to be any examples that use it). Examples are a good idea, DNS->realm, openfortress.nl -> OPENFORTRESS.NL =3Dexample.=3Dc=3Do=3Dm =97> eXAMPLE.com I need to figure out if the TXT records are really case-insensitive, I = found a text saying it may not be. Then the aforementioned original mapping in DNS can be removed. > Also in 6.1, I don't think the phrase "it is useless to lookup a = Kerberos > ticket for ftp.example.com" is a valid use of "kerberos ticket=94. Do you mean I should say =93service ticket=94? That is more accurate = indeed. Thanks! -Rick= From nobody Tue Oct 28 08:56:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372591A8F49 for ; Tue, 28 Oct 2014 08:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.833 X-Spam-Level: X-Spam-Status: No, score=0.833 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgMCytP1s3qe for ; Tue, 28 Oct 2014 08:56:39 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B49FD1A8BB6 for ; Tue, 28 Oct 2014 08:56:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 7ACB7594069; Tue, 28 Oct 2014 08:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QOIGwigdLRDXbU uDbv2JLeZvuTU=; b=OwdtNdXdNOY2dSFMbAlKcLipPFot9GsAjG6F7A4FemGhp/ sdiH7w5qMPZwz8AUR8HxxRmWJIQRWLgntKIbLZkCHpes0i7Pi/sjcXh9lC1CbM1/ tnUhM/+b0yhtH6sgGQZp07QvugWq2dZ0Oa2ZO76TA31UfaCuY++h4uWZpqjeA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id DECA1594062; Tue, 28 Oct 2014 08:56:30 -0700 (PDT) Date: Tue, 28 Oct 2014 10:56:30 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141028155628.GB17213@localhost> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DRrmeOCmE10ciDzunD_8-1-i5bk Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:56:40 -0000 On Mon, Oct 27, 2014 at 02:13:55PM -0400, Benjamin Kaduk wrote: > It might be good to also solicit feedback from the DNS types; I'm not > actually sure if that means dnsop@ietf.org or somewhere else. (I am > not a DNS type, so my comments will be limited in scope.) The preference nowadays is to add new RR types wherever possible. For most cases a DNS resolver style search of a hostname's domain should suffice to find its realm, using FAST to protect each TGS in the process, and DNSSEC for every KDC search. But it is important to not cross zone cuts in this process, and to limit the number of domains/realms searched, and to not search TLDs. E.g., foo.bar.xyz.example, with a zone cut from example. to xyz.example, could have either BAR.XYZ.EXAMPLE or XYZ.EXAMPLE as its realm, but if there's a zone cut from xyz.example. to bar.xyz.example. then it could only have BAR.XYZ.EXAMPLE as its realm. (Perhaps each zone could indicate whether it's OK to search the parent's realm.) If a service in bar.xyz.example. has a realm of, say, FOO.EDU, then a search won't work. A 90% solution should suffice. Nico -- From nobody Tue Oct 28 09:26:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D131A8F4B for ; Tue, 28 Oct 2014 09:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryqnF-_CdQuM for ; Tue, 28 Oct 2014 09:25:54 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA59F1A8AF5 for ; Tue, 28 Oct 2014 09:24:07 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-66-544fc3265170 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A2.B7.09603.623CF445; Tue, 28 Oct 2014 12:24:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9SGO67Z002737 for ; Tue, 28 Oct 2014 12:24:06 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9SGO5O4017832 for ; Tue, 28 Oct 2014 12:24:05 -0400 From: Greg Hudson To: kitten@ietf.org References: Date: Tue, 28 Oct 2014 12:23:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixG6nrqt22D/E4EW/ocXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0dO7lK3gOVPFs/2LWRoYVzJ1MXJySAiYSLTf2QJli0lcuLee rYuRi0NIYDaTxLy725ggnOOMEsdOToZyOpgk9p1vZwFpYRNQlli/fyuYLSIgLLF76ztmEFtY wFDi+YTfjCC2kICjRFfzRFYQm0VAVeLYjKtgcV6gmol72lkhbEGJkzOfgM1hFpCQOPjiBfME Rt5ZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3ECA4bF9UdjBMO KR1iFOBgVOLhXdjnHyLEmlhWXJl7iFGSg0lJlNf4EFCILyk/pTIjsTgjvqg0J7X4EKMEB7OS CG/YbqAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEbxfIUMGi1PTU irTMnBKENBMHJ8hwHqDhrSA1vMUFibnFmekQ+VOMuhwtTW97mYRY8vLzUqXEectAigRAijJK 8+DmwOL9FaM40FvCvKogVTzAVAE36RXQEiagJUbTfECWlCQipKQaGKNcemZZrsuwrYioPXPq TNcFoea97QEqzHOPcjIE7DL+zhP/vkNgR+2yzIcz1MuctmXwV8+LWH6/80D3zT3M7yQUfpWz M4nVd99w1Dv8WvrC9thbfbNZv1xMCetedODupIy9fh8ZGb14mbK+z38tzvT9XD8rc078gV7d a5HMlwrkvtvFp77lVWIpzkg01GIuKk4EAAHha4TSAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wvxgpJ9dXzwLDAHxaylWs7vc08Y Subject: Re: [kitten] draft-ietf-kitten-iakerb-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:25:57 -0000 While examining the OIDs used by various Kerberos-related ASN.1 modules, I noticed that the IAKERB draft does not define a full ASN.1 module at all; it only presents fragments for IAKERB-HEADER and KRB-FINISHED. There should be an appendix in the draft containing a full module, with OID and appropriate imports declarations for the RFC 4120 types used. From nobody Tue Oct 28 09:30:14 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ABF1A0406 for ; Tue, 28 Oct 2014 09:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Zc2RS8OoGoz for ; Tue, 28 Oct 2014 09:30:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF93D1A89FF for ; Tue, 28 Oct 2014 09:30:09 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.1.6.9; Tue, 28 Oct 2014 16:29:46 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) with mapi id 15.01.0006.000; Tue, 28 Oct 2014 16:29:46 +0000 From: Michiko Short To: Greg Hudson , "kitten@ietf.org" Thread-Topic: [kitten] Comments requested on draft-short-pkinit-freshness-00 Thread-Index: Ac/yJtbghGzsElT3RuOdLMFKYwVjJgALYwuAAB3TBdA= Date: Tue, 28 Oct 2014 16:29:46 +0000 Message-ID: <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> In-Reply-To: <544EFB27.6050905@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(24454002)(479174003)(52604005)(199003)(13464003)(108616004)(33646002)(4396001)(122556002)(2171001)(76176999)(230783001)(46102003)(80022003)(40100003)(21056001)(2656002)(19580405001)(50986999)(107046002)(85852003)(85306004)(101416001)(99396003)(86612001)(86362001)(76576001)(87936001)(54356999)(19580395003)(92566001)(31966008)(97736003)(120916001)(74316001)(106356001)(2501002)(15975445006)(105586002)(77096002)(64706001)(20776003)(99286002)(76482002)(95666004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zNt4pwCF12nTh9hJ7Ulu_y7fNYc Cc: Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:30:12 -0000 Thanks for reviewing so quickly. Can you expand on your second point? Are you saying that MIT and Heimdal al= ready have something called a freshness token?=20 Agreed on the security considerations. I figured after discussions that we = would merge some of the content there, but in this first draft I wanted to = be specific. In regards to upgrade, is there something specific you were looking for in = the standard?=20 -----Original Message----- From: Greg Hudson [mailto:ghudson@mit.edu]=20 Sent: Monday, October 27, 2014 7:11 PM To: Michiko Short; kitten@ietf.org Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 On 10/27/2014 04:56 PM, Michiko Short wrote: > https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/ Thanks for working on this issue. I think the working group should adopt t= his draft. I have a few specific comments, which are editorial only: * I stumbled on the reference to "kdcToken" in section 2.2 as the concept h= ad not yet been introduced. Some kind of indication that this is a forward= reference might help. * While I don't think we have to standardize the freshness token, I have he= ard of realms including both MIT and Heimdal KDCs. * The first two paragraphs of the security considerations section seem to s= ay very similar things. * The draft doesn't mention the upgrade process. I assume the plan is that= KDC implementors and/or operators will just have to decide when it is reas= onable to drop support for old clients which don't implement this standard. From nobody Tue Oct 28 09:47:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF201A90EA for ; Tue, 28 Oct 2014 09:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH7dmQpDpsJi for ; Tue, 28 Oct 2014 09:47:20 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3F51A9076 for ; Tue, 28 Oct 2014 09:40:25 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-3e-544fc6f8cf5a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id EF.F5.27750.8F6CF445; Tue, 28 Oct 2014 12:40:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9SGeNXe003853; Tue, 28 Oct 2014 12:40:24 -0400 Received: from [18.101.8.162] (vpn-18-101-8-162.mit.edu [18.101.8.162]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9SGeMOT023587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Oct 2014 12:40:23 -0400 Message-ID: <544FC6F6.6040809@mit.edu> Date: Tue, 28 Oct 2014 12:40:22 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michiko Short , "kitten@ietf.org" References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> In-Reply-To: <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixCmqrPvjmH+IwfEXMhY/Js1gtji6eRWL xb9uPgdmjyVLfjJ5tO74yx7AFMVlk5Kak1mWWqRvl8CV0bNZvmA2f0XzpUnsDYxreLoYOTkk BEwkOv9PY4WwxSQu3FvP1sXIxSEkMJtJYsmCZUwQzkZGifXvtrJDOEeYJO4deMEO0sIroCax YMU+RhCbRUBVYtqxCywgNpuAssT6/VuBbA4OUYEwialLeSDKBSVOznwCFhYRiJCY2xoLEmYW 0JWYvqcL7AhhAW+J9093MEKs2sUocXTbdCaQBCfQmKv3lrBANOhJ7Lj+ixXClpdo3jqbeQKj 4CwkK2YhKZuFpGwBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXUO93MwSvdSU0k2M4DCW5NnB +Oag0iFGAQ5GJR5eg4d+IUKsiWXFlbmHGCU5mJREebuP+IcI8SXlp1RmJBZnxBeV5qQWH2KU 4GBWEuEN2w2U401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4E05CtQo WJSanlqRlplTgpBm4uAEGc4DNHwySA1vcUFibnFmOkT+FKOilDhvJUhCACSRUZoH1wtLM68Y xYFeEYao4gGmKLjuV0CDmYAGG03zARlckoiQkmpglLOz/eMTqiu4oGqm6rTVq+83bz+1UD46 +0Gj/VPBg5X/7TcpdVvP/vno5nPRJXLqT+xit4tvPiybHLgucmpWypk/zAoH/A99qfzHvfzR PI07J+U5BV4H+uxtXf7jRcO1nJL9wRF5LJ4GPE+fXTN8zdS1INM/1qnpohhrF48fq7XPNb0p qZwTlViKMxINtZiLihMBMluIQw4DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/n6ML4VHlVy9hC2N-45x2J6YgWXk Cc: Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:47:27 -0000 On 10/28/2014 12:29 PM, Michiko Short wrote: > Can you expand on your second point? Are you saying that MIT and Heimdal already have something called a freshness token? Oh, definitely not. The draft says "Since the freshness tokens are validated by KDCs in the same realm, standardizing the contents of the freshness token is not a concern for interoperability." I think there are occasionally interoperability concerns within a realm, but this is rare enough that the IETF doesn't need to solve those issues. > In regards to upgrade, is there something specific you were looking for in the standard? I think it would be good to put a note in security considerations that this extension only solves the problem when the KDC requires the client to implement it. > -----Original Message----- > From: Greg Hudson [mailto:ghudson@mit.edu] > Sent: Monday, October 27, 2014 7:11 PM > To: Michiko Short; kitten@ietf.org > Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 > > On 10/27/2014 04:56 PM, Michiko Short wrote: >> https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/ > > Thanks for working on this issue. I think the working group should adopt this draft. I have a few specific comments, which are editorial only: > > * I stumbled on the reference to "kdcToken" in section 2.2 as the concept had not yet been introduced. Some kind of indication that this is a forward reference might help. > > * While I don't think we have to standardize the freshness token, I have heard of realms including both MIT and Heimdal KDCs. > > * The first two paragraphs of the security considerations section seem to say very similar things. > > * The draft doesn't mention the upgrade process. I assume the plan is that KDC implementors and/or operators will just have to decide when it is reasonable to drop support for old clients which don't implement this standard. > From nobody Tue Oct 28 09:52:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3EB1A891C for ; Tue, 28 Oct 2014 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9zH6PmtsRL9 for ; Tue, 28 Oct 2014 09:52:24 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 70FB61A6EF9 for ; Tue, 28 Oct 2014 09:48:47 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 4606E598060; Tue, 28 Oct 2014 09:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=9jzoh09j6FEhJ2 KJTS3WU9O2xXM=; b=vTV8alSNjx2Mmfff7WPJNj7oXsQtwV3tBWz8KAIPNBtVkf 0wkPLGwcGR3Vy71pDCHzSeVHdIod6GXlnxOvQG5fehMTQxtMJenNBB6OyfTFlW7t iV426vfmm5zSQzM4ToBXpJsIjouI7JhDEsQFBUipLp5X3YEPP4/jXpKscqddI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id BA18E59805F; Tue, 28 Oct 2014 09:48:46 -0700 (PDT) Date: Tue, 28 Oct 2014 11:48:45 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20141028164843.GD17213@localhost> References: <544EFB27.6050905@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544EFB27.6050905@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Pcz23SXRAlNhM_cvFbQ0e9fjius Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:52:25 -0000 On Mon, Oct 27, 2014 at 10:10:47PM -0400, Greg Hudson wrote: > On 10/27/2014 04:56 PM, Michiko Short wrote: > > https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/ > > Thanks for working on this issue. I think the working group should > adopt this draft. I have a few specific comments, which are editorial only: > * While I don't think we have to standardize the freshness token, I have > heard of realms including both MIT and Heimdal KDCs. Like Michiko don't know what this means ^^. > * The draft doesn't mention the upgrade process. I assume the plan is > that KDC implementors and/or operators will just have to decide when it > is reasonable to drop support for old clients which don't implement this > standard. That seems like a reasonable plan to me. Nico -- From nobody Tue Oct 28 09:55:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BAF1A8A1C for ; Tue, 28 Oct 2014 09:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX6tmaNjgmcP for ; Tue, 28 Oct 2014 09:55:16 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 24A5C1A8AEE for ; Tue, 28 Oct 2014 09:54:15 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 003CAB806D; Tue, 28 Oct 2014 09:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+Axi54lZRu72Tv Aj1PMg3naTPX4=; b=mFWGrJ8YE7tWAAbAb5vpcPIQJU67wSzazcN1ZlWR6FnHOw huXqlsydD7hzmliCKar0lLj+4/Htd3okBPhWLaxwqRvEX4s4UQa/brcKAwouXhZM cxglwvKqIYcYRkkUlf2InYy08Vcu0V1ztULraHI8dOWbav6o+5IOw6QT/KGpw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 6ECE8B805B; Tue, 28 Oct 2014 09:54:11 -0700 (PDT) Date: Tue, 28 Oct 2014 11:54:09 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20141028165408.GE17213@localhost> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544FC6F6.6040809@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TKEZ2b2j_ZrdsNmer4Zh9-UXK3s Cc: "kitten@ietf.org" , Michiko Short , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:55:17 -0000 On Tue, Oct 28, 2014 at 12:40:22PM -0400, Greg Hudson wrote: > On 10/28/2014 12:29 PM, Michiko Short wrote: > > Can you expand on your second point? Are you saying that MIT and > > Heimdal already have something called a freshness token? > > Oh, definitely not. The draft says "Since the freshness tokens are > validated by KDCs in the same realm, standardizing the contents of the > freshness token is not a concern for interoperability." I think there > are occasionally interoperability concerns within a realm, but this is > rare enough that the IETF doesn't need to solve those issues. Oh, but the freshness token is just an opaque OCTET STRING that the KDC gives to the client for the client to repeat back to the KDC (in the AuthPack, so that it gets signed, forcing the client to make a fresh signature). There's no need to say much about the contents of the freshness token. Just that it has to be nonce-like (not repeat). Nico -- From nobody Tue Oct 28 09:58:37 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48B81A8ACA for ; Tue, 28 Oct 2014 09:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8AZcTl1DCN0 for ; Tue, 28 Oct 2014 09:58:32 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0581A8ABC for ; Tue, 28 Oct 2014 09:58:32 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id CEDA51E05C for ; Tue, 28 Oct 2014 09:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=37gzcuEe6VbicWo73XvX ZuNG+Cg=; b=wVV5vQGWUR9pdxtgslcueNixBc/MwGt3GKStyplIFVoEDYfG4zdK td1z7QgtNTnNo7ZewA90A7xuti+1RonMtHaSdcqOQNKHpEre4wdPWkreVSWrUMxz Y//dWjCtafXvtyMhg8l2qaE8XwVNXtqrJ36U3/EZnNcpdqtVY5woiqU= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 7AC981E057 for ; Tue, 28 Oct 2014 09:58:31 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so9941838wiv.9 for ; Tue, 28 Oct 2014 09:58:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.20.43 with SMTP id k11mr6462690wie.28.1414515510108; Tue, 28 Oct 2014 09:58:30 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Tue, 28 Oct 2014 09:58:30 -0700 (PDT) In-Reply-To: <20141028165408.GE17213@localhost> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> Date: Tue, 28 Oct 2014 11:58:30 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EgJA56CKlOhXBEWsTmR63JYaCt4 Cc: "kitten@ietf.org" , Michiko Short , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:58:33 -0000 On Tue, Oct 28, 2014 at 11:54 AM, Nico Williams wrote: > There's no need to say much about the contents of the freshness token. > Just that it has to be nonce-like (not repeat). Oh, actually, no, the KDCs in a realm need to be able to validate each others' freshness tokens. So they must have structure, something like {nonce, HMAC(realm_secret_key, nonce)}. Now I get Greg's comment: there are realms running a mixture of KDC implementations (Heimdal and MIT, for example). If the token is not standardized then some implementations might use an informal standard anyways. Nico -- From nobody Tue Oct 28 12:22:16 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9971AC44B for ; Tue, 28 Oct 2014 12:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwXWxE4f8Hk0 for ; Tue, 28 Oct 2014 12:22:13 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBF1AC445 for ; Tue, 28 Oct 2014 12:22:13 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id A22DC2005D82E for ; Tue, 28 Oct 2014 12:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=jP3RrmlIl33oRh1em7w9 pID1e2I=; b=Svy01tRNTDw7NpjszLT4w2f8LYfsJ0uPo+L0XLuQRUExo+Zguajw yI7j3gFjJ38S9J81kVIgQWH+9kkX/aXu5r3fqZSZjxQZ87C8RFlKzgBHEf2lNpnd 6E9Jz5cPREAvUG/maDP+dRxDFYKr7m5sojxKOR0goqjow+ED8re/H84= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 5450F2005D828 for ; Tue, 28 Oct 2014 12:22:12 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so6783831wib.4 for ; Tue, 28 Oct 2014 12:22:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.240.68 with SMTP id vy4mr7067006wjc.36.1414524131119; Tue, 28 Oct 2014 12:22:11 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Tue, 28 Oct 2014 12:22:11 -0700 (PDT) In-Reply-To: References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> Date: Tue, 28 Oct 2014 14:22:11 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Zx9xQfBP8ZIQUSYLex4ZUhABDFY Cc: "kitten@ietf.org" , Michiko Short , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:22:13 -0000 {nonce, [kvno], Checksum} seems reasonable. From nobody Tue Oct 28 13:07:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FFC1ACE57 for ; Tue, 28 Oct 2014 13:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdZJfe7uKlJm for ; Tue, 28 Oct 2014 13:06:51 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894311ACE3C for ; Tue, 28 Oct 2014 13:05:34 -0700 (PDT) X-AuditID: 1209190e-f79d46d000003643-da-544ff70d0cc2 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id DB.D1.13891.D07FF445; Tue, 28 Oct 2014 16:05:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9SK5W14018498; Tue, 28 Oct 2014 16:05:32 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9SK5UJk022420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Oct 2014 16:05:31 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9SK5TZh010615; Tue, 28 Oct 2014 16:05:30 -0400 (EDT) Date: Tue, 28 Oct 2014 16:05:29 -0400 (EDT) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <40198A3C-ED75-4793-8F25-18CAFA18C074@openfortress.nl> Message-ID: References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <40198A3C-ED75-4793-8F25-18CAFA18C074@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1605495656-1414526729=:27826" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUixCmqrcv73T/E4PEbXoujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGXMW/aGteAoa8WFaavYGhiPsHQxcnJICJhI vG08wwRhi0lcuLeerYuRi0NIYDaTRPeWBiYIZyOjxMZPi6Eyh5gk+u+tY4VwGhglln7sZwTp ZxHQllh+5T/YXDYBFYmZbzaygdgiAhoSn39NBbOZBYQl1p+bwQxiCwvYSWy/vJUdxOYUcJbY f2k5mM0r4Cix/9gRdogF6xklOjfOZwVJiAroSKzeP4UFokhQ4uTMJywQQwMlfr1tY57AKDgL SWoWkhSErSdx8Mp8RghbW+L+zTa2BYwsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RS U0o3MYLDW5JvB+PXg0qHGAU4GJV4eA0e+oUIsSaWFVfmHmKU5GBSEuUt/OofIsSXlJ9SmZFY nBFfVJqTWnyIUYKDWUmEN+UbUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxW hoNDSYJ3FshQwaLU9NSKtMycEoQ0EwcnyHAeoOGVIDW8xQWJucWZ6RD5U4y6HC1Nb3uZhFjy 8vNSpcR500EuEAApyijNg5sDS0uvGMWB3hLmvQwyigeY0uAmvQJawgS0xGiaD8iSkkSElFQD Y0rNpBOt17dpb/e+POX4FR+z7e/Uc+ycgjMrGaysZPs37px3KjElJmu/8IGWT3leZbyiqxPf X9A/xXkkOVAnPMDW4pD854v8Nee+xcRUPP8z9cXa6X+DnL96FSi295xglFk68euWGd+0H7ZY zQzif3NQTeivqVvVkoMxKgmH+w+LPui+smAVqxJLcUaioRZzUXEiABI3tcQmAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/NGCB3005fEz4SElmbH6HcY86-2U Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:06:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1605495656-1414526729=:27826 Content-Type: TEXT/PLAIN; charset=windows-1253 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 28 Oct 2014, Rick van Rein wrote: > > Also in 6.1, I don't think the phrase "it is useless to lookup a Kerber= os > > ticket for ftp.example.com" is a valid use of "kerberos ticket=94. > > Do you mean I should say =93service ticket=94? That is more accurate ind= eed. The verb "lookup" is problematic as well. I guess "request" would be best. -Ben ---559023410-1605495656-1414526729=:27826-- From nobody Tue Oct 28 13:12:25 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D991ACEC0 for ; Tue, 28 Oct 2014 13:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvedMQjrXcDa for ; Tue, 28 Oct 2014 13:12:15 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 26F661ACD9D for ; Tue, 28 Oct 2014 13:08:19 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id EE97767C072 for ; Tue, 28 Oct 2014 13:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PKYKU62//vihq6o5gR6R MPj/Dvs=; b=Hi1Hs1499f9lYdR2FQ8S3eur30+jP8VSJEVb8CWwe13f4N9wtxy0 AJNLwavRgYAf7xnhCaTKJQjNo5AybD+wKkFGFT85M62tHWSfGmhNs6ORZvYUke9C PLCXIoe7n7P4DsYdEu/4nfqCWmCWK0EKcbTipqM7ti7S+9cap7wEmCU= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 9C2B267C069 for ; Tue, 28 Oct 2014 13:08:18 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so2753650wiv.14 for ; Tue, 28 Oct 2014 13:08:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.19.234 with SMTP id i10mr1536553wie.28.1414526897217; Tue, 28 Oct 2014 13:08:17 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Tue, 28 Oct 2014 13:08:17 -0700 (PDT) In-Reply-To: References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> Date: Tue, 28 Oct 2014 15:08:17 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/vOs3C4vyGSJuLdd18UWhgvXstN8 Cc: "kitten@ietf.org" , Michiko Short , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:12:16 -0000 Better: {index, {nonce, kvno, checksum}}, or {index, {nonce, cname, realm, kvno, checksum}} (and, because of the PKCROSS work, we might want to make that cname, crealm, and srealm), where the index is an index into a cache of tokens that can be used to speed up the check when the client uses the same KDC. Is this worth standardizing? Separately, sure. Microsoft might not implement it, but MIT and Heimdal might want to. Emphasis on 'might'. Nico -- From nobody Tue Oct 28 13:29:57 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7A51ACE2A for ; Tue, 28 Oct 2014 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQCVCcCPo4wI for ; Tue, 28 Oct 2014 13:29:55 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EE2661ACEC7 for ; Tue, 28 Oct 2014 13:25:23 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id B23FC67407B for ; Tue, 28 Oct 2014 13:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=IaZ6XNhzK9Vnw8UqX1IR oxEaDJs=; b=yebuiBW/WDygJqH3X1pCxTZ56jS8mWBNzqTgyJ00X3IC/1iXoZZj wsGrxuZ+Rq/YudCQFmdub7K0jnWboXTCq9NeBgx3snPmcnKIDwl5JxBu73zrkpVq 6n60xuJToOvf0PuXitbYqQonVOpBLX7GtJiJQA2O4T/EtMaMh+XBLoc= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 61F37674078 for ; Tue, 28 Oct 2014 13:25:23 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id x13so383447wgg.19 for ; Tue, 28 Oct 2014 13:25:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.101.230 with SMTP id fj6mr30796328wib.70.1414527922220; Tue, 28 Oct 2014 13:25:22 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Tue, 28 Oct 2014 13:25:22 -0700 (PDT) In-Reply-To: References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> Date: Tue, 28 Oct 2014 15:25:22 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IJprw5_igjm9W5oa1lT-7tMMtt0 Cc: "kitten@ietf.org" , Michiko Short , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:29:56 -0000 I obviously need more caffeine today. A timestamp would also be needed, otherwise there'd be no stateless way to ensure that the token used by a client is fresh (not taken from an earlier AS exchange). From nobody Tue Oct 28 14:38:37 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56E11A897C for ; Tue, 28 Oct 2014 14:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-NESBWti4Th for ; Tue, 28 Oct 2014 14:38:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179BD1AD070 for ; Tue, 28 Oct 2014 14:38:33 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.1.6.9; Tue, 28 Oct 2014 21:38:31 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) with mapi id 15.01.0006.000; Tue, 28 Oct 2014 21:38:09 +0000 From: Michiko Short To: Nico Williams , Greg Hudson Thread-Topic: [kitten] Comments requested on draft-short-pkinit-freshness-00 Thread-Index: Ac/yJtbghGzsElT3RuOdLMFKYwVjJgALYwuAAB3TBdAAAIupAAAAezyAAAAm5AAACaaAUA== Date: Tue, 28 Oct 2014 21:38:08 +0000 Message-ID: <67800303b1294cddbd36d3add529844a@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [131.107.174.24] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(13464003)(24454002)(189002)(107046002)(101416001)(54356999)(99396003)(19580405001)(120916001)(106356001)(93886004)(95666004)(77096002)(108616004)(99286002)(76482002)(76576001)(230783001)(86612001)(105586002)(20776003)(31966008)(64706001)(122556002)(4396001)(2656002)(97736003)(21056001)(46102003)(74316001)(76176999)(86362001)(33646002)(19580395003)(50986999)(2171001)(92566001)(66066001)(85306004)(87936001)(80022003)(40100003)(85852003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pb3LkxPnb9X4q8NueqodhmwYBN4 Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:38:36 -0000 QWgsIHNvIHRoZW4gaGF2aW5nIGEgbWl4IG9mIEtEQyBpbXBsZW1lbnRhdGlvbnMgaXMgc3VwcG9y dGVkIG90aGVyIHRoYW4gd2l0aCBXaW5kb3dzIEFEIGRvbWFpbnM/IA0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmljbyBXaWxsaWFtcyBbbWFpbHRvOm5pY29AY3J5cHRvbmVj dG9yLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI4LCAyMDE0IDk6NTkgQU0NClRvOiBH cmVnIEh1ZHNvbg0KQ2M6IE1pY2hpa28gU2hvcnQ7IGtpdHRlbkBpZXRmLm9yZzsgQW5kcmVpIFBv cG92DQpTdWJqZWN0OiBSZTogW2tpdHRlbl0gQ29tbWVudHMgcmVxdWVzdGVkIG9uIGRyYWZ0LXNo b3J0LXBraW5pdC1mcmVzaG5lc3MtMDANCg0KT24gVHVlLCBPY3QgMjgsIDIwMTQgYXQgMTE6NTQg QU0sIE5pY28gV2lsbGlhbXMgPG5pY29AY3J5cHRvbmVjdG9yLmNvbT4gd3JvdGU6DQo+IFRoZXJl J3Mgbm8gbmVlZCB0byBzYXkgbXVjaCBhYm91dCB0aGUgY29udGVudHMgb2YgdGhlIGZyZXNobmVz cyB0b2tlbi4NCj4gSnVzdCB0aGF0IGl0IGhhcyB0byBiZSBub25jZS1saWtlIChub3QgcmVwZWF0 KS4NCg0KT2gsIGFjdHVhbGx5LCBubywgdGhlIEtEQ3MgaW4gYSByZWFsbSBuZWVkIHRvIGJlIGFi bGUgdG8gdmFsaWRhdGUgZWFjaCBvdGhlcnMnIGZyZXNobmVzcyB0b2tlbnMuICBTbyB0aGV5IG11 c3QgaGF2ZSBzdHJ1Y3R1cmUsIHNvbWV0aGluZyBsaWtlIHtub25jZSwgSE1BQyhyZWFsbV9zZWNy ZXRfa2V5LCBub25jZSl9Lg0KDQpOb3cgSSBnZXQgR3JlZydzIGNvbW1lbnQ6IHRoZXJlIGFyZSBy ZWFsbXMgcnVubmluZyBhIG1peHR1cmUgb2YgS0RDIGltcGxlbWVudGF0aW9ucyAoSGVpbWRhbCBh bmQgTUlULCBmb3IgZXhhbXBsZSkuICBJZiB0aGUgdG9rZW4gaXMgbm90IHN0YW5kYXJkaXplZCB0 aGVuIHNvbWUgaW1wbGVtZW50YXRpb25zIG1pZ2h0IHVzZSBhbiBpbmZvcm1hbCBzdGFuZGFyZCBh bnl3YXlzLg0KDQpOaWNvDQotLQ0K From nobody Tue Oct 28 14:41:54 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1E51AD0A8 for ; Tue, 28 Oct 2014 14:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTfQC6czpsEK for ; Tue, 28 Oct 2014 14:41:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBF81A897C for ; Tue, 28 Oct 2014 14:41:35 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.1.6.9; Tue, 28 Oct 2014 21:41:35 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.71]) with mapi id 15.01.0006.000; Tue, 28 Oct 2014 21:41:34 +0000 From: Michiko Short To: Nico Williams , Greg Hudson Thread-Topic: [kitten] Comments requested on draft-short-pkinit-freshness-00 Thread-Index: Ac/yJtbghGzsElT3RuOdLMFKYwVjJgALYwuAAB3TBdAAAIupAAAAezyAAAAm5AAABQShgAABnCuAAAMsrJA= Date: Tue, 28 Oct 2014 21:41:34 +0000 Message-ID: <70f776594ee74b5fb2cf8e3114450b9b@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [131.107.174.24] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(13464003)(189002)(107046002)(101416001)(54356999)(99396003)(19580405001)(120916001)(106356001)(93886004)(95666004)(77096002)(108616004)(99286002)(76482002)(76576001)(230783001)(86612001)(105586002)(20776003)(31966008)(64706001)(122556002)(4396001)(2656002)(97736003)(21056001)(46102003)(74316001)(76176999)(86362001)(33646002)(19580395003)(50986999)(2171001)(92566001)(66066001)(85306004)(87936001)(80022003)(40100003)(85852003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/AQPCfADZp8NEG2TvKNHH24Uwpbw Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:41:53 -0000 V2luZG93cyB1c2VzIHRoZSBBRCBmb3IgaXRzIGFjY291bnQgZGF0YWJhc2UsIHNvIHdlIGNhbm5v dCB1c2UgYW4gaW5kZXgvc2hhcmVkIGRhdGFiYXNlIG1ldGhvZC4gV2Ugd2VyZSB0aGlua2luZyBz b21ldGhpbmcgdGltZSBib3VuZCB3aXRoIHNvbWV0aGluZyB1bmlxdWUuIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmljbyBXaWxsaWFtcyBbbWFpbHRvOm5pY29AY3J5cHRv bmVjdG9yLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI4LCAyMDE0IDE6MDggUE0NClRv OiBHcmVnIEh1ZHNvbg0KQ2M6IE1pY2hpa28gU2hvcnQ7IGtpdHRlbkBpZXRmLm9yZzsgQW5kcmVp IFBvcG92DQpTdWJqZWN0OiBSZTogW2tpdHRlbl0gQ29tbWVudHMgcmVxdWVzdGVkIG9uIGRyYWZ0 LXNob3J0LXBraW5pdC1mcmVzaG5lc3MtMDANCg0KQmV0dGVyOiB7aW5kZXgsIHtub25jZSwga3Zu bywgY2hlY2tzdW19fSwgb3Ige2luZGV4LCB7bm9uY2UsIGNuYW1lLCByZWFsbSwga3ZubywgY2hl Y2tzdW19fSAoYW5kLCBiZWNhdXNlIG9mIHRoZSBQS0NST1NTIHdvcmssIHdlIG1pZ2h0IHdhbnQg dG8gbWFrZSB0aGF0IGNuYW1lLCBjcmVhbG0sIGFuZCBzcmVhbG0pLCB3aGVyZSB0aGUgaW5kZXgg aXMgYW4gaW5kZXggaW50byBhIGNhY2hlIG9mIHRva2VucyB0aGF0IGNhbiBiZSB1c2VkIHRvIHNw ZWVkIHVwIHRoZSBjaGVjayB3aGVuIHRoZSBjbGllbnQgdXNlcyB0aGUgc2FtZSBLREMuDQoNCklz IHRoaXMgd29ydGggc3RhbmRhcmRpemluZz8gIFNlcGFyYXRlbHksIHN1cmUuICBNaWNyb3NvZnQg bWlnaHQgbm90IGltcGxlbWVudCBpdCwgYnV0IE1JVCBhbmQgSGVpbWRhbCBtaWdodCB3YW50IHRv LiAgRW1waGFzaXMgb24gJ21pZ2h0Jy4NCg0KTmljbw0KLS0NCg== From nobody Tue Oct 28 14:44:43 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6439C1A9165 for ; Tue, 28 Oct 2014 14:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1dWto364ZRL for ; Tue, 28 Oct 2014 14:44:34 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C4D831AD09C for ; Tue, 28 Oct 2014 14:44:34 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 9872D2005D008 for ; Tue, 28 Oct 2014 14:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=LKtAaPH1i3cK2wGawExm zEzzx1Q=; b=Tm4jvl0vgw4lwXt95UVnnTIiyz3z3aIcYV4D91Xqg0BlB2Swg9z9 JNHLp6ZavEMfZ054IM+Qx0T1XGLmqWJr8XQ4BAKCydLMfSR656s5iQEqXBpTlDV3 lMmQcCIhSoaSIUkysOpCLhTnu2oAchWAg35ffVgEbSEFj8fmYzqaeQk= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 4F6202005D009 for ; Tue, 28 Oct 2014 14:44:34 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so527946wgh.21 for ; Tue, 28 Oct 2014 14:44:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.240.68 with SMTP id vy4mr7873961wjc.36.1414532673148; Tue, 28 Oct 2014 14:44:33 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Tue, 28 Oct 2014 14:44:33 -0700 (PDT) In-Reply-To: <67800303b1294cddbd36d3add529844a@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> <67800303b1294cddbd36d3add529844a@BL2PR03MB212.namprd03.prod.outlook.com> Date: Tue, 28 Oct 2014 16:44:33 -0500 Message-ID: From: Nico Williams To: Michiko Short Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-ADfuV4S9B4jogen-ykmpCUhR0o Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:44:36 -0000 On Tue, Oct 28, 2014 at 4:38 PM, Michiko Short wrote: > Ah, so then having a mix of KDC implementations is supported other than with Windows AD domains? FWIW, there have been alternative implementations of Windows DCs too, though I don't know if any of them have supported mixed implementations for the same domain. I would favor an optional standard for the freshness token's structure. Nico -- From nobody Tue Oct 28 14:53:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069A41AD1EE for ; Tue, 28 Oct 2014 14:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.855 X-Spam-Level: ** X-Spam-Status: No, score=2.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_CIALIS_LEO3=3.899, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kujo5bO1nlrH for ; Tue, 28 Oct 2014 14:53:45 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4D31AD0A3 for ; Tue, 28 Oct 2014 14:53:45 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 3093A36006B for ; Tue, 28 Oct 2014 14:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=kDOHVVqqA2UQoKtBLM+B rOTZ8wU=; b=Eovj6SFGRapZ2H4uYDlEurfYdEw0Bc7EWgV2SWmaWKaiNHPNN6Fn RVswVx+kSkOTVuGGJnWIlPzVsNi7vQaBlz8g0+8WCi6SNKAoeNhj1n/i/U9yVBH/ BevqE/8x1qT1bZB4/RJCt7D8dtzDMMr3gaC6T4G5mABXXU0z6f38b1U= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id D6209360059 for ; Tue, 28 Oct 2014 14:53:44 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id q5so123309wiv.4 for ; Tue, 28 Oct 2014 14:53:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.8.98 with SMTP id dj2mr8026639wid.70.1414533223836; Tue, 28 Oct 2014 14:53:43 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Tue, 28 Oct 2014 14:53:43 -0700 (PDT) In-Reply-To: <70f776594ee74b5fb2cf8e3114450b9b@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> <70f776594ee74b5fb2cf8e3114450b9b@BL2PR03MB212.namprd03.prod.outlook.com> Date: Tue, 28 Oct 2014 16:53:43 -0500 Message-ID: From: Nico Williams To: Michiko Short Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-LtLKGNSanI30PlScI0YOYmZogM Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:53:46 -0000 On Tue, Oct 28, 2014 at 4:41 PM, Michiko Short wrote: > Windows uses the AD for its account database, so we cannot use an index/shared database method. We were thinking something time bound with something unique. The index would be into a local cache, so that if the same client goes back to the same AS, then the AS can save itself the work of cryptographically verifying the freshness token, instead doing an octet-wise comparison of the token to that in the cache and checking that the timestamp in the token is "fresh". Clearly the token must notionally include a timestamp, whether it's encrypted or MACed. It may or may not need a link to the client requesting a ticket as well (cname, crealm, subjectPublicKey (if not anon), subjectPublicKeyInfo (if using DH)). We should say something about what "freshness" means. Within the last 30 seconds? Within the last minute? Clearly it should be a matter of local configuration, for some advice would help. Nico -- From nobody Tue Oct 28 15:22:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4B1A005D for ; Tue, 28 Oct 2014 15:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp7ywoIA29Dg for ; Tue, 28 Oct 2014 15:21:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0658.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:658]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31161A0053 for ; Tue, 28 Oct 2014 15:21:42 -0700 (PDT) Received: from CO1PR06MB379.namprd06.prod.outlook.com (10.141.51.11) by CO1PR06MB860.namprd06.prod.outlook.com (10.141.71.139) with Microsoft SMTP Server (TLS) id 15.1.6.9; Tue, 28 Oct 2014 22:21:19 +0000 Received: from CO2PR06CA030.namprd06.prod.outlook.com (10.141.242.30) by CO1PR06MB379.namprd06.prod.outlook.com (10.141.51.11) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 28 Oct 2014 22:21:17 +0000 Received: from BY2FFO11FD038.protection.gbl (2a01:111:f400:7c0c::190) by CO2PR06CA030.outlook.office365.com (2a01:111:e400:142a::30) with Microsoft SMTP Server (TLS) id 15.1.6.9 via Frontend Transport; Tue, 28 Oct 2014 22:21:17 +0000 Received: from mail.usda.gov (199.135.140.14) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Tue, 28 Oct 2014 22:21:16 +0000 Received: from 001FSN2MMR1-013.001f.mgd2.msft.net (199.135.140.60) by 001FSN2MMR1-004.001f.mgd2.msft.net (199.135.140.14) with Microsoft SMTP Server (TLS) id 14.3.195.2; Tue, 28 Oct 2014 22:21:06 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.27]) by 001FSN2MMR1-013.001f.mgd2.msft.net ([199.135.140.60]) with mapi id 14.03.0195.002; Tue, 28 Oct 2014 22:21:05 +0000 From: "Nordgren, Bryce L -FS" To: "kitten@ietf.org" Thread-Topic: PKCROSS comments Thread-Index: Ac/y9L53cYkX+jO0Qx+4SWsXMv7KrQ== Date: Tue, 28 Oct 2014 22:21:05 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7443E4@001FSN2MPN1-045.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.121] Content-Type: multipart/alternative; boundary="_000_82E7C9A01FD0764CACDD35D10F5DFB6E7443E4001FSN2MPN1045001_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:199.135.140.14; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(189002)(199003)(97736003)(4396001)(120916001)(2656002)(512954002)(110136001)(221733001)(19580395003)(15975445006)(68736004)(16236675004)(76482002)(55846006)(50986999)(99396003)(33656002)(54356999)(21056001)(19625215002)(2501002)(69596002)(85852003)(92566001)(16796002)(86362001)(26826002)(95666004)(71186001)(31966008)(6806004)(44976005)(15202345003)(19300405004)(64706001)(2351001)(107046002)(87936001)(92726001)(46102003)(85306004)(106466001)(229853001)(66066001)(80022003)(86146001)(81156004)(74482002)(107886001)(20776003)(77096002)(84676001)(22756005)(84326002)(80862005); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR06MB379; H:mail.usda.gov; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR06MB379; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0378F1E47A Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.14 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.14; helo=mail.usda.gov; Authentication-Results: spf=pass (sender IP is 199.135.140.14) smtp.mailfrom=bnordgren@fs.fed.us; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR06MB860; X-OriginatorOrg: fs.fed.us Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/KdwztRgx6kf4a5AC8DmOVnTFQis Subject: [kitten] PKCROSS comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:21:51 -0000 --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7443E4001FSN2MPN1045001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Me likey. Congrats on a much evolved draft! Section 2.1: "in with" should be "with": A Kerberos client in with a ticket-granting ticket (TGT) for any one source realm (usually but not necessarily the client's own realm) Section 2.2: "it allows participation by clients that do not support client-driven PKCROSS (or whose PKCROSS requests are rejected by the target)." Why would a target realm reject a client but issue an ITGT to a TGS from th= e same realm? Isn't it more or less the realm which is being evaluated for = trust? Clients can't vouch for themselves. Section 2.2.1 (mis-spelled Authenticator) Section 2.6: for symmetry's sake, should there be a mechanism for a target = KDC to hint to the source KDC that constantly requesting an ITGT is annoyin= g and permanent long term keys are going to be required (for them)? Section 3.2: add PARENT : "...pair-wise trust PARENT and "child" realms." Section 5.2: Do we pass the transit path policy from KDC to KDC? I'm not co= nvinced that a common policy language is useful except for such a case. Why= would a target KDC want to know a foreign site's advertised policy? Why wo= uld target KDC trust that the foreign site applied the policy as written? T= ransit paths, at least, are constructed in such a way that you can't edit y= ourself out. If PKCROSS really succeeds, the main function of a KDC will be to act as an= "identity firewall". It handles the coarse-grained, realm wide decisions a= bout which identity sources are made available to local services. Firewalls= don't try and share their configuration information with each other. They = just drop the connection. The KDC probably should too. Too much sharing can= be bad. Section 5.3: A] do routing algorithms for network addresses take into account "one-way c= onnections"? I can easily see a KDC in an organization's DMZ accepting PKCR= OSS, and having manually keyed cross-realm TGT from the internal realm to t= he DMZ realm. The effect would be to donate institutional users to the glob= al Kerberos ecosystem without allowing external users access to internal se= rvices. B] It seems likely that connecting to an external organization will either = be a one-hop affair via PKCROSS or completely impossible. (e.g., it seems w= eird to permit manual keying of cross realm principals from a realm that ca= n PKCROSS, but not allow PKCROSS yourself.) What would a trust router do? This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7443E4001FSN2MPN1045001_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Me likey. Congrats on a much evolved draft!

 

Section 2.1: “in with” should be “= with”:

A Kerberos client in with a ticket-granting ticket (TGT) f= or any one

   source realm (usually but not necessarily the= client's own realm)

 

Section 2.2: 

“it allows participation by clients that do not
   support client-driven PKCROSS (or whose PKCROSS requests =
are rejected
   by the target).”
 
Why would a target realm reject a client but issue an ITGT to a TGS fr=
om the same realm? Isn’t it more or less the realm which is being eva=
luated for trust? Clients can’t vouch for themselves.

 


Section 2.2.1 (mis-spelled Authenticator)


 


Section 2.6: for symmetry’s sake, should there be a mechanism fo=
r a target KDC to hint to the source KDC that constantly requesting an ITGT=
 is annoying and permanent long term keys are going to be required (for the=
m)?


 


Section 3.2: add PARENT : “…pair-wise trust PARENT and =
220;child” realms.”


 


Section 5.2: Do we pass the transit path policy from KDC to KDC? IR=
17;m not convinced that a common policy language is useful except for such =
a case. Why would a target KDC want to know a foreign site’s advertis=
ed policy? Why would target KDC trust that the foreign site applied the pol=
icy as written? Transit paths, at least, are constructed in such a way that=
 you can’t edit yourself out. 


 


If PKCROSS really succeeds, the main function of a KDC will be to act =
as an “identity firewall”. It handles the coarse-grained, realm=
 wide decisions about which identity sources are made available to local se=
rvices. Firewalls don’t try and share their configuration information=
 with each other. They just drop the connection. The KDC probably should to=
o. Too much sharing can be bad.


 


Section 5.3: 


A] do routing algorithms for network addresses take into account ̶=
0;one-way connections”? I can easily see a KDC in an organizationR=
17;s DMZ accepting PKCROSS, and having manually keyed cross-realm TGT from =
the internal realm to the DMZ realm. The effect would be to donate institut=
ional users to the global Kerberos ecosystem without allowing external user=
s access to internal services. 


B] It seems likely that connecting to an external organization will ei=
ther be a one-hop affair via PKCROSS or completely impossible. (e.g., it se=
ems weird to permit manual keying of cross realm principals from a realm th=
at can PKCROSS, but not allow PKCROSS yourself.) What would a trust router =
do?




This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you have received this message in er= ror, please notify the sender and delete the email immediately. --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7443E4001FSN2MPN1045001_-- From nobody Tue Oct 28 15:24:34 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0620A1A0069 for ; Tue, 28 Oct 2014 15:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.826 X-Spam-Level: *** X-Spam-Status: No, score=3.826 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q6P6CJecmJI for ; Tue, 28 Oct 2014 15:24:15 -0700 (PDT) Received: from nm44-vm7.bullet.mail.ne1.yahoo.com (nm44-vm7.bullet.mail.ne1.yahoo.com [98.138.120.247]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C93B1A0095 for ; Tue, 28 Oct 2014 15:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414535034; bh=bvbVzPkp/JaspOg7PzCVJIDSAm69ZASM5lCRD0gMph8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=BcLLKhpDUs1bFS9BmIWBHYGfBkas6xYhM5iy6i36qFxqkuVqnlJsiy3QxuEleYZX07NSKHRng+k0B31US0aMQQBb3aRVFc+ECmyERZoulAnTBOUNlli2diNbtwBIjFaIZxzeR1Ie3aHBxfco0tUUTaNpcsquJC0hN38tOY8g/x5kWg9rw7WkkmRvzx6rthG+hXS28e003DCCu0PY1vpGtb/7OsWLGRf+Z/a+Km1EJ7q1Kbo1v2X/Q7uDTHWUU7CaN44mLYfwIzBj/cHbQO7sKI8sSOTgFgDBasZqovrSvq4w3Dlx6dQrycCndwsKWe4eo6GacC3m93pkNuxolMwC7g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=H7r8+0r0vgPhSr6rG6b/zZEGWSttDiF8ECocvQVfAxpUDzZoRwQBVz8vFthEceTTVlogZeDh36IX97xL3mvjpDk//DuC3kz1z0BVjnNXE3fvEqc4iITizAHhHdav2XwO8zZeUrJnp+Az0ClJnJW7G6FtMTcc59EKWlUPBlt7oS4aquvOkNIEo6QBxmBKMD2FPRlIdW3Qn4INfn9D6pL0hmSOx6qt7XgjNREtgsdih0J8wlqcHdnKu8Wxb+d8zu6PHIvL7WYo50rdQ6Yc1WOxLhDCGAmzHdcT0lDSMfyN0Xr5KLuYcFGWYss2hHr+t1tPPinONd68PHv0pkSoycbiug==; Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 28 Oct 2014 22:23:54 -0000 Received: from [98.138.226.180] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 28 Oct 2014 22:20:55 -0000 Received: from [66.196.81.173] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 28 Oct 2014 22:20:04 -0000 Received: from [98.139.215.228] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 28 Oct 2014 22:20:03 -0000 Received: from [127.0.0.1] by omp1068.mail.bf1.yahoo.com with NNFMP; 28 Oct 2014 22:20:03 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 952992.24514.bm@omp1068.mail.bf1.yahoo.com X-YMail-OSG: NkWdXm4VM1lV7Q97iUYAu0G7uwjrcMQracycgWcO1zAZWop3BGS.8Or0xziAJuy sYrWSc9M6JFJOe7UHCK6unFq6JQG0YYzFFCFH5dlMQGyBPE28Go6p9gNvqXH7LlNIP78a1Ed5FPE I4XwT4ioaElAoC_BeNiRhPbZ5NtaKVle33FVH34aLFGMMSJ7v2jdKIQki9mYr0KT1uzf029ygKwu fX6gFS5OAUm.rl7oXcun96iop2jmaAM7oEtl.3IWnLvfpDZWGcheHYYI7yjp5UrcHp54X_ai1YXz gTE0Tg_mCjVfhMnMzVeEYPc1TsKk7_1OG.xVARrDukpwk91NQVEZypnqxqzLhW6z4DYcTSrutllb msm0AOSMm.rVp1m9OG2peQZzsDAb2JNBRHNJum9N6QTCEMvsMh3Ik4KFm.u8Q8GSM0kivzTfZS1D XaCvBFiIS7PcljbrxqbhyKTYeIP_vCvCm7TdEKgtsTYr7ZhZPzGlgBpXHv0lKOh3ekJAjMef0eRV ZE1AUGe4QJuHZ07Dnac01N6F5uxEc6qK6K4AB1jHIvWHuyweWeptPdpOBaXBOlp7NMUE- Received: by 66.196.81.116; Tue, 28 Oct 2014 22:20:03 +0000 Date: Tue, 28 Oct 2014 22:20:02 +0000 (UTC) From: Bill Mills To: =?UTF-8?Q?=E2=8C=98_Matt_Miller?= , Benjamin Kaduk Message-ID: <2122430389.819476.1414534802288.JavaMail.yahoo@jws10633.mail.bf1.yahoo.com> In-Reply-To: <544EACAA.6070506@cisco.com> References: <544EACAA.6070506@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_819475_1041334597.1414534802287" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UgAS_vTd-u5-Yci7nR8e6qaml7k Cc: "kitten@ietf.org" Subject: [kitten] draft-17 Re: proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:24:29 -0000 ------=_Part_819475_1041334597.1414534802287 Content-Type: multipart/alternative; boundary="----=_Part_819474_1068201204.1414534802284" ------=_Part_819474_1068201204.1414534802284 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the color there, I think that's a fair characterization of norma= tive vs. informative. =C2=A0Attached is my -17 current cut. =C2=A0Window ha= s closed for publication already I guess. =C2=A0Posted for discussion. -bill =20 On Monday, October 27, 2014 1:35 PM, =E2=8C=98 Matt Miller wrote: =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/27/14, 2:27 PM, Bill Mills wrote: > Is it fair to say the discovery docs are informative rather than=20 > normative?=C2=A0 I think so because they are SHOULD rathe rthan MUST. >=20 >=20 /me doffs hat SHOULD means "do it unless you understand unless you have a good reason (and understand the consequences) to not do it." To me, that would mean you have to understand the "it", to know if you understand have a good reason (and understand the consequences) to not follow the SHOULD.=C2=A0 If you have to understand something, then which (to me) means it's normative. The decision on whether or not a reference is normative can't be based on whether its publication is impacted, but on if it's important to understand the referenced material before one can implement the given specification. - --=20 - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > On Monday, October 27, 2014 12:28 PM, Benjamin Kaduk > wrote: >=20 >=20 > On Tue, 21 Oct 2014, Bill Mills wrote: >=20 >> how does the inclusion of working drafts rather than finished >> drafts affect the process?=C2=A0 Inclusion of the dynamic registration >> stuff would do that. >=20 > To some extent it depends on the specifics; if I understand > correctly, in the general case, if draft A makes a normative > reference to draft B, then draft A can be approved by the IESG for > publication, but does not get actually published by the RFC Editor > until draft B is also approved, so they get published in the same > batch.=C2=A0 Such a dependency wouldn't necessarily hold up our WG work > on it. >=20 >=20 > -Ben >=20 >=20 >=20 >=20 > _______________________________________________ Kitten mailing > list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUTqyqAAoJEDWi+S0W7cO1+c8IAKVWhWJWlsW7U6NkaoCD8ZV1 0cVeNPaU3XWrwEIhc1BGK5DccmJuc+725tR5F9RxPFJRUJAlotwbBFXc7wVGK05D nDjqm3SDVl3kq0l7ZvNry2g24QV0iAkB0MljZhMlJPxRAGZEpz98/9yLSTtdN6G5 oWpWo/9xdyGaALstVdaFzrRHidPu7Sqk9UZdrjWiFB5NHniqqU3bdQDZPhOxxSD5 rWT2hW6qKYepl4rh9nTxfV139scKzWfcTV+BRnb/UKPqzcqzH49cuDus43BMJMd5 x7AXpBlmSliohpnepL2/irtv5IKiOFUb9R3mpI2EH7OqKWfYlDmwR98jKMbFNHw=3D =3Dkxu6 -----END PGP SIGNATURE----- ------=_Part_819474_1068201204.1414534802284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the color there, I t= hink that's a fair characterization of normative vs. informative.  Att= ached is my -17 current cut.  Window has closed for publication alread= y I guess.  Posted for discussion.

-bill

<= div class=3D"qtdSeparateBR">

On Monday, October 27, 2014 1:35 PM, =E2=8C=98 Matt Miller= <mamille2@cisco.com> wrote:


-----BEGIN PGP SIGNED MESSAGE-----
H= ash: SHA512

On 10/27/14, 2:27 PM, Bill= Mills wrote:
> Is it fair to say the discovery docs a= re informative rather than
> normative?  I think= so because they are SHOULD rathe rthan MUST.
>
>

/me doffs hat

SHOULD means "do it unless you understand u= nless you have a good
reason (and understand the conseque= nces) to not do it."

To me, that would= mean you have to understand the "it", to know if you
und= erstand have a good reason (and understand the consequences) to not
follow the SHOULD.  If you have to understand something, th= en which
(to me) means it's normative.
=
The decision on whether or not a reference is normative = can't be based
on whether its publication is impacted, bu= t on if it's important to
understand the referenced mater= ial before one can implement the given
specification.


- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.<= div class=3D"yqt2945863406" id=3D"yqtfd65491">

> On Monday, October 27, 2014 12:28 PM, Benjamin Kaduk
> <kaduk@MIT.EDU> wrote:
&g= t;
>
> On Tue, 21 Oct 2014, Bil= l Mills wrote:
>
>> how does = the inclusion of working drafts rather than finished
>= > drafts affect the process?  Inclusion of the dynamic registration=
>> stuff would do that.
> > To some extent it depends on the specifics; if I under= stand
> correctly, in the general case, if draft A mak= es a normative
> reference to draft B, then draft A ca= n be approved by the IESG for
> publication, but does = not get actually published by the RFC Editor
> until d= raft B is also approved, so they get published in the same
> batch.  Such a dependency wouldn't necessarily hold up our WG w= ork
> on it.
>
>
> -Ben

>
>
>
>
> _______________________________________________ Kitten mailing<= br clear=3D"none">> list Kitten@ietf.org ht= tps://www.ietf.org/mailman/listinfo/kitten
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GP= GTools - https://gpgtools.org

iQEcBAEBCgAG= BQJUTqyqAAoJEDWi+S0W7cO1+c8IAKVWhWJWlsW7U6NkaoCD8ZV1
0cVe= NPaU3XWrwEIhc1BGK5DccmJuc+725tR5F9RxPFJRUJAlotwbBFXc7wVGK05D
nDjqm3SDVl3kq0l7ZvNry2g24QV0iAkB0MljZhMlJPxRAGZEpz98/9yLSTtdN6G5
oWpWo/9xdyGaALstVdaFzrRHidPu7Sqk9UZdrjWiFB5NHniqqU3bdQDZPhOxxSD= 5
rWT2hW6qKYepl4rh9nTxfV139scKzWfcTV+BRnb/UKPqzcqzH49cuDu= s43BMJMd5
x7AXpBlmSliohpnepL2/irtv5IKiOFUb9R3mpI2EH7OqKWf= YlDmwR98jKMbFNHw=3D
=3Dkxu6
-----END PG= P SIGNATURE-----



------=_Part_819474_1068201204.1414534802284-- ------=_Part_819475_1041334597.1414534802287 Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=draft-ietf-kitten-sasl-oauth-17.html Content-ID: <6d0a2990-cdf7-972d-fc7a-aa6074c51126@yahoo.com> PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIg CiAgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXN0cmljdC5kdGQiPgoK PGh0bWwgbGFuZz0iZW4iIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6 bGFuZz0iZW4iPgo8aGVhZCBwcm9maWxlPSJodHRwOi8vd3d3LnczLm9yZy8yMDA2LzAzL2hjYXJk JTIwaHR0cDovL2R1YmxpbmNvcmUub3JnL2RvY3VtZW50cy8yMDA4LzA4LzA0L2RjLWh0bWwvIj4K ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11cy1hc2NpaSIgLz4KCiAgPHRpdGxlPkEgc2V0IG9mIFNBU0wgTWVjaGFuaXNtcyBmb3Ig T0F1dGg8L3RpdGxlPgoKICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiIHRpdGxlPSJYbWwyUmZjIChz YW5zIHNlcmlmKSI+CiAgLyo8IVtDREFUQVsqLwoJICBhIHsKCSAgdGV4dC1kZWNvcmF0aW9uOiBu b25lOwoJICB9CgkgIGEuc21wbCB7CgkgIGNvbG9yOiBibGFjazsKCSAgfQoJICBhOmhvdmVyIHsK CSAgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7CgkgIH0KCSAgYTphY3RpdmUgewoJICB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsKCSAgfQoJICBhZGRyZXNzIHsKCSAgbWFyZ2luLXRvcDog MWVtOwoJICBtYXJnaW4tbGVmdDogMmVtOwoJICBmb250LXN0eWxlOiBub3JtYWw7CgkgIH0KCSAg Ym9keSB7CgkgIGNvbG9yOiBibGFjazsKCSAgZm9udC1mYW1pbHk6IHZlcmRhbmEsIGhlbHZldGlj YSwgYXJpYWwsIHNhbnMtc2VyaWY7CgkgIGZvbnQtc2l6ZTogMTBwdDsKCSAgCgkgIH0KCSAgY2l0 ZSB7CgkgIGZvbnQtc3R5bGU6IG5vcm1hbDsKCSAgfQoJICBkZCB7CgkgIG1hcmdpbi1yaWdodDog MmVtOwoJICB9CgkgIGRsIHsKCSAgbWFyZ2luLWxlZnQ6IDJlbTsKCSAgfQoJCgkgIHVsLmVtcHR5 IHsKCSAgbGlzdC1zdHlsZS10eXBlOiBub25lOwoJICB9CgkgIHVsLmVtcHR5IGxpIHsKCSAgbWFy Z2luLXRvcDogLjVlbTsKCSAgfQoJICBkbCBwIHsKCSAgbWFyZ2luLWxlZnQ6IDBlbTsKCSAgfQoJ ICBkdCB7CgkgIG1hcmdpbi10b3A6IC41ZW07CgkgIH0KCSAgaDEgewoJICBmb250LXNpemU6IDE0 cHQ7CgkgIGxpbmUtaGVpZ2h0OiAyMXB0OwoJICBwYWdlLWJyZWFrLWFmdGVyOiBhdm9pZDsKCSAg fQoJICBoMS5ucCB7CgkgIHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7CgkgIH0KCSAgaDEgYSB7 CgkgIGNvbG9yOiAjMzMzMzMzOwoJICB9CgkgIGgyIHsKCSAgZm9udC1zaXplOiAxMnB0OwoJICBs aW5lLWhlaWdodDogMTVwdDsKCSAgcGFnZS1icmVhay1hZnRlcjogYXZvaWQ7CgkgIH0KCSAgaDMs IGg0LCBoNSwgaDYgewoJICBmb250LXNpemU6IDEwcHQ7CgkgIHBhZ2UtYnJlYWstYWZ0ZXI6IGF2 b2lkOwoJICB9CgkgIGgyIGEsIGgzIGEsIGg0IGEsIGg1IGEsIGg2IGEgewoJICBjb2xvcjogYmxh Y2s7CgkgIH0KCSAgaW1nIHsKCSAgbWFyZ2luLWxlZnQ6IDNlbTsKCSAgfQoJICBsaSB7CgkgIG1h cmdpbi1sZWZ0OiAyZW07CgkgIG1hcmdpbi1yaWdodDogMmVtOwoJICB9CgkgIG9sIHsKCSAgbWFy Z2luLWxlZnQ6IDJlbTsKCSAgbWFyZ2luLXJpZ2h0OiAyZW07CgkgIH0KCSAgb2wgcCB7CgkgIG1h cmdpbi1sZWZ0OiAwZW07CgkgIH0KCSAgcCB7CgkgIG1hcmdpbi1sZWZ0OiAyZW07CgkgIG1hcmdp bi1yaWdodDogMmVtOwoJICB9CgkgIHByZSB7CgkgIG1hcmdpbi1sZWZ0OiAzZW07CgkgIGJhY2tn cm91bmQtY29sb3I6IGxpZ2h0eWVsbG93OwoJICBwYWRkaW5nOiAuMjVlbTsKCSAgfQoJICBwcmUu dGV4dDIgewoJICBib3JkZXItc3R5bGU6IGRvdHRlZDsKCSAgYm9yZGVyLXdpZHRoOiAxcHg7Cgkg IGJhY2tncm91bmQtY29sb3I6ICNmMGYwZjA7CgkgIHdpZHRoOiA2OWVtOwoJICB9CgkgIHByZS5p bmxpbmUgewoJICBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsKCSAgcGFkZGluZzogMGVtOwoJICB9 CgkgIHByZS50ZXh0IHsKCSAgYm9yZGVyLXN0eWxlOiBkb3R0ZWQ7CgkgIGJvcmRlci13aWR0aDog MXB4OwoJICBiYWNrZ3JvdW5kLWNvbG9yOiAjZjhmOGY4OwoJICB3aWR0aDogNjllbTsKCSAgfQoJ ICBwcmUuZHJhd2luZyB7CgkgIGJvcmRlci1zdHlsZTogc29saWQ7CgkgIGJvcmRlci13aWR0aDog MXB4OwoJICBiYWNrZ3JvdW5kLWNvbG9yOiAjZjhmOGY4OwoJICBwYWRkaW5nOiAyZW07CgkgIH0K CSAgdGFibGUgewoJICBtYXJnaW4tbGVmdDogMmVtOwoJICB9CgkgIHRhYmxlLnR0IHsKCSAgdmVy dGljYWwtYWxpZ246IHRvcDsKCSAgfQoJICB0YWJsZS5mdWxsIHsKCSAgYm9yZGVyLXN0eWxlOiBv dXRzZXQ7CgkgIGJvcmRlci13aWR0aDogMXB4OwoJICB9CgkgIHRhYmxlLmhlYWRlcnMgewoJICBi b3JkZXItc3R5bGU6IG91dHNldDsKCSAgYm9yZGVyLXdpZHRoOiAxcHg7CgkgIH0KCSAgdGFibGUu dHQgdGQgewoJICB2ZXJ0aWNhbC1hbGlnbjogdG9wOwoJICB9CgkgIHRhYmxlLmZ1bGwgdGQgewoJ ICBib3JkZXItc3R5bGU6IGluc2V0OwoJICBib3JkZXItd2lkdGg6IDFweDsKCSAgfQoJICB0YWJs ZS50dCB0aCB7CgkgIHZlcnRpY2FsLWFsaWduOiB0b3A7CgkgIH0KCSAgdGFibGUuZnVsbCB0aCB7 CgkgIGJvcmRlci1zdHlsZTogaW5zZXQ7CgkgIGJvcmRlci13aWR0aDogMXB4OwoJICB9CgkgIHRh YmxlLmhlYWRlcnMgdGggewoJICBib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBpbnNldCBub25lOwoJ ICBib3JkZXItd2lkdGg6IDFweDsKCSAgfQoJICB0YWJsZS5sZWZ0IHsKCSAgbWFyZ2luLXJpZ2h0 OiBhdXRvOwoJICB9CgkgIHRhYmxlLnJpZ2h0IHsKCSAgbWFyZ2luLWxlZnQ6IGF1dG87CgkgIH0K CSAgdGFibGUuY2VudGVyIHsKCSAgbWFyZ2luLWxlZnQ6IGF1dG87CgkgIG1hcmdpbi1yaWdodDog YXV0bzsKCSAgfQoJICBjYXB0aW9uIHsKCSAgY2FwdGlvbi1zaWRlOiBib3R0b207CgkgIGZvbnQt d2VpZ2h0OiBib2xkOwoJICBmb250LXNpemU6IDlwdDsKCSAgbWFyZ2luLXRvcDogLjVlbTsKCSAg fQoJCgkgIHRhYmxlLmhlYWRlciB7CgkgIGJvcmRlci1zcGFjaW5nOiAxcHg7CgkgIHdpZHRoOiA5 NSU7CgkgIGZvbnQtc2l6ZTogMTBwdDsKCSAgY29sb3I6IHdoaXRlOwoJICB9CgkgIHRkLnRvcCB7 CgkgIHZlcnRpY2FsLWFsaWduOiB0b3A7CgkgIH0KCSAgdGQudG9wbm93cmFwIHsKCSAgdmVydGlj YWwtYWxpZ246IHRvcDsKCSAgd2hpdGUtc3BhY2U6IG5vd3JhcDsgCgkgIH0KCSAgdGFibGUuaGVh ZGVyIHRkIHsKCSAgYmFja2dyb3VuZC1jb2xvcjogZ3JheTsKCSAgd2lkdGg6IDUwJTsKCSAgfQoJ ICB0YWJsZS5oZWFkZXIgYSB7CgkgIGNvbG9yOiB3aGl0ZTsKCSAgfQoJICB0ZC5yZWZlcmVuY2Ug ewoJICB2ZXJ0aWNhbC1hbGlnbjogdG9wOwoJICB3aGl0ZS1zcGFjZTogbm93cmFwOwoJICBwYWRk aW5nLXJpZ2h0OiAxZW07CgkgIH0KCSAgdGhlYWQgewoJICBkaXNwbGF5OnRhYmxlLWhlYWRlci1n cm91cDsKCSAgfQoJICB1bC50b2MsIHVsLnRvYyB1bCB7CgkgIGxpc3Qtc3R5bGU6IG5vbmU7Cgkg IG1hcmdpbi1sZWZ0OiAxLjVlbTsKCSAgbWFyZ2luLXJpZ2h0OiAwZW07CgkgIHBhZGRpbmctbGVm dDogMGVtOwoJICB9CgkgIHVsLnRvYyBsaSB7CgkgIGxpbmUtaGVpZ2h0OiAxNTAlOwoJICBmb250 LXdlaWdodDogYm9sZDsKCSAgZm9udC1zaXplOiAxMHB0OwoJICBtYXJnaW4tbGVmdDogMGVtOwoJ ICBtYXJnaW4tcmlnaHQ6IDBlbTsKCSAgfQoJICB1bC50b2MgbGkgbGkgewoJICBsaW5lLWhlaWdo dDogbm9ybWFsOwoJICBmb250LXdlaWdodDogbm9ybWFsOwoJICBmb250LXNpemU6IDlwdDsKCSAg bWFyZ2luLWxlZnQ6IDBlbTsKCSAgbWFyZ2luLXJpZ2h0OiAwZW07CgkgIH0KCSAgbGkuZXhjbHVk ZWQgewoJICBmb250LXNpemU6IDBwdDsKCSAgfQoJICB1bCBwIHsKCSAgbWFyZ2luLWxlZnQ6IDBl bTsKCSAgfQoJCgkgIC5jb21tZW50IHsKCSAgYmFja2dyb3VuZC1jb2xvcjogeWVsbG93OwoJICB9 CgkgIC5jZW50ZXIgewoJICB0ZXh0LWFsaWduOiBjZW50ZXI7CgkgIH0KCSAgLmVycm9yIHsKCSAg Y29sb3I6IHJlZDsKCSAgZm9udC1zdHlsZTogaXRhbGljOwoJICBmb250LXdlaWdodDogYm9sZDsK CSAgfQoJICAuZmlndXJlIHsKCSAgZm9udC13ZWlnaHQ6IGJvbGQ7CgkgIHRleHQtYWxpZ246IGNl bnRlcjsKCSAgZm9udC1zaXplOiA5cHQ7CgkgIH0KCSAgLmZpbGVuYW1lIHsKCSAgY29sb3I6ICMz MzMzMzM7CgkgIGZvbnQtd2VpZ2h0OiBib2xkOwoJICBmb250LXNpemU6IDEycHQ7CgkgIGxpbmUt aGVpZ2h0OiAyMXB0OwoJICB0ZXh0LWFsaWduOiBjZW50ZXI7CgkgIH0KCSAgLmZuIHsKCSAgZm9u dC13ZWlnaHQ6IGJvbGQ7CgkgIH0KCSAgLmhpZGRlbiB7CgkgIGRpc3BsYXk6IG5vbmU7CgkgIH0K CSAgLmxlZnQgewoJICB0ZXh0LWFsaWduOiBsZWZ0OwoJICB9CgkgIC5yaWdodCB7CgkgIHRleHQt YWxpZ246IHJpZ2h0OwoJICB9CgkgIC50aXRsZSB7CgkgIGNvbG9yOiAjOTkwMDAwOwoJICBmb250 LXNpemU6IDE4cHQ7CgkgIGxpbmUtaGVpZ2h0OiAxOHB0OwoJICBmb250LXdlaWdodDogYm9sZDsK CSAgdGV4dC1hbGlnbjogY2VudGVyOwoJICBtYXJnaW4tdG9wOiAzNnB0OwoJICB9CgkgIC52Y2Fy ZGxpbmUgewoJICBkaXNwbGF5OiBibG9jazsKCSAgfQoJICAud2FybmluZyB7CgkgIGZvbnQtc2l6 ZTogMTRwdDsKCSAgYmFja2dyb3VuZC1jb2xvcjogeWVsbG93OwoJICB9CgkKCQoJICBAbWVkaWEg cHJpbnQgewoJICAubm9wcmludCB7CgkJZGlzcGxheTogbm9uZTsKCSAgfQoJCgkgIGEgewoJCWNv bG9yOiBibGFjazsKCQl0ZXh0LWRlY29yYXRpb246IG5vbmU7CgkgIH0KCQoJICB0YWJsZS5oZWFk ZXIgewoJCXdpZHRoOiA5MCU7CgkgIH0KCQoJICB0ZC5oZWFkZXIgewoJCXdpZHRoOiA1MCU7CgkJ Y29sb3I6IGJsYWNrOwoJCWJhY2tncm91bmQtY29sb3I6IHdoaXRlOwoJCXZlcnRpY2FsLWFsaWdu OiB0b3A7CgkJZm9udC1zaXplOiAxMnB0OwoJICB9CgkKCSAgdWwudG9jIGE6OmFmdGVyIHsKCQlj b250ZW50OiBsZWFkZXIoJy4nKSB0YXJnZXQtY291bnRlcihhdHRyKGhyZWYpLCBwYWdlKTsKCSAg fQoJCgkgIHVsLmluZCBsaSBsaSBhIHsKCQljb250ZW50OiB0YXJnZXQtY291bnRlcihhdHRyKGhy ZWYpLCBwYWdlKTsKCSAgfQoJCgkgIC5wcmludDJjb2wgewoJCWNvbHVtbi1jb3VudDogMjsKCQkt bW96LWNvbHVtbi1jb3VudDogMjsKCQljb2x1bW4tZmlsbDogYXV0bzsKCSAgfQoJICB9CgkKCSAg QHBhZ2UgewoJICBAdG9wLWxlZnQgewoJCSAgIGNvbnRlbnQ6ICJJbnRlcm5ldC1EcmFmdCI7IAoJ ICB9IAoJICBAdG9wLXJpZ2h0IHsKCQkgICBjb250ZW50OiAiRGVjZW1iZXIgMjAxMCI7IAoJICB9 IAoJICBAdG9wLWNlbnRlciB7CgkJICAgY29udGVudDogIkFiYnJldmlhdGVkIFRpdGxlIjszCgkg IH0gCgkgIEBib3R0b20tbGVmdCB7CgkJICAgY29udGVudDogIkRvZSI7IAoJICB9IAoJICBAYm90 dG9tLWNlbnRlciB7CgkJICAgY29udGVudDogIkV4cGlyZXMgSnVuZSAyMDExIjsgCgkgIH0gCgkg IEBib3R0b20tcmlnaHQgewoJCSAgIGNvbnRlbnQ6ICJbUGFnZSAiIGNvdW50ZXIocGFnZSkgIl0i OyAKCSAgfSAKCSAgfQoJCgkgIEBwYWdlOmZpcnN0IHsgCgkJQHRvcC1sZWZ0IHsKCQkgIGNvbnRl bnQ6IG5vcm1hbDsKCQl9CgkJQHRvcC1yaWdodCB7CgkJICBjb250ZW50OiBub3JtYWw7CgkJfQoJ CUB0b3AtY2VudGVyIHsKCQkgIGNvbnRlbnQ6IG5vcm1hbDsKCQl9CgkgIH0KICAvKl1dPiovCiAg PC9zdHlsZT4KCiAgPGxpbmsgaHJlZj0iI3JmYy50b2MiIHJlbD0iQ29udGVudHMiPgo8bGluayBo cmVmPSIjcmZjLnNlY3Rpb24uMSIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMSBJbnRyb2R1Y3Rpb24i Pgo8bGluayBocmVmPSIjcmZjLnNlY3Rpb24uMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMiBUZXJt aW5vbG9neSI+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi4zIiByZWw9IkNoYXB0ZXIiIHRpdGxl PSIzIE9BdXRoIFNBU0wgTWVjaGFuaXNtIFNwZWNpZmljYXRpb25zIj4KPGxpbmsgaHJlZj0iI3Jm Yy5zZWN0aW9uLjMuMSIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMy4xIEluaXRpYWwgQ2xpZW50IFJl c3BvbnNlIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMS4xIiByZWw9IkNoYXB0ZXIiIHRp dGxlPSIzLjEuMSBSZXNlcnZlZCBLZXkvVmFsdWVzIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9u LjMuMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMy4yIFNlcnZlcidzIFJlc3BvbnNlIj4KPGxpbmsg aHJlZj0iI3JmYy5zZWN0aW9uLjMuMi4xIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSIzLjIuMSBPQXV0 aCBJZGVudGlmaWVycyBpbiB0aGUgU0FTTCBDb250ZXh0Ij4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0 aW9uLjMuMi4yIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSIzLjIuMiBTZXJ2ZXIgUmVzcG9uc2UgdG8g RmFpbGVkIEF1dGhlbnRpY2F0aW9uIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMi4zIiBy ZWw9IkNoYXB0ZXIiIHRpdGxlPSIzLjIuMyBDb21wbGV0aW5nIGFuIEVycm9yIE1lc3NhZ2UgU2Vx dWVuY2UiPgo8bGluayBocmVmPSIjcmZjLnNlY3Rpb24uMy4zIiByZWw9IkNoYXB0ZXIiIHRpdGxl PSIzLjMgT0F1dGggQWNjZXNzIFRva2VuIFR5cGVzIHVzaW5nIEtleWVkIE1lc3NhZ2UgRGlnZXN0 cyI+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi40IiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI0IEV4 YW1wbGVzIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjQuMSIgcmVsPSJDaGFwdGVyIiB0aXRs ZT0iNC4xIFN1Y2Nlc3NmdWwgQmVhcmVyIFRva2VuIEV4Y2hhbmdlIj4KPGxpbmsgaHJlZj0iI3Jm Yy5zZWN0aW9uLjQuMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iNC4yIFN1Y2Nlc3NmdWwgT0F1dGgg MS4wYSBUb2tlbiBFeGNoYW5nZSI+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi40LjMiIHJlbD0i Q2hhcHRlciIgdGl0bGU9IjQuMyBGYWlsZWQgRXhjaGFuZ2UiPgo8bGluayBocmVmPSIjcmZjLnNl Y3Rpb24uNC40IiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI0LjQgU01UUCBFeGFtcGxlIG9mIGEgRmFp bGVkIE5lZ290aWF0aW9uIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjUiIHJlbD0iQ2hhcHRl ciIgdGl0bGU9IjUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPgo8bGluayBocmVmPSIjcmZjLnNl Y3Rpb24uNiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iNiBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb25z aWRlcmF0aW9ucyI+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi43IiByZWw9IkNoYXB0ZXIiIHRp dGxlPSI3IElBTkEgQ29uc2lkZXJhdGlvbnMiPgo8bGluayBocmVmPSIjcmZjLnNlY3Rpb24uNy4x IiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI3LjEgU0FTTCBSZWdpc3RyYXRpb24iPgo8bGluayBocmVm PSIjcmZjLnJlZmVyZW5jZXMiIHJlbD0iQ2hhcHRlciIgdGl0bGU9IjggUmVmZXJlbmNlcyI+Cjxs aW5rIGhyZWY9IiNyZmMucmVmZXJlbmNlcy4xIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI4LjEgTm9y bWF0aXZlIFJlZmVyZW5jZXMiPgo8bGluayBocmVmPSIjcmZjLnJlZmVyZW5jZXMuMiIgcmVsPSJD aGFwdGVyIiB0aXRsZT0iOC4yIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMiPgo8bGluayBocmVmPSIj cmZjLmFwcGVuZGl4LkFwcGVuZGl4JTIwQSIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iQXBwZW5kaXgg QSBBY2tub3dsZWdlbWVudHMiPgo8bGluayBocmVmPSIjcmZjLmFwcGVuZGl4LkFwcGVuZGl4JTIw QiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iQXBwZW5kaXggQiBEb2N1bWVudCBIaXN0b3J5Ij4KPGxp bmsgaHJlZj0iI3JmYy5hdXRob3JzIiByZWw9IkNoYXB0ZXIiPgoKCiAgPG1ldGEgbmFtZT0iZ2Vu ZXJhdG9yIiBjb250ZW50PQogICJodHRwOi8vZ3JlZW5ieXRlcy5kZS90ZWNoL3dlYmRhdi9yZmMy NjI5LnhzbHQsIFJldmlzaW9uIDEuNTM5LCAyMDExLTAxLTAyIDE3OjEzOjAwLCBYU0xUIHZlbmRv cjogU0FYT04gNi41LjUgZnJvbSBNaWNoYWVsIEtheSBodHRwOi8vc2F4b24uc2YubmV0LyIgLz4K ICA8bGluayByZWw9InNjaGVtYS5kY3QiIGhyZWY9Imh0dHA6Ly9wdXJsLm9yZy9kYy90ZXJtcy8i IC8+CiAgPG1ldGEgbmFtZT0iZGN0LmNyZWF0b3IiIGNvbnRlbnQ9IkRvZSwgSi4iIC8+CiAgPG1l dGEgbmFtZT0iZGN0LmlkZW50aWZpZXIiIGNvbnRlbnQ9InVybjppZXRmOmlkOmRyYWZ0LXNhbXBs ZS1pbnB1dC0wMCIgLz4KICA8bWV0YSBuYW1lPSJkY3QuaXNzdWVkIiBzY2hlbWU9IklTTzg2MDEi IGNvbnRlbnQ9IjIwMTAtMTIiIC8+CiAgCiAgPG1ldGEgbmFtZT0iZGN0LmFic3RyYWN0IiBjb250 ZW50PSJPQXV0aCBlbmFibGVzIGEgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gdG8gb2J0YWluIGxp bWl0ZWQgYWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlLCBlaXRoZXIgb24gYmVoYWxmIG9m IGEgcmVzb3VyY2Ugb3duZXIgYnkgb3JjaGVzdHJhdGluZyBhbiBhcHByb3ZhbCBpbnRlcmFjdGlv biwgb3IgYnkgYWxsb3dpbmcgdGhlIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBh Y2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuICAiIC8+CiAgPG1ldGEgbmFtZT0iZGVzY3JpcHRpb24i IGNvbnRlbnQ9Ik9BdXRoIGVuYWJsZXMgYSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiB0byBvYnRh aW4gbGltaXRlZCBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2UsIGVpdGhlciBvbiBiZWhh bGYgb2YgYSByZXNvdXJjZSBvd25lciBieSBvcmNoZXN0cmF0aW5nIGFuIGFwcHJvdmFsIGludGVy YWN0aW9uLCBvciBieSBhbGxvd2luZyB0aGUgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gdG8gb2J0 YWluIGFjY2VzcyBvbiBpdHMgb3duIGJlaGFsZi4gICIgLz4KICA8bWV0YSBuYW1lPSJrZXl3b3Jk cyIgY29udGVudD0iIiAvPgoKPC9oZWFkPgoKPGJvZHk+CgogIDx0YWJsZSBjbGFzcz0iaGVhZGVy Ij4KICAgIDx0Ym9keT4KICAgIAogICAgCTx0cj4KPHRkIGNsYXNzPSJsZWZ0Ij5LSVRURU48L3Rk Pgo8dGQgY2xhc3M9InJpZ2h0Ij5XLiBNaWxsczwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNzPSJs ZWZ0Ij5JbnRlcm5ldC1EcmFmdDwvdGQ+Cjx0ZCBjbGFzcz0icmlnaHQiPk1pY3Jvc29mdDwvdGQ+ CjwvdHI+Cjx0cj4KPHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBU cmFjazwvdGQ+Cjx0ZCBjbGFzcz0icmlnaHQiPlQuIFNob3dhbHRlcjwvdGQ+CjwvdHI+Cjx0cj4K PHRkIGNsYXNzPSJsZWZ0Ij5FeHBpcmVzOiBBcHJpbCAyOSwgMjAxNTwvdGQ+Cjx0ZCBjbGFzcz0i cmlnaHQiPkguVC4gVHNjaG9mZW5pZzwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPgo8dGQgY2xhc3M9InJpZ2h0Ij5BUk0gTHRkLjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNz PSJsZWZ0Ij48L3RkPgo8dGQgY2xhc3M9InJpZ2h0Ij5PY3RvYmVyIDI4LCAyMDE0PC90ZD4KPC90 cj4KCiAgICAJCiAgICA8L3Rib2R5PgogIDwvdGFibGU+CgogIDxwIGNsYXNzPSJ0aXRsZSI+QSBz ZXQgb2YgU0FTTCBNZWNoYW5pc21zIGZvciBPQXV0aDxiciAvPgogIDxzcGFuIGNsYXNzPSJmaWxl bmFtZSI+ZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0xNy50eHQ8L3NwYW4+PC9wPgogIAog IDxoMSBpZD0icmZjLmFic3RyYWN0Ij48YSBocmVmPSIjcmZjLmFic3RyYWN0Ij5BYnN0cmFjdDwv YT48L2gxPgo8cD5PQXV0aCBlbmFibGVzIGEgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gdG8gb2J0 YWluIGxpbWl0ZWQgYWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlLCBlaXRoZXIgb24gYmVo YWxmIG9mIGEgcmVzb3VyY2Ugb3duZXIgYnkgb3JjaGVzdHJhdGluZyBhbiBhcHByb3ZhbCBpbnRl cmFjdGlvbiwgb3IgYnkgYWxsb3dpbmcgdGhlIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9i dGFpbiBhY2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuICA8L3A+CjxwPlRoaXMgZG9jdW1lbnQgZGVm aW5lcyBob3cgYW4gYXBwbGljYXRpb24gY2xpZW50IHVzZXMgY3JlZGVudGlhbHMgb2J0YWluZWQg dmlhIE9BdXRoIG92ZXIgdGhlIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5 ZXIgKFNBU0wpIHRvIGFjY2VzcyBhIHByb3RlY3RlZCByZXNvdXJjZSBhdCBhIHJlc291cmNlIHNl cnZlLiAgVGhlcmVieSwgaXQgZW5hYmxlcyBzY2hlbWVzIGRlZmluZWQgd2l0aGluIHRoZSBPQXV0 aCBmcmFtZXdvcmsgZm9yIG5vbi1IVFRQLWJhc2VkIGFwcGxpY2F0aW9uIHByb3RvY29scy4gIDwv cD4KPHA+Q2xpZW50cyB0eXBpY2FsbHkgc3RvcmUgdGhlIHVzZXIncyBsb25nLXRlcm0gY3JlZGVu dGlhbC4gVGhpcyBkb2VzLCBob3dldmVyLCBsZWFkIHRvIHNpZ25pZmljYW50IHNlY3VyaXR5IHZ1 bG5lcmFiaWxpdGllcywgZm9yIGV4YW1wbGUsIHdoZW4gc3VjaCBhIGNyZWRlbnRpYWwgbGVha3Mu IEEgc2lnbmlmaWNhbnQgYmVuZWZpdCBvZiBPQXV0aCBmb3IgdXNhZ2UgaW4gdGhvc2UgY2xpZW50 cyBpcyB0aGF0IHRoZSBwYXNzd29yZCBpcyByZXBsYWNlZCBieSBhIHNoYXJlZCBzZWNyZXQgd2l0 aCBoaWdoZXIgZW50cm9weSwgaS5lLiwgdGhlIHRva2VuLiBUb2tlbnMgdHlwaWNhbGx5IHByb3Zp ZGUgbGltaXRlZCBhY2Nlc3MgcmlnaHRzIGFuZCBjYW4gYmUgbWFuYWdlZCBhbmQgcmV2b2tlZCBz ZXBhcmF0ZWx5IGZyb20gdGhlIHVzZXIncyBsb25nLXRlcm0gcGFzc3dvcmQuICA8L3A+CjxoMSBp ZD0icmZjLnN0YXR1cyI+PGEgaHJlZj0iI3JmYy5zdGF0dXMiPlN0YXR1cyBvZiB0aGlzIE1lbW88 L2E+PC9oMT4KPHA+VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LjwvcD4KPHA+ SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0gRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC9wPgo8cD5JbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyBy ZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIjwvcD4KPHA+VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBcHJp bCAyOSwgMjAxNS48L3A+CjxoMSBpZD0icmZjLmNvcHlyaWdodG5vdGljZSI+PGEgaHJlZj0iI3Jm Yy5jb3B5cmlnaHRub3RpY2UiPkNvcHlyaWdodCBOb3RpY2U8L2E+PC9oMT4KPHA+Q29weXJpZ2h0 IChjKSAyMDE0IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvcD4KPHA+VGhpcyBkb2N1bWVu dCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbCBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlvbiBvZiB0aGlz IGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0 aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0IHRv IHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1 bWVudCBtdXN0IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHBy b3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLjwvcD4KCiAgCiAgPGhyIGNsYXNzPSJub3ByaW50IiAvPgogIDxoMSBjbGFzcz0i bnAiIGlkPSJyZmMudG9jIj48YSBocmVmPSIjcmZjLnRvYyI+VGFibGUgb2YgQ29udGVudHM8L2E+ PC9oMT4KICA8dWwgY2xhc3M9InRvYyI+CgogIAk8bGk+MS4gICA8YSBocmVmPSIjcmZjLnNlY3Rp b24uMSI+SW50cm9kdWN0aW9uPC9hPgo8L2xpPgo8bGk+Mi4gICA8YSBocmVmPSIjcmZjLnNlY3Rp b24uMiI+VGVybWlub2xvZ3k8L2E+CjwvbGk+CjxsaT4zLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlv bi4zIj5PQXV0aCBTQVNMIE1lY2hhbmlzbSBTcGVjaWZpY2F0aW9uczwvYT4KPC9saT4KPGxpPjMu MS4gICA8YSBocmVmPSIjcmZjLnNlY3Rpb24uMy4xIj5Jbml0aWFsIENsaWVudCBSZXNwb25zZTwv YT4KPC9saT4KPGxpPjMuMS4xLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjEuMSI+UmVzZXJ2 ZWQgS2V5L1ZhbHVlczwvYT4KPC9saT4KPGxpPjMuMi4gICA8YSBocmVmPSIjcmZjLnNlY3Rpb24u My4yIj5TZXJ2ZXIncyBSZXNwb25zZTwvYT4KPC9saT4KPGxpPjMuMi4xLiAgIDxhIGhyZWY9IiNy ZmMuc2VjdGlvbi4zLjIuMSI+T0F1dGggSWRlbnRpZmllcnMgaW4gdGhlIFNBU0wgQ29udGV4dDwv YT4KPC9saT4KPGxpPjMuMi4yLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjIuMiI+U2VydmVy IFJlc3BvbnNlIHRvIEZhaWxlZCBBdXRoZW50aWNhdGlvbjwvYT4KPC9saT4KPGxpPjMuMi4zLiAg IDxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjIuMyI+Q29tcGxldGluZyBhbiBFcnJvciBNZXNzYWdl IFNlcXVlbmNlPC9hPgo8L2xpPgo8bGk+My4zLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjMi Pk9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlcyB1c2luZyBLZXllZCBNZXNzYWdlIERpZ2VzdHM8L2E+ CjwvbGk+CjxsaT40LiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi40Ij5FeGFtcGxlczwvYT4KPC9s aT4KPGxpPjQuMS4gICA8YSBocmVmPSIjcmZjLnNlY3Rpb24uNC4xIj5TdWNjZXNzZnVsIEJlYXJl ciBUb2tlbiBFeGNoYW5nZTwvYT4KPC9saT4KPGxpPjQuMi4gICA8YSBocmVmPSIjcmZjLnNlY3Rp b24uNC4yIj5TdWNjZXNzZnVsIE9BdXRoIDEuMGEgVG9rZW4gRXhjaGFuZ2U8L2E+CjwvbGk+Cjxs aT40LjMuICAgPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjQuMyI+RmFpbGVkIEV4Y2hhbmdlPC9hPgo8 L2xpPgo8bGk+NC40LiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi40LjQiPlNNVFAgRXhhbXBsZSBv ZiBhIEZhaWxlZCBOZWdvdGlhdGlvbjwvYT4KPC9saT4KPGxpPjUuICAgPGEgaHJlZj0iI3JmYy5z ZWN0aW9uLjUiPlNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC9hPgo8L2xpPgo8bGk+Ni4gICA8YSBo cmVmPSIjcmZjLnNlY3Rpb24uNiI+SW50ZXJuYXRpb25hbGl6YXRpb24gQ29uc2lkZXJhdGlvbnM8 L2E+CjwvbGk+CjxsaT43LiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi43Ij5JQU5BIENvbnNpZGVy YXRpb25zPC9hPgo8L2xpPgo8bGk+Ny4xLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi43LjEiPlNB U0wgUmVnaXN0cmF0aW9uPC9hPgo8L2xpPgo8bGk+OC4gICA8YSBocmVmPSIjcmZjLnJlZmVyZW5j ZXMiPlJlZmVyZW5jZXM8L2E+CjwvbGk+CjxsaT44LjEuICAgPGEgaHJlZj0iI3JmYy5yZWZlcmVu Y2VzLjEiPk5vcm1hdGl2ZSBSZWZlcmVuY2VzPC9hPgo8L2xpPgo8bGk+OC4yLiAgIDxhIGhyZWY9 IiNyZmMucmVmZXJlbmNlcy4yIj5JbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC9hPgo8L2xpPgo8bGk+ QXBwZW5kaXggQS4gICA8YSBocmVmPSIjcmZjLmFwcGVuZGl4LkFwcGVuZGl4JTIwQSI+QWNrbm93 bGVnZW1lbnRzPC9hPgo8L2xpPgo8bGk+QXBwZW5kaXggQi4gICA8YSBocmVmPSIjcmZjLmFwcGVu ZGl4LkFwcGVuZGl4JTIwQiI+RG9jdW1lbnQgSGlzdG9yeTwvYT4KPC9saT4KPGxpPjxhIGhyZWY9 IiNyZmMuYXV0aG9ycyI+QXV0aG9ycycgQWRkcmVzc2VzPC9hPgo8L2xpPgoKCiAgPC91bD4KCiAg PGgxIGlkPSJyZmMuc2VjdGlvbi4xIj4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjEiPjEuPC9hPiBJ bnRyb2R1Y3Rpb248L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uMS5wLjEiPk9BdXRoIDEuMGEgPGEg aHJlZj0iI1JGQzU4NDkiPltSRkM1ODQ5XTwvYT4gYW5kIE9BdXRoIDIuMCA8YSBocmVmPSIjUkZD Njc0OSI+W1JGQzY3NDldPC9hPiBhcmUgcHJvdG9jb2wgZnJhbWV3b3JrcyB0aGF0IGVuYWJsZSBh IHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBsaW1pdGVkIGFjY2VzcyB0byBhIHBy b3RlY3RlZCByZXNvdXJjZSwgZWl0aGVyIG9uIGJlaGFsZiBvZiBhIHJlc291cmNlIG93bmVyIGJ5 IG9yY2hlc3RyYXRpbmcgYW4gYXBwcm92YWwgaW50ZXJhY3Rpb24sIG9yIGJ5IGFsbG93aW5nIHRo ZSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiB0byBvYnRhaW4gYWNjZXNzIG9uIGl0cyBvd24gYmVo YWxmLiA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4xLnAuMiI+VGhlIGNvcmUgT0F1dGggMi4wIHNw ZWNpZmljYXRpb24gPGEgaHJlZj0iI1JGQzY3NDkiPltSRkM2NzQ5XTwvYT4gc3BlY2lmaWVzIHRo ZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBPQXV0aCBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlcjsgaXQgZG9lcyBub3QgZGVmaW5lIHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRo ZSBPQXV0aCBjbGllbnQgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXIgZm9yIHRoZSBhY2Nlc3MgdG8g YSBwcm90ZWN0ZWQgcmVzb3VyY2UgdXNpbmcgYW4gQWNjZXNzIFRva2VuLiAgSW5zdGVhZCwgdGhl IE9BdXRoIGNsaWVudCB0byByZXNvdXJjZSBzZXJ2ZXIgaW50ZXJhY3Rpb24gaXMgZGVzY3JpYmVk IGluIHNlcGFyYXRlIHNwZWNpZmljYXRpb25zLCBzdWNoIGFzIHRoZSBiZWFyZXIgdG9rZW4gc3Bl Y2lmaWNhdGlvbiA8YSBocmVmPSIjUkZDNjc1MCI+W1JGQzY3NTBdPC9hPiBhbmQgdGhlIE1BQyBU b2tlbiBzcGVjaWZpY2F0aW9uIDxhIGhyZWY9IiNJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hYyI+ W0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFjXTwvYT4uIE9BdXRoIDEuMGEgaW5jbHVkZWQgdGhl IHByb3RvY29sIHNwZWNpZmljYXRpb24gZm9yIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhl IE9BdXRoIGNsaWVudCBhbmQgdGhlIHJlc291cmNlIHNlcnZlciBpbiA8YSBocmVmPSIjUkZDNTg0 OSI+W1JGQzU4NDldPC9hPi4gIDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjEucC4zIj5UaGUgbWFp biB1c2UgY2FzZXMgZm9yIE9BdXRoIDIuMCBhbmQgT0F1dGggMS4wYSBoYXZlIHNvIGZhciBmb2N1 c2VkIG9uIGFuIEhUVFAtYmFzZWQgPGEgaHJlZj0iI1JGQzI2MTYiPltSRkMyNjE2XTwvYT4gZW52 aXJvbm1lbnQgb25seS4gIFRoaXMgZG9jdW1lbnQgaW50ZWdyYXRlcyBPQXV0aCAxLjBhIGFuZCBP QXV0aCAyLjAgaW50byBub24tSFRUUC1iYXNlZCBhcHBsaWNhdGlvbnMgdXNpbmcgdGhlIGludGVn cmF0aW9uIGludG8gU0FTTC4gIEhlbmNlLCB0aGlzIGRvY3VtZW50ICB0YWtlcyBhZHZhbnRhZ2Ug b2YgdGhlIE9BdXRoIHByb3RvY29sIGFuZCBpdHMgZGVwbG95bWVudCBiYXNlIHRvIHByb3ZpZGUg YSB3YXkgdG8gdXNlIHRoZSBTaW1wbGUgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyaXR5IExheWVy IChTQVNMKSA8YSBocmVmPSIjUkZDNDQyMiI+W1JGQzQ0MjJdPC9hPiB0byBnYWluIGFjY2VzcyB0 byByZXNvdXJjZXMgd2hlbiB1c2luZyBub24tSFRUUC1iYXNlZCBwcm90b2NvbHMsIHN1Y2ggYXMg dGhlIEludGVybmV0IE1lc3NhZ2UgQWNjZXNzIFByb3RvY29sIChJTUFQKSA8YSBocmVmPSIjUkZD MzUwMSI+W1JGQzM1MDFdPC9hPiBhbmQgdGhlIFNpbXBsZSBNYWlsIFRyYW5zZmVyIFByb3RvY29s IChTTVRQKSA8YSBocmVmPSIjUkZDNTMyMSI+W1JGQzUzMjFdPC9hPiwgd2hpY2ggaXMgd2hhdCB0 aGlzIG1lbW8gdXNlcyBpbiB0aGUgZXhhbXBsZXMuPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uMS5w LjQiPlRvIGlsbHVzdHJhdGUgdGhlIGltcGFjdCBvZiBpbnRlZ3JhdGluZyB0aGlzIHNwZWNpZmlj YXRpb24gaW50byBhbiBPQXV0aC1lbmFibGVkIGFwcGxpY2F0aW9uIGVudmlyb25tZW50LCA8YSBo cmVmPSIjb3ZlcnZpZXciPkZpZ3VyZSAxPC9hPiBzaG93cyB0aGUgYWJzdHJhY3QgbWVzc2FnZSBm bG93IG9mIE9BdXRoIDIuMCA8YSBocmVmPSIjUkZDNjc0OSI+W1JGQzY3NDldPC9hPi4gQXMgaW5k aWNhdGVkIGluIHRoZSBmaWd1cmUsIHRoaXMgZG9jdW1lbnQgaW1wYWN0cyB0aGUgZXhjaGFuZ2Ug b2YgbWVzc2FnZXMgKEUpIGFuZCAoRikgc2luY2UgU0FTTCBpcyB1c2VkIGZvciBpbnRlcmFjdGlv biBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXIgaW5zdGVhZCBvZiBI VFRQLjwvcD4KPGRpdiBpZD0iI3JmYy5maWd1cmUuMSI+PC9kaXY+CjxkaXYgaWQ9IiNvdmVydmll dyI+PC9kaXY+CjxwcmU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0tLSsKICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfAogICB8ICAgICAgICB8LS0oQSkt LSBBdXRob3JpemF0aW9uIFJlcXVlc3QgLS0tJmd0O3wgICBSZXNvdXJjZSAgICB8ICB8CiAgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgT3duZXIgICAg IHwgIHxQbGFpbgogICB8ICAgICAgICB8Jmx0Oy0oQiktLS0tLS0gQWNjZXNzIEdyYW50IC0tLS0t LS0tLXwgICAgICAgICAgICAgICB8ICB8T0F1dGgKICAgfCAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfDIuMAogICB8ICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAog ICB8ICAgICAgICB8ICAgICAgICAgQ2xpZW50IENyZWRlbnRpYWxzICZhbXA7ICAgICArLS0tLS0t LS0tLS0tLS0tKyAgfAogICB8ICAgICAgICB8LS0oQyktLS0tLS0gQWNjZXNzIEdyYW50IC0tLS0t LS0tJmd0O3wgQXV0aG9yaXphdGlvbiB8ICB8CiAgIHwgQ2xpZW50IHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwgIHwKICAgfCAgICAgICAgfCZsdDst KEQpLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS18ICAgICAgICAgICAgICAgfCAgfAogICB8 ICAgICAgICB8ICAgICAgKHcvIE9wdGlvbmFsIFJlZnJlc2ggVG9rZW4pICstLS0tLS0tLS0tLS0t LS0rICB8CiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0tLSsKICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLS0tKwogICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICB8CiAgIHwgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgIHxPQXV0aAog ICB8ICAgICAgICB8LS0oRSktLS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tJmd0O3wgICAgUmVz b3VyY2UgICB8ICB8b3ZlcgogICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgIFNlcnZlciAgICB8ICB8U0FTTAogICB8ICAgICAgICB8Jmx0Oy0oRiktLS0t IFByb3RlY3RlZCBSZXNvdXJjZSAtLS0tLXwgICAgICAgICAgICAgICB8ICB8CiAgIHwgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgIHwK ICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tKyAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tLS0rCjwvcHJlPgo8cD48L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4x LnAuNiI+VGhlIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNBU0wp IGlzIGEgZnJhbWV3b3JrIGZvciBwcm92aWRpbmcgYXV0aGVudGljYXRpb24gYW5kIGRhdGEgc2Vj dXJpdHkgc2VydmljZXMgaW4gY29ubmVjdGlvbi1vcmllbnRlZCBwcm90b2NvbHMgdmlhIHJlcGxh Y2VhYmxlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuICBJdCBwcm92aWRlcyBhIHN0cnVjdHVy ZWQgaW50ZXJmYWNlIGJldHdlZW4gcHJvdG9jb2xzIGFuZCBtZWNoYW5pc21zLiAgVGhlIHJlc3Vs dGluZyBmcmFtZXdvcmsgYWxsb3dzIG5ldyBwcm90b2NvbHMgdG8gcmV1c2UgZXhpc3RpbmcgYXV0 aGVudGljYXRpb24gcHJvdG9jb2xzIGFuZCBhbGxvd3Mgb2xkIHByb3RvY29scyB0byBtYWtlIHVz ZSBvZiBuZXcgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcy4gIFRoZSBmcmFtZXdvcmsgYWxzbyBw cm92aWRlcyBhIHByb3RvY29sIGZvciBzZWN1cmluZyBzdWJzZXF1ZW50IGV4Y2hhbmdlcyB3aXRo aW4gYSBkYXRhIHNlY3VyaXR5IGxheWVyLjwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjEucC43Ij5X aGVuIE9BdXRoIGlzIGludGVncmF0ZWQgaW50byBTQVNMIHRoZSBoaWdoLWxldmVsIHN0ZXBzIGFy ZSBhcyBmb2xsb3dzOiA8L3A+Cgo8dWwgY2xhc3M9ImVtcHR5Ij4KPGxpPihBKSAgVGhlIGNsaWVu dCByZXF1ZXN0cyBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlIG93bmVyLiAgVGhlIGF1 dGhvcml6YXRpb24gcmVxdWVzdCBjYW4gYmUgbWFkZSBkaXJlY3RseSB0byB0aGUgcmVzb3VyY2Ug b3duZXIgKGFzIHNob3duKSwgb3IgcHJlZmVyYWJseSBpbmRpcmVjdGx5IHZpYSB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgYXMgYW4gaW50ZXJtZWRpYXJ5LjwvbGk+CjxsaT4oQikgIFRoZSBjbGll bnQgcmVjZWl2ZXMgYW4gYXV0aG9yaXphdGlvbiBncmFudCB3aGljaCBpcyBhIGNyZWRlbnRpYWwg cmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRpb24sIGV4cHJlc3Nl ZCB1c2luZyBvbmUgb2YgdGhlIGdyYW50IHR5cGVzIGRlZmluZWQgaW4gPGEgaHJlZj0iI1JGQzY3 NDkiPltSRkM2NzQ5XTwvYT4gb3IgPGEgaHJlZj0iI1JGQzU4NDkiPltSRkM1ODQ5XTwvYT4gb3Ig dXNpbmcgYW4gZXh0ZW5zaW9uIGdyYW50IHR5cGUuICBUaGUgYXV0aG9yaXphdGlvbiBncmFudCB0 eXBlIGRlcGVuZHMgb24gdGhlIG1ldGhvZCB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gcmVxdWVzdCBh dXRob3JpemF0aW9uIGFuZCB0aGUgdHlwZXMgc3VwcG9ydGVkIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci48L2xpPgo8bGk+KEMpICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tl biBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcHJl c2VudGluZyB0aGUgYXV0aG9yaXphdGlvbiBncmFudC48L2xpPgo8bGk+KEQpICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMgdGhl IGF1dGhvcml6YXRpb24gZ3JhbnQsIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYW4gYWNjZXNzIHRva2Vu LjwvbGk+CjxsaT4oRSkgIFRoZSBjbGllbnQgcmVxdWVzdHMgdGhlIHByb3RlY3RlZCByZXNvdXJj ZSBmcm9tIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0ZXMgYnkgcHJlc2VudGlu ZyB0aGUgYWNjZXNzIHRva2VuLjwvbGk+CjxsaT4oRikgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFs aWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgaW5kaWNhdGVzIGEgc3VjY2Vz c2Z1bCBhdXRoZW50aWNhdGlvbi48L2xpPgo8L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0 aW9uLjEucC44Ij5BZ2Fpbiwgc3RlcHMgKEUpIGFuZCAoRikgYXJlIG5vdCBkZWZpbmVkIGluIDxh IGhyZWY9IiNSRkM2NzQ5Ij5bUkZDNjc0OV08L2E+IChidXQgYXJlIGRlc2NyaWJlZCBpbiwgZm9y IGV4YW1wbGUsIDxhIGhyZWY9IiNSRkM2NzUwIj5bUkZDNjc1MF08L2E+IGZvciB0aGUgT0F1dGgg QmVhcmVyIFRva2VuIGluc3RlYWQpIGFuZCBhcmUgdGhlIG1haW4gZnVuY3Rpb25hbGl0eSBzcGVj aWZpZWQgd2l0aGluIHRoaXMgZG9jdW1lbnQuIENvbnNlcXVlbnRseSwgdGhlIG1lc3NhZ2UgZXhj aGFuZ2Ugc2hvd24gaW4gPGEgaHJlZj0iI292ZXJ2aWV3Ij5GaWd1cmUgMTwvYT4gaXMgdGhlIHJl c3VsdCBvZiB0aGlzIHNwZWNpZmljYXRpb24uIFRoZSBjbGllbnQgd2lsbCBnZW5lcmFsbHkgbmVl ZCB0byBkZXRlcm1pbmUgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBvaW50cyAoYW5kIHBlcmhhcHMg dGhlIHNlcnZpY2UgZW5kcG9pbnRzKSBiZWZvcmUgdGhlIE9BdXRoIDIuMCBwcm90b2NvbCBleGNo YW5nZSBtZXNzYWdlcyBpbiBzdGVwcyAoQSktKEQpIGFyZSBleGVjdXRlZC4gVGhlIGRpc2NvdmVy eSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIsIGF1dGhvcml6YXRpb24gc2VydmVyIGVuZHBvaW50cywg YW5kIGNsaWVudCByZWdpc3RyYXRpb24gYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4gVGhlIGNsaWVudCBtdXN0IGRpc2NvdmVyIHRoZSBhdXRob3JpemF0aW9uIGVu ZHBvaW50cyB1c2luZyBhIGRpc2NvdmVyeSBtZWNoYW5pc20gc3VjaCBhcyBPcGVuSUQgQ29ubmVj dCBEaXNjb3ZlcnkgPGEgaHJlZj0iI09wZW5JRC5EaXNjb3ZlcnkiPltPcGVuSUQuRGlzY292ZXJ5 XTwvYT4gb3IgV2ViZmluZ2VyIHVzaW5nIGhvc3QtbWV0YSA8YSBocmVmPSIjUkZDNzAzMyI+W1JG QzcwMzNdPC9hPi4gIE9uY2UgY3JlZGVudGlhbHMgYXJlIG9idGFpbmVkIHRoZSBjbGllbnQgcHJv Y2VlZHMgdG8gc3RlcHMgKEUpIGFuZCAoRikgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24u ICBBdXRob3JpemF0aW9uIGVuZHBvaW50cyBNQVkgcmVxdWlyZSBjbGllbnQgcmVnaXN0cmF0aW9u IGFuZCBnZW5lcmljIGNsaWVudHMgU0hPVUxEIHN1cHBvcnQgdGhlIER5bmFtaWMgQ2xpZW50IFJl Z2lzdHJhdGlvbiBwcm90b2NvbCAgPGEgaHJlZj0iI0ktRC5pZXRmLW9hdXRoLWR5bi1yZWciPltJ LUQuaWV0Zi1vYXV0aC1keW4tcmVnXTwvYT4uICA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4xLnAu OSI+T0F1dGggMS4wIGZvbGxvd3MgYSBzaW1pbGFyIG1vZGVsIGJ1dCB1c2VzIGEgZGlmZmVyZW50 IHRlcm1pbm9sb2d5IGFuZCBkb2VzIG5vdCBzZXBhcmF0ZSB0aGUgcmVzb3VyY2Ugc2VydmVyIGZy b20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLjwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi4yIj4K PGEgaHJlZj0iI3JmYy5zZWN0aW9uLjIiPjIuPC9hPiA8YSBocmVmPSIjdGVybWlub2xvZ3kiIGlk PSJ0ZXJtaW5vbG9neSI+VGVybWlub2xvZ3k8L2E+CjwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi4y LnAuMSI+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIDxhIGhyZWY9IiNSRkMyMTE5Ij5bUkZDMjExOV08L2E+LjwvcD4K PHAgaWQ9InJmYy5zZWN0aW9uLjIucC4yIj5UaGUgcmVhZGVyIGlzIGFzc3VtZWQgdG8gYmUgZmFt aWxpYXIgd2l0aCB0aGUgdGVybXMgdXNlZCBpbiB0aGUgT0F1dGggMi4wIHNwZWNpZmljYXRpb24g PGEgaHJlZj0iI1JGQzY3NDkiPltSRkM2NzQ5XTwvYT4gYW5kIFNBU0wgPGEgaHJlZj0iI1JGQzQ0 MjIiPltSRkM0NDIyXTwvYT4uPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uMi5wLjMiPkluIGV4YW1w bGVzLCAiQzoiIGFuZCAiUzoiIGluZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQg c2VydmVyIHJlc3BlY3RpdmVseS4gTGluZSBicmVha3MgaGF2ZSBiZWVuIGluc2VydGVkIGZvciBy ZWFkYWJpbGl0eS48L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4yLnAuNCI+Tm90ZSB0aGF0IHRoZSBJ TUFQIFNBU0wgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyBiYXNlNjQgZW5jb2RpbmcsIHNlZSBTZWN0 aW9uIDQgb2YgPGEgaHJlZj0iI1JGQzQ2NDgiPltSRkM0NjQ4XTwvYT4sIG5vdCB0aGlzIG1lbW8u PC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjMiPgo8YSBocmVmPSIjcmZjLnNlY3Rpb24uMyI+My48 L2E+IDxhIGhyZWY9IiNTQVNMLU9BVVRIIiBpZD0iU0FTTC1PQVVUSCI+T0F1dGggU0FTTCBNZWNo YW5pc20gU3BlY2lmaWNhdGlvbnM8L2E+CjwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi4zLnAuMSI+ U0FTTCBpcyB1c2VkIGFzIGFuIGF1dGhlbnRpY2F0aW9uIGZyYW1ld29yayBpbiBhIHZhcmlldHkg b2YgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2xzLiBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhl IGZvbGxvd2luZyBTQVNMIG1lY2hhbmlzbXMgZm9yIHVzYWdlIHdpdGggT0F1dGg6IDwvcD4KCjx1 bCBjbGFzcz0iZW1wdHkiPjxsaT4KPGRsPgo8ZHQ+T0FVVEhCRUFSRVI6PC9kdD4KPGRkIHN0eWxl PSJtYXJnaW4tbGVmdDogOCI+T0F1dGggMi4wIGJlYXJlciB0b2tlbnMsIGFzIGRlc2NyaWJlZCBp biA8YSBocmVmPSIjUkZDNjc1MCI+W1JGQzY3NTBdPC9hPi4gUkZDIDY3NTAgdXNlcyBUcmFuc3Bv cnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgdG8gc2VjdXJlIHRoZSBwcm90b2NvbCBpbnRlcmFjdGlv biBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXIuPC9kZD4KPGR0Pk9B VVRIMTBBOjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPk9BdXRoIDEuMGEgTUFDIHRv a2VucyAodXNpbmcgdGhlIEhNQUMtU0hBMSBrZXllZCBtZXNzYWdlIGRpZ2VzdCksIGFzIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDMuNC4yIG9mIDxhIGhyZWY9IiNSRkM1ODQ5Ij5bUkZDNTg0OV08L2E+ LiAgPC9kZD4KPC9kbD4KPHA+IDwvcD4KPC9saT48L3VsPgoKPHA+IE5ldyBleHRlbnNpb25zIG1h eSBiZSBkZWZpbmVkIHRvIGFkZCBhZGRpdGlvbmFsIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlcy4g U3VjaCBhIG5ldyBTQVNMIE9BdXRoIG1lY2hhbmlzbSBjYW4gYmUgYWRkZWQgYnkgc2ltcGx5IHJl Z2lzdGVyaW5nIHRoZSBuZXcgbmFtZShzKSBhbmQgY2l0aW5nIHRoaXMgc3BlY2lmaWNhdGlvbiBm b3IgdGhlIGZ1cnRoZXIgZGVmaW5pdGlvbi4gIDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMucC4y Ij5UaGVzZSBtZWNoYW5pc21zIGFyZSBjbGllbnQgaW5pdGlhdGVkIGFuZCBsb2NrLXN0ZXAsIHRo ZSBzZXJ2ZXIgYWx3YXlzIHJlcGx5aW5nIHRvIGEgY2xpZW50IG1lc3NhZ2UuICBJbiB0aGUgY2Fz ZSB3aGVyZSB0aGUgY2xpZW50IGhhcyBhbmQgY29ycmVjdGx5IHVzZXMgYSB2YWxpZCB0b2tlbiB0 aGUgZmxvdyBpczogPC9wPgoKPG9sPgo8bGk+Q2xpZW50IHNlbmRzIGEgdmFsaWQgYW5kIGNvcnJl Y3QgaW5pdGlhbCBjbGllbnQgcmVzcG9uc2UuICA8L2xpPgo8bGk+U2VydmVyIHJlc3BvbmRzIHdp dGggYSBzdWNjZXNzZnVsIGF1dGhlbnRpY2F0aW9uLiAgPC9saT4KPC9vbD4KCjxwPiBJbiB0aGUg Y2FzZSB3aGVyZSBhdXRob3JpemF0aW9uIGZhaWxzIHRoZSBzZXJ2ZXIgc2VuZHMgYW4gZXJyb3Ig cmVzdWx0LCB0aGVuIGNsaWVudCBNVVNUIHRoZW4gc2VuZCBhbiBhZGRpdGlvbmFsIG1lc3NhZ2Ug dG8gdGhlIHNlcnZlciBpbiBvcmRlciB0byBhbGxvdyB0aGUgc2VydmVyIHRvIGZpbmlzaCB0aGUg ZXhjaGFuZ2UuICBTb21lIHByb3RvY29scyBhbmQgY29tbW9uIFNBU0wgaW1wbGVtZW50YXRpb25z IGRvIG5vdCBzdXBwb3J0IGJvdGggc2VuZGluZyBhIFNBU0wgbWVzc2FnZSBhbmQgZmluYWxpemlu ZyBhIFNBU0wgbmVnb3RpYXRpb24sIHRoZSBhZGRpdGlvbmFsIGNsaWVudCBtZXNzYWdlIGluIHRo ZSBlcnJvciBjYXNlIGRlYWxzIHdpdGggdGhpcyBwcm9ibGVtLiAgVGhpcyBleGNoYW5nZSBpczog PC9wPgoKPG9sPgo8bGk+Q2xpZW50IHNlbmRzIGFuIGludmFsaWQgaW5pdGlhbCBjbGllbnQgcmVz cG9uc2UuPC9saT4KPGxpPlNlcnZlciByZXNwb25kcyB3aXRoIGFuIGVycm9yIG1lc3NhZ2UuIDwv bGk+CjxsaT5DbGllbnQgc2VuZHMgYSBkdW1teSBjbGllbnQgcmVzcG9uc2UuPC9saT4KPGxpPlNl cnZlciBmYWlscyB0aGUgYXV0aGVudGljYXRpb24uPC9saT4KPC9vbD4KCjxwPiA8L3A+CjxoMSBp ZD0icmZjLnNlY3Rpb24uMy4xIj4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMSI+My4xLjwvYT4g SW5pdGlhbCBDbGllbnQgUmVzcG9uc2U8L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uMy4xLnAuMSI+ Q2xpZW50IHJlc3BvbnNlcyBhcmUgYSBHUzIgPGEgaHJlZj0iI1JGQzU4MDEiPltSRkM1ODAxXTwv YT4gaGVhZGVyIGZvbGxvd2VkIGJ5IHplcm8gb3IgbW9yZSBrZXkvdmFsdWUgcGFpcnMsIG9yIG1h eSBiZSBlbXB0eS4gVGhlIGdzMi1oZWFkZXIgaXMgZGVmaW5lZCBoZXJlIGZvciBjb21wYXRpYmls aXR5IHdpdGggR1MyIGlmIGEgR1MyIG1lY2hhbmlzbSBpcyBmb3JtYWxseSBkZWZpbmVkLCBidXQg dGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgb25lLiAgVGhlc2Uga2V5L3ZhbHVlIHBhaXJz IHRha2UgdGhlIHBsYWNlIG9mIHRoZSBjb3JyZXNwb25kaW5nIEhUVFAgaGVhZGVycyBhbmQgdmFs dWVzIHRvIGNvbnZleSB0aGUgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IHRvIGNvbXBsZXRlIGFuIE9B dXRoIHN0eWxlIEhUVFAgYXV0aG9yaXphdGlvbi4gIFVua25vd24ga2V5L3ZhbHVlIHBhaXJzIE1V U1QgYmUgaWdub3JlZCBieSB0aGUgc2VydmVyLiBUaGUgQUJORiA8YSBocmVmPSIjUkZDNTIzNCI+ W1JGQzUyMzRdPC9hPiBzeW50YXggaXM6IDwvcD4KPGRpdiBpZD0iI3JmYy5maWd1cmUuMiI+PC9k aXY+CjxwcmU+CiAgICAgICAgICAgIAogIGt2c2VwICAgICAgICAgID0gJXgwMQogIGtleSAgICAg ICAgICAgID0gMSooQUxQSEEgLyAiLCIpCiAgdmFsdWUgICAgICAgICAgPSAqKFZDSEFSIC8gU1Ag LyBIVEFCIC8gQ1IgLyBMRiApCiAga3ZwYWlyICAgICAgICAgPSBrZXkgIj0iIHZhbHVlIGt2c2Vw Cjs7Z3MyLWhlYWRlciAgICAgPSBTZWUgUkZDIDU4MDEKICBjbGllbnRfcmVzcCAgICA9IChnczIt aGVhZGVyIGt2c2VwIDAqa3ZwYWlyIGt2c2VwKSAvIGt2c2VwCjwvcHJlPgo8cD48L3A+CjxwIGlk PSJyZmMuc2VjdGlvbi4zLjEucC4zIj5UaGUgR1MyIGhlYWRlciBNQVkgaW5jbHVkZSB0aGUgdXNl ciBuYW1lIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVzb3VyY2UgYmVpbmcgYWNjZXNzZWQsIHRoZSAi YXV0aHppZCIuICBJdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBhcHBsaWNhdGlvbiBwcm90b2NvbHMg YXJlIGFsbG93ZWQgdG8gcmVxdWlyZSBhbiBhdXRoemlkLCBhcyBhcmUgc3BlY2lmaWMgc2VydmVy IGltcGxlbWVudGF0aW9ucy4gIDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMS5wLjQiPlRoZSBm b2xsb3dpbmcga2V5cyBhbmQgY29ycmVzcG9uZGluZyB2YWx1ZXMgYXJlIGRlZmluZWQgaW4gdGhl IGNsaWVudCByZXNwb25zZTogPC9wPgo8cD48L3A+Cgo8dWwgY2xhc3M9ImVtcHR5Ij48bGk+Cjxk bD4KPGR0PmF1dGggKFJFUVVJUkVEKTo8L2R0Pgo8ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij5U aGUgcGF5bG9hZCB0aGF0IHdvdWxkIGJlIGluIHRoZSBIVFRQIEF1dGhvcml6YXRpb24gaGVhZGVy IGlmIHRoaXMgT0F1dGggZXhjaGFuZ2Ugd2FzIGJlaW5nIGNhcnJpZWQgb3V0IG92ZXIgSFRUUC48 L2RkPgo8ZHQ+aG9zdDo8L2R0Pgo8ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij5Db250YWlucyB0 aGUgaG9zdCBuYW1lIHRvIHdoaWNoIHRoZSBjbGllbnQgY29ubmVjdGVkLiBJbiBhbiBIVFRQIGNv bnRleHQgdGhpcyBpcyB0aGUgdmFsdWUgb2YgdGhlIEhUVFAgSG9zdCBoZWFkZXIuIDwvZGQ+Cjxk dD5wb3J0OjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPkNvbnRhaW5zIHRoZSBwb3J0 IG51bWJlciByZXByZXNlbnRlZCBhcyBhIGRlY2ltYWwgcG9zaXRpdmUgaW50ZWdlciBzdHJpbmcg d2l0aG91dCBsZWFkaW5nIHplcm9zIHRvIHdoaWNoIHRoZSBjbGllbnQgY29ubmVjdGVkLjwvZGQ+ CjwvZGw+CjxwPiA8L3A+CjwvbGk+PC91bD4KCjxwPiA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4z LjEucC42Ij5Gb3IgT0F1dGggdG9rZW4gdHlwZXMgc3VjaCBhcyBPQXV0aCAxLjBhIHRoYXQgdXNl IGtleWVkIG1lc3NhZ2UgZGlnZXN0cyB0aGUgY2xpZW50IE1VU1Qgc2VuZCBob3N0IGFuZCBwb3J0 IG51bWJlciBrZXkvdmFsdWVzLCBhbmQgdGhlIHNlcnZlciBNVVNUIGZhaWwgYW4gYXV0aG9yaXph dGlvbiByZXF1ZXN0IHJlcXVpcmluZyBrZXllZCBtZXNzYWdlIGRpZ2VzdHMgdGhhdCBhcmUgbm90 IGFjY29tcGFuaWVkIGJ5IGhvc3QgYW5kIHBvcnQgdmFsdWVzLiAgIEluIE9BdXRoIDEuMGEgZm9y IGV4YW1wbGUsIHRoZSBzby1jYWxsZWQgInNpZ25hdHVyZSBiYXNlIHN0cmluZyBjYWxjdWxhdGlv biIgaW5jbHVkZXMgdGhlIHJlY29uc3RydWN0ZWQgSFRUUCBVUkwuICA8L3A+CjxoMSBpZD0icmZj LnNlY3Rpb24uMy4xLjEiPgo8YSBocmVmPSIjcmZjLnNlY3Rpb24uMy4xLjEiPjMuMS4xLjwvYT4g UmVzZXJ2ZWQgS2V5L1ZhbHVlczwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi4zLjEuMS5wLjEiPklu IHRoZXNlIG1lY2hhbmlzbXMgdmFsdWVzIGZvciBwYXRoLCBxdWVyeSBzdHJpbmcgYW5kIHBvc3Qg Ym9keSBhcmUgYXNzaWduZWQgZGVmYXVsdCB2YWx1ZXMuICBPQXV0aCBhdXRob3JpemF0aW9uIHNj aGVtZXMgTUFZIGRlZmluZSB1c2FnZSBvZiB0aGVzZSBpbiB0aGUgU0FTTCBjb250ZXh0IGFuZCBl eHRlbmQgdGhpcyBzcGVjaWZpY2F0aW9uLiAgRm9yIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlcyB0 aGF0IHVzZSByZXF1ZXN0IGtleWVkIG1lc3NhZ2UgZGlnZXN0IHRoZSBkZWZhdWx0IHZhbHVlcyBN VVNUIGJlIHVzZWQgdW5sZXNzIGV4cGxpY2l0IHZhbHVlcyBhcmUgcHJvdmlkZWQgaW4gdGhlIGNs aWVudCByZXNwb25zZS4gIFRoZSBmb2xsb3dpbmcga2V5IHZhbHVlcyBhcmUgcmVzZXJ2ZWQgZm9y IGZ1dHVyZSB1c2U6IDwvcD4KCjx1bCBjbGFzcz0iZW1wdHkiPjxsaT4KPGRsPgo8ZHQ+bXRoZCAo UkVTRVJWRUQpOjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPkhUVFAgbWV0aG9kLCB0 aGUgZGVmYXVsdCB2YWx1ZSBpcyAiUE9TVCIuICA8L2RkPgo8ZHQ+cGF0aCAoUkVTRVJWRUQpOjwv ZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPkhUVFAgcGF0aCBkYXRhLCB0aGUgZGVmYXVs dCB2YWx1ZSBpcyAiLyIuICA8L2RkPgo8ZHQ+cG9zdCAoUkVTRVJWRUQpOjwvZHQ+CjxkZCBzdHls ZT0ibWFyZ2luLWxlZnQ6IDgiPkhUVFAgcG9zdCBkYXRhLCB0aGUgZGVmYXVsdCB2YWx1ZSBpcyAi Ii4gIDwvZGQ+CjxkdD5xcyAoUkVTRVJWRUQpOjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6 IDgiPlRoZSBIVFRQIHF1ZXJ5IHN0cmluZywgdGhlIGRlZmF1bHQgdmFsdWUgaXMgIiIuICA8L2Rk Pgo8L2RsPgo8cD4gPC9wPgo8L2xpPjwvdWw+Cgo8cD4gPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9u LjMuMiI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjIiPjMuMi48L2E+IFNlcnZlcidzIFJlc3Bv bnNlPC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMi5wLjEiPlRoZSBzZXJ2ZXIgdmFsaWRhdGVz IHRoZSByZXNwb25zZSBhY2NvcmRpbmcgdGhlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBPQXV0aCBB Y2Nlc3MgVG9rZW4gVHlwZXMgdXNlZC4gIElmIHRoZSBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZSB1 dGlsaXplcyBhIGtleWVkIG1lc3NhZ2UgZGlnZXN0IG9mIHRoZSByZXF1ZXN0IHBhcmFtZXRlcnMg dGhlbiB0aGUgY2xpZW50IG11c3QgcHJvdmlkZSBhIGNsaWVudCByZXNwb25zZSB0aGF0IHNhdGlz ZmllcyB0aGUgZGF0YSByZXF1aXJlbWVudHMgZm9yIHRoZSBzY2hlbWUgaW4gdXNlLiAgPC9wPgo8 cCBpZD0icmZjLnNlY3Rpb24uMy4yLnAuMiI+VGhlIHNlcnZlciByZXNwb25kcyB0byBhIHN1Y2Nl c3NmdWxseSB2ZXJpZmllZCBjbGllbnQgbWVzc2FnZSBieSBjb21wbGV0aW5nIHRoZSBTQVNMIG5l Z290aWF0aW9uLiBUaGUgYXV0aGVudGljYXRlZCBpZGVudGl0eSByZXBvcnRlZCBieSB0aGUgU0FT TCBtZWNoYW5pc20gaXMgdGhlIGlkZW50aXR5IHNlY3VyZWx5IGVzdGFibGlzaGVkIGZvciB0aGUg Y2xpZW50IHdpdGggdGhlIE9BdXRoIGNyZWRlbnRpYWwuICBUaGUgYXBwbGljYXRpb24sIG5vdCB0 aGUgU0FTTCBtZWNoYW5pc20sIGJhc2VkIG9uIGxvY2FsIGFjY2VzcyBwb2xpY3kgZGV0ZXJtaW5l cyB3aGV0aGVyIHRoZSBpZGVudGl0eSByZXBvcnRlZCBieSB0aGUgbWVjaGFuaXNtIGlzIGFsbG93 ZWQgYWNjZXNzIHRvIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UuICBOb3RlIHRoYXQgdGhlIHNlbWFu dGljcyBvZiB0aGUgYXV0aHotaWQgaXMgc3BlY2lmaWVkIGJ5IHRoZSBTQVNMIGZyYW1ld29yayA8 YSBocmVmPSIjUkZDNDQyMiI+W1JGQzQ0MjJdPC9hPi48L3A+CjxoMSBpZD0icmZjLnNlY3Rpb24u My4yLjEiPgo8YSBocmVmPSIjcmZjLnNlY3Rpb24uMy4yLjEiPjMuMi4xLjwvYT4gT0F1dGggSWRl bnRpZmllcnMgaW4gdGhlIFNBU0wgQ29udGV4dDwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi4zLjIu MS5wLjEiPkluIHRoZSBPQXV0aCBmcmFtZXdvcmsgdGhlIGNsaWVudCBtYXkgYmUgYXV0aGVudGlj YXRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZSByZXNvdXJjZSBvd25lciBp cyBhdXRoZW50aWNhdGVkIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gT0F1dGggYWNjZXNz IHRva2VucyBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXV0aGVudGljYXRpb24g b2YgdGhlIHJlc291cmNlIG93bmVyIGFuZCBhYm91dCB0aGUgY2xpZW50IGFuZCBtYXkgdGhlcmVm b3JlIG1ha2UgdGhpcyBpbmZvcm1hdGlvbiBhY2Nlc3NpYmxlIHRvIHRoZSByZXNvdXJjZSBzZXJ2 ZXIuPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uMy4yLjEucC4yIj5JZiBib3RoIGlkZW50aWZpZXJz IGFyZSBuZWVkZWQgYnkgYW4gYXBwbGljYXRpb24gdGhlIGRldmVsb3BlciB3aWxsIG5lZWQgdG8g cHJvdmlkZSBhIHdheSB0byBjb21tdW5pY2F0ZSB0aGF0IGZyb20gdGhlIFNBU0wgbWVjaGFuaXNt IGJhY2sgdG8gdGhlIGFwcGxpY2F0aW9uLiAgPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjMuMi4y Ij4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMi4yIj4zLjIuMi48L2E+IFNlcnZlciBSZXNwb25z ZSB0byBGYWlsZWQgQXV0aGVudGljYXRpb248L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uMy4yLjIu cC4xIj5Gb3IgYSBmYWlsZWQgYXV0aGVudGljYXRpb24gdGhlIHNlcnZlciByZXR1cm5zIGEgSlNP TiA8YSBocmVmPSIjUkZDNDYyNyI+W1JGQzQ2MjddPC9hPiBmb3JtYXR0ZWQgZXJyb3IgcmVzdWx0 LCBhbmQgZmFpbHMgdGhlIGF1dGhlbnRpY2F0aW9uLiAgVGhlIGVycm9yIHJlc3VsdCBjb25zaXN0 cyBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczogPC9wPgoKPHVsIGNsYXNzPSJlbXB0eSI+PGxpPgo8 ZGw+CjxkdD5zdGF0dXMgKFJFUVVJUkVEKTo8L2R0Pgo8ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4 Ij5UaGUgYXV0aG9yaXphdGlvbiBlcnJvciBjb2RlLiBWYWxpZCBlcnJvciBjb2RlcyBhcmUgZGVm aW5lZCBpbiB0aGUgSUFOQSAiT0F1dGggRXh0ZW5zaW9ucyBFcnJvciBSZWdpc3RyeSIgc3BlY2lm aWVkIGluIHRoZSBPQXV0aCAyIGNvcmUgc3BlY2lmaWNhdGlvbi4gIDwvZGQ+CjxkdD5zY29wZSAo T1BUSU9OQUwpOjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPkFuIE9BdXRoIHNjb3Bl IHdoaWNoIGlzIHZhbGlkIHRvIGFjY2VzcyB0aGUgc2VydmljZS4gIFRoaXMgbWF5IGJlIGVtcHR5 IHdoaWNoIGltcGxpZXMgdGhhdCB1bnNjb3BlZCB0b2tlbnMgYXJlIHJlcXVpcmVkLCBvciBhIHNj b3BlIHZhbHVlLiAgSWYgYSBzY29wZSBpcyBzcGVjaWZpZWQgdGhlbiBhIHNpbmdsZSBzY29wZSBp cyBwcmVmZXJyZWQsIHVzZSBvZiBhIHNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIHNjb3BlcyBpcyBO T1QgUkVDT01NRU5ERUQuICA8L2RkPgo8ZHQ+b2F1dGgtY29uZmlndXJhdGlvbiAoT1BUSU9OQUwp OjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPlRoZSBVUkwgZm9yIGZvciBhIGRvY3Vt ZW50IGZvbGxvd2luZyB0aGUgT3BlbklEIFByb3ZpZGVyIENvbmZpZ3VyYXRpb24gSW5mb3JtYXRp b24gc2NoZW1hIGFzIGRlc2NyaWJlZCBpbiBPcGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnkgPGEgaHJl Zj0iI09wZW5JRC5EaXNjb3ZlcnkiPltPcGVuSUQuRGlzY292ZXJ5XTwvYT4gc2VjdGlvbiAzIHRo YXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSB1c2VyLiAgVGhpcyBkb2N1bWVudCBNVVNUIGhhdmUg YWxsIE9BdXRoIHJlbGF0ZWQgZGF0YSBlbGVtZW50cyBwb3B1bGF0ZWQuICBUaGUgc2VydmVyIE1B WSByZXR1cm4gZGlmZmVyZW50IFVSTHMgZm9yIHVzZXJzIGluIGRpZmZlcmVudCBkb21haW5zIGFu ZCB0aGUgY2xpZW50IFNIT1VMRCBOT1QgY2FjaGUgYSBzaW5nbGUgcmV0dXJuZWQgdmFsdWUgYW5k IGFzc3VtZSBpdCBhcHBsaWVzIGZvciBhbGwgdXNlcnMvZG9tYWlucyB0aGF0IHRoZSBzZXJ2ZXIg c3Vwb3J0cy4gIFRoZSByZXR1cm5lZCBkaXNjb3ZlcnkgZG9jdW1lbnQgU0hPVUxEIGhhdmUgYWxs IGRhdGEgZWxlbWVudHMgcmVxdWlyZWQgYnkgdGhlIE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeSBz cGVjaWZpY2F0aW9uIHBvcHVsYXRlZC4gIEluIGFkZGl0aW9uLCB0aGUgZGlzY292ZXJ5IGRvY3Vt ZW50IFNIT1VMRCBjb250YWluIHRoZSAncmVnaXN0cmF0aW9uX2VuZHBvaW50JyBlbGVtZW50IHRv IGxlYXJuIGFib3V0IHRoZSBlbmRwb2ludCB0byBiZSB1c2VkIHdpdGggdGhlIER5bmFtaWMgQ2xp ZW50IFJlZ2lzdHJhdGlvbiBwcm90b2NvbCA8YSBocmVmPSIjSS1ELmlldGYtb2F1dGgtZHluLXJl ZyI+W0ktRC5pZXRmLW9hdXRoLWR5bi1yZWddPC9hPiB0byBvYnRhaW4gdGhlIG1pbmltdW0gbnVt YmVyIG9mIHBhcmFtZXRlcnMgbmVjZXNzYXJ5IGZvciB0aGUgT0F1dGggcHJvdG9jb2wgZXhjaGFu Z2UgdG8gZnVuY3Rpb24uICBBbm90aGVyIGNvbXBhcmFibGUgZGlzY292ZXJ5IG9yIGNsaWVudCBy ZWdpc3RyYXRpb24gbWVjaGFuaXNtIE1BWSBiZSB1c2VkIGlmIGF2YWlsYWJsZS4gIDwvZGQ+Cjxk dD48L2R0Pgo8ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij5UaGUgdXNlIG9mIHRoZSAnb2ZmbGlu ZV9hY2Nlc3MnIHNjb3BlLCBhcyBkZWZpbmVkIGluIDxhIGhyZWY9IiNPcGVuSUQuQ29yZSI+W09w ZW5JRC5Db3JlXTwvYT4gaXMgUkVDT01NRU5ERUQgdG8gZ2l2ZSBjbGllbnRzIHRoZSBjYXBhYmls aXR5IHRvIGV4cGxpY2l0bHkgcmVxdWVzdCBhIHJlZnJlc2ggdG9rZW4uICA8L2RkPgo8L2RsPgo8 cD4gPC9wPgo8L2xpPjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uMy4yLjIucC4y Ij5JZiB0aGUgcmVzb3VyY2Ugc2VydmVyIHByb3ZpZGVzIGEgc2NvcGUgdGhlbiB0aGUgY2xpZW50 IE1VU1QgYWx3YXlzIHJlcXVlc3Qgc2NvcGVkIHRva2VucyBmcm9tIHRoZSB0b2tlbiBlbmRwb2lu dC4gIElmIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcHJvdmlkZXMgbm8gc2NvcGUgdG8gdGhlIGNsaWVu dCB0aGVuIHRoZSBjbGllbnQgU0hPVUxEIHByZXN1bWUgYW4gZW1wdHkgc2NvcGUgKHVuc2NvcGVk IHRva2VuKSBpcyByZXF1aXJlZCB0byBhY2Nlc3MgdGhlIHJlc291cmNlLiAgPC9wPgo8cCBpZD0i cmZjLnNlY3Rpb24uMy4yLjIucC4zIj5TaW5jZSBjbGllbnRzIG1heSBpbnRlcmFjdCB3aXRoIGEg bnVtYmVyIG9mIGFwcGxpY2F0aW9uIHNlcnZlcnMsIHN1Y2ggYXMgZW1haWwgc2VydmVycyBhbmQg WE1QUCBzZXJ2ZXJzLCB0aGV5IG5lZWQgdG8gaGF2ZSBhIHdheSB0byBkZXRlcm1pbmUgd2hldGhl ciBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gaGFzIGJlZW4gcGVyZm9ybWVkIGFscmVhZHkg YW5kIHdoZXRoZXIgYW4gYWxyZWFkeSBhdmFpbGFibGUgcmVmcmVzaCB0b2tlbiBjYW4gYmUgcmUt dXNlZCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuIGZvciB0aGUgZGVzaXJlZCByZXNvdXJjZSBz ZXJ2ZXIuICBUaGlzIHNwZWNpZmljYXRpb24gUkVDT01NRU5EcyB0aGF0IGEgY2xpZW50IHVzZXMg dGhlIGluZm9ybWF0aW9uIGluIHRoZSAnaXNzdWUnIGVsZW1lbnQgdG8gbWFrZSB0aGlzIGRldGVy bWluYXRpb24uICA8L3A+CjxoMSBpZD0icmZjLnNlY3Rpb24uMy4yLjMiPgo8YSBocmVmPSIjcmZj LnNlY3Rpb24uMy4yLjMiPjMuMi4zLjwvYT4gQ29tcGxldGluZyBhbiBFcnJvciBNZXNzYWdlIFNl cXVlbmNlPC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMi4zLnAuMSI+U2VjdGlvbiAzLjYgb2Yg PGEgaHJlZj0iI1JGQzQ0MjIiPltSRkM0NDIyXTwvYT4gZXhwbGljaXRseSBwcm9oaWJpdHMgYWRk aXRpb25hbCBpbmZvcm1hdGlvbiBpbiBhbiB1bnN1Y2Nlc3NmdWwgYXV0aGVudGljYXRpb24gb3V0 Y29tZS4gIFRoZXJlZm9yZSwgdGhlIGVycm9yIG1lc3NhZ2UgaXMgc2VudCBpbiBhIG5vcm1hbCBt ZXNzYWdlLiAgVGhlIGNsaWVudCBNVVNUIHRoZW4gc2VuZCBhbiBhZGRpdGlvbmFsIGNsaWVudCBy ZXNwb25zZSBjb25zaXN0aW5nIG9mIGEgc2luZ2xlICV4MDEgKGNvbnRyb2wgQSkgY2hhcmFjdGVy IHRvIHRoZSBzZXJ2ZXIgaW4gb3JkZXIgdG8gYWxsb3cgdGhlIHNlcnZlciB0byBmaW5pc2ggdGhl IGV4Y2hhbmdlLiAgPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjMuMyI+CjxhIGhyZWY9IiNyZmMu c2VjdGlvbi4zLjMiPjMuMy48L2E+IDxhIGhyZWY9IiNrZXllZC1kaWdlc3RzIiBpZD0ia2V5ZWQt ZGlnZXN0cyI+T0F1dGggQWNjZXNzIFRva2VuIFR5cGVzIHVzaW5nIEtleWVkIE1lc3NhZ2UgRGln ZXN0czwvYT4KPC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMy5wLjEiPk9BdXRoIEFjY2VzcyBU b2tlbiBUeXBlcyBtYXkgdXNlIGtleWVkIG1lc3NhZ2UgZGlnZXN0cyBhbmQgdGhlIGNsaWVudCBh bmQgdGhlIHJlc291cmNlIHNlcnZlciBtYXkgbmVlZCB0byBwZXJmb3JtIGEgY3J5cHRvZ3JhcGhp YyBjb21wdXRhdGlvbiBmb3IgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIGRhdGEgb3JpZ2luIGF1 dGhlbnRpY2F0aW9uLjwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMy5wLjIiPk9BdXRoIGlzIGRl c2lnbmVkIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzIGlkZW50aWZpZWQgYnkgVVJJcy4gIFNBU0wg aXMgZGVzaWduZWQgZm9yIHVzZXIgYXV0aGVudGljYXRpb24sIGFuZCBoYXMgbm8gZmFjaWxpdHkg Zm9yIG1vcmUgZmluZS1ncmFpbmVkIGFjY2VzcyBjb250cm9sLiAgSW4gdGhpcyBzcGVjaWZpY2F0 aW9uIHdlIHJlcXVpcmUgb3IgZGVmaW5lIGRlZmF1bHQgdmFsdWVzIGZvciB0aGUgZGF0YSBlbGVt ZW50cyBmcm9tIGFuIEhUVFAgcmVxdWVzdCB3aGljaCBhbGxvdyB0aGUgc2lnbmF0dXJlIGJhc2Ug c3RyaW5nIHRvIGJlIGNvbnN0cnVjdGVkIHByb3Blcmx5LiAgVGhlIGRlZmF1bHQgSFRUUCBwYXRo IGlzICIvIiBhbmQgdGhlIGRlZmF1bHQgcG9zdCBib2R5IGlzIGVtcHR5LiAgVGhlc2UgYXRvbXMg YXJlIGRlZmluZWQgYXMgZXh0ZW5zaW9uIHBvaW50cyBzbyB0aGF0IG5vIGNoYW5nZXMgYXJlIG5l ZWRlZCBpZiB0aGVyZSBpcyBhIHJldmlzaW9uIG9mIFNBU0wgd2hpY2ggc3VwcG9ydHMgbW9yZSBz cGVjaWZpYyByZXNvdXJjZSBhdXRob3JpemF0aW9uLCBlLmcuLCBJTUFQIGFjY2VzcyB0byBhIHNw ZWNpZmljIGZvbGRlciBvciBGVFAgYWNjZXNzIGxpbWl0ZWQgdG8gYSBzcGVjaWZpYyBkaXJlY3Rv cnkuIDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMy5wLjMiPlVzaW5nIHRoZSBleGFtcGxlIGlu IHRoZSBPQXV0aCAxLjBhIHNwZWNpZmljYXRpb24gYXMgYSBzdGFydGluZyBwb2ludCwgb24gYW4g SU1BUCBzZXJ2ZXIgcnVubmluZyBvbiBwb3J0IDE0MyBhbmQgZ2l2ZW4gdGhlIE9BdXRoIDEuMGEg c3R5bGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0ICh3aXRoICV4MDEgc2hvd24gYXMgXkEgYW5kIGxp bmUgYnJlYWtzIGFkZGVkIGZvciByZWFkYWJpbGl0eSkgYmVsb3c6IDwvcD4KPGRpdiBpZD0iI3Jm Yy5maWd1cmUuMyI+PC9kaXY+CjxwcmU+Cm4sYT11c2VyQGV4YW1wbGUuY29tLF5BCmhvc3Q9ZXhh bXBsZS5jb21eQQpwb3J0PTE0M15BCmF1dGg9T0F1dGggcmVhbG09IkV4YW1wbGUiLAogICAgICAg ICAgIG9hdXRoX2NvbnN1bWVyX2tleT0iOWRqZGo4Mmg0OGRqczlkMiIsCiAgICAgICAgICAgb2F1 dGhfdG9rZW49ImtrazlkN2RoM2szOXNqdjciLAogICAgICAgICAgIG9hdXRoX3NpZ25hdHVyZV9t ZXRob2Q9IkhNQUMtU0hBMSIsCiAgICAgICAgICAgb2F1dGhfdGltZXN0YW1wPSIxMzcxMzEyMDEi LAogICAgICAgICAgIG9hdXRoX25vbmNlPSI3ZDhmM2U0YSIsCiAgICAgICAgICAgb2F1dGhfc2ln bmF0dXJlPSJUbTkwSUdFZ2NtVmhiQ0J6YVdkdVlYUjFjbVUiXkFeQQo8L3ByZT4KPHA+PC9wPgo8 cCBpZD0icmZjLnNlY3Rpb24uMy4zLnAuNSI+VGhlIHNpZ25hdHVyZSBiYXNlIHN0cmluZyB3b3Vs ZCBiZSBjb25zdHJ1Y3RlZCBwZXIgdGhlIE9BdXRoIDEuMCBzcGVjaWZpY2F0aW9uIDxhIGhyZWY9 IiNSRkM1ODQ5Ij5bUkZDNTg0OV08L2E+IHdpdGggdGhlIGZvbGxvd2luZyB0aGluZ3Mgbm90ZWQ6 IDwvcD4KCjx1bD4KPGxpPlRoZSBtZXRob2QgdmFsdWUgaXMgZGVmYXVsdGVkIHRvIFBPU1QuPC9s aT4KPGxpPlRoZSBzY2hlbWUgZGVmYXVsdHMgdG8gYmUgImh0dHAiLCBhbmQgYW55IHBvcnQgbnVt YmVyIG90aGVyIHRoYW4gODAgaXMgaW5jbHVkZWQuPC9saT4KPGxpPlRoZSBwYXRoIGRlZmF1bHRz IHRvICIvIi48L2xpPgo8bGk+VGhlIHF1ZXJ5IHN0cmluZyBkZWZhdWx0cyB0byAiIi48L2xpPgo8 L3VsPgoKPHA+IEluIHRoaXMgZXhhbXBsZSB0aGUgc2lnbmF0dXJlIGJhc2Ugc3RyaW5nIHdpdGgg bGluZSBicmVha3MgYWRkZWQgZm9yIHJlYWRhYmlsaXR5IHdvdWxkIGJlOiA8L3A+CjxkaXYgaWQ9 IiNyZmMuZmlndXJlLjQiPjwvZGl2Pgo8cHJlPgpQT1NUJmFtcDtodHRwJTNBJTJGJTJGZXhhbXBs ZS5jb206MTQzJTJGJmFtcDtvYXV0aF9jb25zdW1lcl9rZXklM0Q5ZGpkajgyaDQKOGRqczlkMiUy Nm9hdXRoX25vbmNlJTNEN2Q4ZjNlNGElMjZvYXV0aF9zaWduYXR1cmVfbWV0aG9kJTNESE1BQy1T SApBMSUyNm9hdXRoX3RpbWVzdGFtcCUzRDEzNzEzMTIwMSUyNm9hdXRoX3Rva2VuJTNEa2trOWQ3 ZGgzazM5c2p2Nwo8L3ByZT4KPHA+PC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjQiPgo8YSBocmVm PSIjcmZjLnNlY3Rpb24uNCI+NC48L2E+IEV4YW1wbGVzPC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9u LjQucC4xIj5UaGVzZSBleGFtcGxlcyBpbGx1c3RyYXRlIGV4Y2hhbmdlcyBiZXR3ZWVuIElNQVAg YW5kIFNNVFAgY2xpZW50cyBhbmQgc2VydmVycy48L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi40LnAu MiI+Tm90ZSB0byBpbXBsZW1lbnRlcnM6ICBUaGUgU0FTTCBPQXV0aCBtZXRob2QgbmFtZXMgYXJl IGNhc2UgaW5zZW5zaXRpdmUuICBPbmUgZXhhbXBsZSB1c2VzICJCZWFyZXIiIGJ1dCB0aGF0IGNv dWxkIGFzIGVhc2lseSBiZSAiYmVhcmVyIiwgIkJFQVJFUiIsIG9yICJCZUFyRXIiLiAgPC9wPgo8 aDEgaWQ9InJmYy5zZWN0aW9uLjQuMSI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi40LjEiPjQuMS48 L2E+IFN1Y2Nlc3NmdWwgQmVhcmVyIFRva2VuIEV4Y2hhbmdlPC9oMT4KPHAgaWQ9InJmYy5zZWN0 aW9uLjQuMS5wLjEiPlRoaXMgZXhhbXBsZSBzaG93cyBhIHN1Y2Nlc3NmdWwgT0F1dGggMi4wIGJl YXJlciB0b2tlbiBleGNoYW5nZSBpbiBJTUFQLiBOb3RlIHRoYXQgbGluZSBicmVha3MgYXJlIGlu c2VydGVkIGZvciByZWFkYWJpbGl0eSBhbmQgdGhlIHVuZGVybHlpbmcgVExTIGVzdGFibGlzaG1l bnQgaXMgbm90IHNob3duIGVpdGhlci48L3A+CjxkaXYgaWQ9IiNyZmMuZmlndXJlLjUiPjwvZGl2 Pgo8cHJlPgpTOiAqIE9LIElNQVA0cmV2MSBTZXJ2ZXIgUmVhZHkKQzogdDAgQ0FQQUJJTElUWQpT OiAqIENBUEFCSUxJVFkgSU1BUDRyZXYxIEFVVEg9T0FVVEhCRUFSRVIgU0FTTC1JUgpTOiB0MCBP SyBDb21wbGV0ZWQKQzogdDEgQVVUSEVOVElDQVRFIE9BVVRIQkVBUkVSIGJpeGhQWFZ6WlhKQVpY aGhiWEJzWlM1amIyMHNBV2h2YzNROWMyCiAgICAgIFZ5ZG1WeUxtVjRZVzF3YkdVdVkyOXRBWEJ2 Y25ROU1UUXpBV0YxZEdnOVFtVmhjbVZ5SUhaR09XUm1kRFJ4YgogICAgICBWUmpNazUyWWpOU2JH TnJRbWhpU0ZKb1pHMXNlbVJIUlhWWk1qbDBRMmM5UFFFQgpTOiB0MSBPSyBTQVNMIGF1dGhlbnRp Y2F0aW9uIHN1Y2NlZWRlZAo8L3ByZT4KPHA+PC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uNC4xLnAu MyI+QXMgcmVxdWlyZWQgYnkgSU1BUCA8YSBocmVmPSIjUkZDMzUwMSI+W1JGQzM1MDFdPC9hPiwg dGhlIHBheWxvYWRzIGFyZSBiYXNlNjQtZW5jb2RlZC4gVGhlIGRlY29kZWQgaW5pdGlhbCBjbGll bnQgcmVzcG9uc2UgKHdpdGggJXgwMSByZXByZXNlbnRlZCBhcyBeQSBhbmQgbG9uZyBsaW5lcyB3 cmFwcGVkIGZvciByZWFkYWJpbGl0eSkgaXM6IDwvcD4KPGRpdiBpZD0iI3JmYy5maWd1cmUuNiI+ PC9kaXY+CjxwcmU+Cm4sYT11c2VyQGV4YW1wbGUuY29tLF5BaG9zdD1zZXJ2ZXIuZXhhbXBsZS5j b21eQXBvcnQ9MTQzXkEKYXV0aD1CZWFyZXIgdkY5ZGZ0NHFtVGMyTnZiM1JsY2tCaGJIUmhkbWx6 ZEdFdVkyOXRDZz09XkFeQQo8L3ByZT4KPHA+PC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uNC4xLnAu NSI+VGhlIHNhbWUgY3JlZGVudGlhbCB1c2VkIGluIGFuIFNNVFAgZXhjaGFuZ2UgaXMgc2hvd24g YmVsb3cuICBOb3RlIHRoYXQgbGluZSBicmVha3MgYXJlIGluc2VydGVkIGZvciByZWFkYWJpbGl0 eSwgYW5kIHRoYXQgdGhlIFNNVFAgcHJvdG9jb2wgdGVybWluYXRlcyBsaW5lcyB3aXRoIENSIGFu ZCBMRiBjaGFyYWN0ZXJzIChBU0NJSSB2YWx1ZXMgMHgwRCBhbmQgMHgwQSksIHRoZXNlIGFyZSBu b3QgZGlzcGxheWVkIGV4cGxpY2l0bHkgaW4gdGhlIGV4YW1wbGUuPC9wPgo8ZGl2IGlkPSIjcmZj LmZpZ3VyZS43Ij48L2Rpdj4KPHByZT4KW2Nvbm5lY3Rpb24gYmVnaW5zXQpTOiAyMjAgbXguZXhh bXBsZS5jb20gRVNNVFAgMTJzbTIwOTU2MDNma3MuOQpDOiBFSExPIHNlbmRlci5leGFtcGxlLmNv bQpTOiAyNTAtbXguZXhhbXBsZS5jb20gYXQgeW91ciBzZXJ2aWNlLFsxNzIuMzEuMTM1LjQ3XQpT OiAyNTAtU0laRSAzNTY1MTU4NApTOiAyNTAtOEJJVE1JTUUKUzogMjUwLUFVVEggTE9HSU4gUExB SU4gT0FVVEhCRUFSRVIKUzogMjUwLUVOSEFOQ0VEU1RBVFVTQ09ERVMKUzogMjUwIFBJUEVMSU5J TkcKQzogdDEgQVVUSEVOVElDQVRFIE9BVVRIQkVBUkVSIGJpeGhQWFZ6WlhKQVpYaGhiWEJzWlM1 amIyMHNBV2h2YzNROWMKICAgICAgMlZ5ZG1WeUxtVjRZVzF3YkdVdVkyOXRBWEJ2Y25ROU1UUXpB V0YxZEdnOVFtVmhjbVZ5SUhaR09XUm1kRFIKICAgICAgeGJWUmpNazUyWWpOU2JHTnJRbWhpU0ZK b1pHMXNlbVJIUlhWWk1qbDBRMmM5UFFFQgpTOiAyMzUgQXV0aGVudGljYXRpb24gc3VjY2Vzc2Z1 bC4KW2Nvbm5lY3Rpb24gY29udGludWVzLi4uXQogICAgICAgICAgICA8L3ByZT4KPHA+PC9wPgo8 aDEgaWQ9InJmYy5zZWN0aW9uLjQuMiI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi40LjIiPjQuMi48 L2E+IFN1Y2Nlc3NmdWwgT0F1dGggMS4wYSBUb2tlbiBFeGNoYW5nZTwvaDE+CjxwIGlkPSJyZmMu c2VjdGlvbi40LjIucC4xIj5UaGlzIElNQVAgZXhhbXBsZSBzaG93cyBhIHN1Y2Nlc3NmdWwgT0F1 dGggMS4wYSB0b2tlbiBleGNoYW5nZS4gTm90ZSB0aGF0IGxpbmUgYnJlYWtzIGFyZSBpbnNlcnRl ZCBmb3IgcmVhZGFiaWxpdHkgYW5kIHRoZSB1bmRlcmx5aW5nIFRMUyBlc3RhYmxpc2htZW50IGlz IG5vdCBzaG93bi4gU2lnbmF0dXJlIGNvbXB1dGF0aW9uIGlzIGRpc2N1c3NlZCBpbiA8YSBocmVm PSIja2V5ZWQtZGlnZXN0cyI+U2VjdGlvbiAzLjM8L2E+LjwvcD4KPGRpdiBpZD0iI3JmYy5maWd1 cmUuOCI+PC9kaXY+CjxwcmU+ClM6ICogT0sgSU1BUDRyZXYxIFNlcnZlciBSZWFkeQpDOiB0MCBD QVBBQklMSVRZClM6ICogQ0FQQUJJTElUWSBJTUFQNHJldjEgQVVUSD1PQVVUSEJFQVJFUiBPQVVU SDEwQSBTQVNMLUlSIApTOiB0MCBPSyBDb21wbGV0ZWQgCkM6IHQxIEFVVEhFTlRJQ0FURSBPQVVU SDEwQSBiaXhoUFhWelpYSkFaWGhoYlhCc1pTNWpiMjBzQVdodmMzUTlaWGhoYgogICAgICBYQnNa UzVqYjIwQmNHOXlkRDB4TkRNQllYVjBhRDFQUVhWMGFDQnlaV0ZzYlQwaVJYaGhiWEJzWlNJc2Iy RjEKICAgICAgZEdoZlkyOXVjM1Z0WlhKZmEyVjVQU0k1Wkdwa2FqZ3lhRFE0Wkdwek9XUXlJaXh2 WVhWMGFGOTBiMnRsYmowCiAgICAgIGlhMnRyT1dRM1pHZ3phek01YzJwMk55SXNiMkYxZEdoZmMy bG5ibUYwZFhKbFgyMWxkR2h2WkQwaVNFMUJReQogICAgICAxVFNFRXhJaXh2WVhWMGFGOTBhVzFs YzNSaGJYQTlJakV6TnpFek1USXdNU0lzYjJGMWRHaGZibTl1WTJVOUkKICAgICAgamRrT0dZelpU UmhJaXh2WVhWMGFGOXphV2R1WVhSMWNtVTlJbFJ0T1RCSlIwVm5ZMjFXYUdKRFFucGhWMlIxCiAg ICAgIFdWaFNNV050VlNVelJDSUJBUT09ClM6IHQxIE9LIFNBU0wgYXV0aGVudGljYXRpb24gc3Vj Y2VlZGVkCjwvcHJlPgo8cD48L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi40LjIucC4zIj5BcyByZXF1 aXJlZCBieSBJTUFQIDxhIGhyZWY9IiNSRkMzNTAxIj5bUkZDMzUwMV08L2E+LCB0aGUgcGF5bG9h ZHMgYXJlIGJhc2U2NC1lbmNvZGVkLiBUaGUgZGVjb2RlZCBpbml0aWFsIGNsaWVudCByZXNwb25z ZSAod2l0aCAleDAxIHJlcHJlc2VudGVkIGFzIF5BIGFuZCBsaW5lcyB3cmFwcGVkIGZvciByZWFk YWJpbGl0eSkgaXM6IDwvcD4KPGRpdiBpZD0iI3JmYy5maWd1cmUuOSI+PC9kaXY+CjxwcmU+Cm4s YT11c2VyQGV4YW1wbGUuY29tLF5BCmhvc3Q9ZXhhbXBsZS5jb21eQQpwb3J0PTE0M15BCmF1dGg9 T0F1dGggcmVhbG09IkV4YW1wbGUiLAogICAgICAgICAgIG9hdXRoX2NvbnN1bWVyX2tleT0iOWRq ZGo4Mmg0OGRqczlkMiIsCiAgICAgICAgICAgb2F1dGhfdG9rZW49ImtrazlkN2RoM2szOXNqdjci LAogICAgICAgICAgIG9hdXRoX3NpZ25hdHVyZV9tZXRob2Q9IkhNQUMtU0hBMSIsCiAgICAgICAg ICAgb2F1dGhfdGltZXN0YW1wPSIxMzcxMzEyMDEiLAogICAgICAgICAgIG9hdXRoX25vbmNlPSI3 ZDhmM2U0YSIsCiAgICAgICAgICAgb2F1dGhfc2lnbmF0dXJlPSJTU2R0SUdFZ2JHbDBkR3hsSUhS bFlTQndiM1F1Il5BXkEKPC9wcmU+CjxwPjwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi40LjMiPgo8 YSBocmVmPSIjcmZjLnNlY3Rpb24uNC4zIj40LjMuPC9hPiBGYWlsZWQgRXhjaGFuZ2U8L2gxPgo8 cCBpZD0icmZjLnNlY3Rpb24uNC4zLnAuMSI+VGhpcyBJTUFQIGV4YW1wbGUgc2hvd3MgYSBmYWls ZWQgZXhjaGFuZ2UgYmVjYXVzZSBvZiB0aGUgZW1wdHkgQXV0aG9yaXphdGlvbiBoZWFkZXIsIHdo aWNoIGlzIGhvdyBhIGNsaWVudCBjYW4gcXVlcnkgZm9yIHRoZSBuZWVkZWQgc2NvcGUuIE5vdGUg dGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5zZXJ0ZWQgZm9yIHJlYWRhYmlsaXR5LjwvcD4KPGRpdiBp ZD0iI3JmYy5maWd1cmUuMTAiPjwvZGl2Pgo8cHJlPgpTOiAqIE9LIElNQVA0cmV2MSBTZXJ2ZXIg UmVhZHkKQzogdDAgQ0FQQUJJTElUWQpTOiAqIENBUEFCSUxJVFkgSU1BUDRyZXYxIEFVVEg9T0FV VEhCRUFSRVIgU0FTTC1JUiBJTUFQNHJldjEgU2VydmVyIAogICAgIFJlYWR5IApTOiB0MCBPSyBD b21wbGV0ZWQgCkM6IHQxIEFVVEhFTlRJQ0FURSBPQVVUSEJFQVJFUiBiaXhoUFhWelpYSkFaWGho YlhCc1pTNWpiMjBzQVcKICAgICAgaHZjM1E5YzJWeWRtVnlMbVY0WVcxd2JHVXVZMjl0QVhCdmNu UTlNVFF6QVdGMWRHZzlBUUU9ClM6ICsgZXlKemRHRjBkWE1pT2lKcGJuWmhiR2xrWDNSdmEyVnVJ aXdpYzJOdmNHVWlPaUpsZUdGdGNHeGwKICAgICBYM05qYjNCbElpd2liM0JsYm1sa0xXTnZibVpw WjNWeVlYUnBiMjRpT2lKb2RIUndjem92TDJWNAogICAgIFlXMXdiR1V1WTI5dEx5NTNaV3hzTFd0 dWIzZHVMMjl3Wlc1cFpDMWpiMjVtYVdkMWNtRjBhVzl1CiAgICAgSW4wPQpDOiArIEFRPT0KUzog dDEgTk8gU0FTTCBhdXRoZW50aWNhdGlvbiBmYWlsZWQKPC9wcmU+CjxwPjwvcD4KPHAgaWQ9InJm Yy5zZWN0aW9uLjQuMy5wLjMiPlRoZSBkZWNvZGVkIGluaXRpYWwgY2xpZW50IHJlc3BvbnNlIGlz OiA8L3A+CjxkaXYgaWQ9IiNyZmMuZmlndXJlLjExIj48L2Rpdj4KPHByZT4KbixhPXVzZXJAZXhh bXBsZS5jb20sXkFob3N0PXNlcnZlci5leGFtcGxlLmNvbV5BCnBvcnQ9MTQzXkFhdXRoPV5BXkEK ICAgICAgICAgICAgPC9wcmU+CjxwPjwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjQuMy5wLjUiPlRo ZSBkZWNvZGVkIHNlcnZlciBlcnJvciByZXNwb25zZSBpczogPC9wPgo8ZGl2IGlkPSIjcmZjLmZp Z3VyZS4xMiI+PC9kaXY+CjxwcmU+CnsKInN0YXR1cyI6ImludmFsaWRfdG9rZW4iLAoic2NvcGUi OiJleGFtcGxlX3Njb3BlIiwKIm9wZW5pZC1jb25maWd1cmF0aW9uIjoiaHR0cHM6Ly9leGFtcGxl LmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiIKfQogICAgICAgICAgICA8L3By ZT4KPHA+PC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uNC4zLnAuNyI+VGhlIGNsaWVudCByZXNwb25k cyB3aXRoIHRoZSByZXF1aXJlZCBkdW1teSByZXNwb25zZSwgIkFRPT0iIGlzIHRoZSBiYXNlNjQg ZW5jb2Rpbmcgb2YgdGhlIEFTQ0lJIHZhbHVlIDB4MDEuICA8L3A+CjxoMSBpZD0icmZjLnNlY3Rp b24uNC40Ij4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjQuNCI+NC40LjwvYT4gU01UUCBFeGFtcGxl IG9mIGEgRmFpbGVkIE5lZ290aWF0aW9uPC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9uLjQuNC5wLjEi PlRoaXMgZXhhbXBsZSBzaG93cyBhbiBhdXRob3JpemF0aW9uIGZhaWx1cmUgaW4gYW4gU01UUCBl eGNoYW5nZS4gIE5vdGUgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5zZXJ0ZWQgZm9yIHJlYWRhYmls aXR5LCBhbmQgdGhhdCB0aGUgU01UUCBwcm90b2NvbCB0ZXJtaW5hdGVzIGxpbmVzIHdpdGggQ1Ig YW5kIExGIGNoYXJhY3RlcnMgKEFTQ0lJIHZhbHVlcyAweDBEIGFuZCAweDBBKSwgdGhlc2UgYXJl IG5vdCBkaXNwbGF5ZWQgZXhwbGljaXRseSBpbiB0aGUgZXhhbXBsZS48L3A+CjxkaXYgaWQ9IiNy ZmMuZmlndXJlLjEzIj48L2Rpdj4KPHByZT4KW2Nvbm5lY3Rpb24gYmVnaW5zXQpTOiAyMjAgbXgu ZXhhbXBsZS5jb20gRVNNVFAgMTJzbTIwOTU2MDNma3MuOQpDOiBFSExPIHNlbmRlci5leGFtcGxl LmNvbQpTOiAyNTAtbXguZXhhbXBsZS5jb20gYXQgeW91ciBzZXJ2aWNlLFsxNzIuMzEuMTM1LjQ3 XQpTOiAyNTAtU0laRSAzNTY1MTU4NApTOiAyNTAtOEJJVE1JTUUKUzogMjUwLUFVVEggTE9HSU4g UExBSU4gT0FVVEhCRUFSRVIKUzogMjUwLUVOSEFOQ0VEU1RBVFVTQ09ERVMKUzogMjUwIFBJUEVM SU5JTkcKQzogQVVUSCBPQVVUSEJFQVJFUiBiaXgxYzJWeVBYTnZiV1YxYzJWeVFHVjRZVzF3YkdV dVkyOXRMQUZoZFhSb1BVSmxZWEpsCiAgICAgICBjaUIyUmpsa1puUTBjVzFVWXpKT2RtSXpVbXhq YTBKb1pFaFNhR1J0Ykhwa1IwVjFXVEk1ZEVOblBUMEJBUT09ClM6IDMzNCBleUp6ZEdGMGRYTWlP aUkwTURFaUxDSnpZMmhsYldWeklqb2lZbVZoY21WeUlHMWhZeUlzSW5OamIzQmxJam9pYQogICAg ICAgSFIwY0hNNkx5OXRZV2xzTG1kdmIyZHNaUzVqYjIwdkluMEsKQzogQVE9PQpTOiA1MzUtNS43 LjEgVXNlcm5hbWUgYW5kIFBhc3N3b3JkIG5vdCBhY2NlcHRlZC4gTGVhcm4gbW9yZSBhdApTOiA1 MzUgNS43LjEgaHR0cDovL3N1cHBvcnQuZXhhbXBsZS5jb20vbWFpbC9vYXV0aApbY29ubmVjdGlv biBjb250aW51ZXMuLi5dCiAgICAgICAgICAgIDwvcHJlPgo8cD48L3A+CjxwIGlkPSJyZmMuc2Vj dGlvbi40LjQucC4zIj5UaGUgc2VydmVyIHJldHVybmVkIGFuIGVycm9yIG1lc3NhZ2UgaW4gdGhl IDMzNCBTQVNMIG1lc3NhZ2UsIHRoZSBjbGllbnQgcmVzcG9uZHMgd2l0aCB0aGUgcmVxdWlyZWQg ZHVtbXkgcmVzcG9uc2UsIGFuZCB0aGUgc2VydmVyIGZpbmFsaXplcyB0aGUgbmVnb3RpYXRpb24u ICA8L3A+CjxoMSBpZD0icmZjLnNlY3Rpb24uNSI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi41Ij41 LjwvYT4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uNS5w LjEiPk9BdXRoIDEuMGEgYW5kIE9BdXRoIDIgYWxsb3dzIGZvciBhIHZhcmlldHkgb2YgZGVwbG95 bWVudCBzY2VuYXJpb3MsIGFuZCB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiB0aGVzZSBwcm9m aWxlcyB2YXJ5LiBBcyBzaG93biBpbiA8YSBocmVmPSIjb3ZlcnZpZXciPkZpZ3VyZSAxPC9hPiB0 aGlzIHNwZWNpZmljYXRpb24gaXMgYWltZWQgdG8gYmUgaW50ZWdyYXRlZCBpbnRvIGEgbGFyZ2Vy IE9BdXRoIGRlcGxveW1lbnQuIEFwcGxpY2F0aW9uIGRldmVsb3BlcnMgdGhlcmVmb3JlIG5lZWQg dG8gdW5kZXJzdGFuZCB0aGUgbmVlZHMgb2YgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGJh c2VkIG9uIGEgdGhyZWF0IGFzc2Vzc21lbnQgYmVmb3JlIHNlbGVjdGluZyBhIHNwZWNpZmljIFNB U0wgT0F1dGggbWVjaGFuaXNtLiBGb3IgT0F1dGggMi4wIGEgZGV0YWlsZWQgc2VjdXJpdHkgZG9j dW1lbnQgPGEgaHJlZj0iI1JGQzY4MTkiPltSRkM2ODE5XTwvYT4gcHJvdmlkZXMgZ3VpZGFuY2Ug dG8gc2VsZWN0IHRob3NlIE9BdXRoIDIuMCBjb21wb25lbnRzIHRoYXQgaGVscCB0byBtaXRpZ2F0 ZSB0aHJlYXRzIGZvciBhIGdpdmVuIGRlcGxveW1lbnQuIEZvciBPQXV0aCAxLjBhIFNlY3Rpb24g NCBvZiBSRkMgNTg0OSA8YSBocmVmPSIjUkZDNTg0OSI+W1JGQzU4NDldPC9hPiBwcm92aWRlcyBn dWlkYW5jZSBzcGVjaWZpYyB0byBPQXV0aCAxLjAuPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uNS5w LjIiPlRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHR3byBTQVNMICBNZWNoYW5pc21zIGZvciBPQXV0 aCBhbmQgZWFjaCBjb21lcyB3aXRoIGRpZmZlcmVudCBzZWN1cml0eSBwcm9wZXJ0aWVzLiAgPC9w PgoKPGRsPgo8ZHQ+T0FVVEhCRUFSRVI6PC9kdD4KPGRkIHN0eWxlPSJtYXJnaW4tbGVmdDogOCI+ VGhpcyBtZWNoYW5pc20gYm9ycm93cyBmcm9tIE9BdXRoIDIuMCBiZWFyZXIgdG9rZW5zIDxhIGhy ZWY9IiNSRkM2NzUwIj5bUkZDNjc1MF08L2E+LiBJdCByZWxpZXMgb24gdGhlIGFwcGxpY2F0aW9u IHVzaW5nIFRMUyB0byBwcm90ZWN0IHRoZSBPQXV0aCAyLjAgQmVhcmVyIFRva2VuIGV4Y2hhbmdl OyB3aXRob3V0IFRMUyB1c2FnZSBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgdGhpcyBtZXRob2Qg aXMgY29tcGxldGVseSBpbnNlY3VyZS4gQ29uc2VxdWVudGx5LCBUTFMgTVVTVCBiZSBwcm92aWRl ZCBieSB0aGUgYXBwbGljYXRpb24gd2hlbiBjaG9vc2luZyB0aGlzIGF1dGhlbnRpY2F0aW9uIG1l Y2hhbmlzbS48L2RkPgo8ZHQ+T0FVVEgxMEE6PC9kdD4KPGRkIHN0eWxlPSJtYXJnaW4tbGVmdDog OCI+VGhpcyBtZWNoYW5pc20gcmUtdXNlcyBPQXV0aCAxLjBhIE1BQyB0b2tlbnMgKHVzaW5nIHRo ZSBITUFDLVNIQTEga2V5ZWQgbWVzc2FnZSBkaWdlc3QpLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjQuMiBvZiA8YSBocmVmPSIjUkZDNTg0OSI+W1JGQzU4NDldPC9hPi4gVG8gY29tcHV0ZSB0 aGUga2V5ZWQgbWVzc2FnZSBkaWdlc3QgaW4gdGhlIHNhbWUgd2F5IHdhcyBpbiBSRkMgNTgzOSB0 aGlzIHNwZWNpZmljYXRpb24gY29udmV5cyBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgYmV0d2VlbiB0 aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyLiBUaGlzIFNBU0wgbWVjaGFuaXNtIG9ubHkgc3VwcG9y dHMgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBJZiBzZXJ2ZXItc2lkZSBhdXRoZW50aWNhdGlvbiBp cyBkZXNpcmVhYmxlIHRoZW4gaXQgbXVzdCBiZSBwcm92aWRlZCBieSB0aGUgYXBwbGljYXRpb24g dW5kZXJuZWF0aCB0aGUgU0FTTCBsYXllci4gVGhlIHVzZSBvZiBUTFMgaXMgc3Ryb25nbHkgUkVD T01NRU5ERUQuICA8L2RkPgo8L2RsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjUucC4z Ij5BZGRpdGlvbmFsbHksIHRoZSBmb2xsb3dpbmcgYXNwZWN0cyBhcmUgd29ydGggcG9pbnRpbmcg b3V0OiA8L3A+Cgo8ZGw+CjxkdD5BbiBhY2Nlc3MgdG9rZW4gaXMgbm90IGVxdWl2YWxlbnQgdG8g dGhlIHVzZXIncyBsb25nIHRlcm0gcGFzc3dvcmQuPC9kdD4KPGRkIHN0eWxlPSJtYXJnaW4tbGVm dDogOCI+Cjxicj48YnI+IENhcmUgaGFzIHRvIGJlIHRha2VuIHdoZW4gdGhlc2UgT0F1dGggY3Jl ZGVudGlhbHMgYXJlIHVzZWQgZm9yIGFjdGlvbnMgbGlrZSBjaGFuZ2luZyBwYXNzd29yZHMgKGFz IGl0IGlzIHBvc3NpYmxlIHdpdGggc29tZSBwcm90b2NvbHMsIGUuZy4sIFhNUFAgPGEgaHJlZj0i I1JGQzYxMjAiPltSRkM2MTIwXTwvYT4pLiBUaGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCBlbnN1 cmUgdGhhdCBhY3Rpb25zIHRha2VuIGluIHRoZSBhdXRoZW50aWNhdGVkIGNoYW5uZWwgYXJlIGFw cHJvcHJpYXRlIHRvIHRoZSBzdHJlbmd0aCBvZiB0aGUgcHJlc2VudGVkIGNyZWRlbnRpYWwuPC9k ZD4KPGR0PkxpZmV0aW1lIG9mIHRoZSBhcHBsaWF0aW9uIHNlc3Npb25zLjwvZHQ+CjxkZCBzdHls ZT0ibWFyZ2luLWxlZnQ6IDgiPgo8YnI+PGJyPiBJdCBpcyBwb3NzaWJsZSB0aGF0IFNBU0wgd2ls bCBiZSBhdXRoZW50aWNhdGluZyBhIGNvbm5lY3Rpb24gYW5kIHRoZSBsaWZlIG9mIHRoYXQgY29u bmVjdGlvbiBtYXkgb3V0bGFzdCB0aGUgbGlmZSBvZiB0aGUgYWNjZXNzIHRva2VuIHVzZWQgdG8g ZXN0YWJsaXNoIGl0LiAgVGhpcyBpcyBhIGNvbW1vbiBwcm9ibGVtIGluIGFwcGxpY2F0aW9uIHBy b3RvY29scyB3aGVyZSBjb25uZWN0aW9ucyBhcmUgbG9uZy1saXZlZCwgYW5kIG5vdCBhIHByb2Js ZW0gd2l0aCB0aGlzIG1lY2hhbmlzbSBwZXIgc2UuIFJlc291cmNlIHNlcnZlcnMgbWF5IHVuaWxh dGVyYWxseSBkaXNjb25uZWN0IGNsaWVudHMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBhcHBsaWNh dGlvbiBwcm90b2NvbC48L2RkPgo8ZHQ+QWNjZXNzIHRva2VucyBoYXZlIGEgbGlmZXRpbWUuPC9k dD4KPGRkIHN0eWxlPSJtYXJnaW4tbGVmdDogOCI+Cjxicj48YnI+IFJlZHVjaW5nIHRoZSBsaWZl dGltZSBvZiBhbiBhY2Nlc3MgdG9rZW4gcHJvdmlkZXMgc2VjdXJpdHkgYmVuZWZpdHMgYW5kIE9B dXRoIDIuMCBpbnRyb2R1Y2VzIHJlZnJlc2ggdG9rZW5zIHRvIG9idGFpbiBuZXcgYWNjZXNzIHRv a2VuIG9uIHRoZSBmbHkgd2l0aG91dCBhbnkgbmVlZCBmb3IgYSBodW1hbiBpbnRlcmFjdGlvbi4g IEFkZGl0aW9uYWxseSwgYSBwcmV2aW91c2x5IG9idGFpbmVkIGFjY2VzcyB0b2tlbiBtaWdodCBi ZSByZXZva2VkIG9yIHJlbmRlcmVkIGludmFsaWQgYXQgYW55IHRpbWUuIFRoZSBjbGllbnQgTUFZ IHJlcXVlc3QgYSBuZXcgYWNjZXNzIHRva2VuIGZvciBlYWNoIGNvbm5lY3Rpb24gdG8gYSByZXNv dXJjZSBzZXJ2ZXIsIGJ1dCBpdCBTSE9VTEQgY2FjaGUgYW5kIHJlLXVzZSB2YWxpZCBjcmVkZW50 aWFscy48L2RkPgo8L2RsPgoKPHA+IDwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi42Ij4KPGEgaHJl Zj0iI3JmYy5zZWN0aW9uLjYiPjYuPC9hPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb25zaWRlcmF0 aW9uczwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi42LnAuMSI+VGhlIGlkZW50aWZlciBhc3NlcnRl ZCBieSB0aGUgT0F1dGggYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYWJvdXQgdGhlIHJlc291cmNlIG93 bmVyIGluc2lkZSB0aGUgYWNjZXNzIHRva2VuIG1heSBiZSBkaXNwbGF5ZWQgdG8gYSBodW1hbi4g Rm9yIGV4YW1wbGUsIHdoZW4gU0FTTCBpcyB1c2VkIGluIHRoZSBjb250ZXh0IG9mIElNQVAgdGhl IGNsaWVudCBtYXkgYXNzZXJ0IHRoZSByZXNvdXJjZSBvd25lcidzIGVtYWlsIGFkZHJlc3MgdG8g dGhlIElNQVAgc2VydmVyIGZvciB1c2FnZSBpbiBhbiBlbWFpbC1iYXNlZCBhcHBsaWNhdGlvbi4g VGhlIGlkZW50aWZpZXIgbWF5IHRoZXJlZm9yZSBjb250YWluIGludGVybmF0aW9uYWxpemVkIGNo YXJhY3RlcnMgYW5kIGFuIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGVuc3VyZSB0aGF0IHRoZSBtYXBw aW5nIGJldHdlZW4gdGhlIGlkZW50aWZpZXIgcHJvdmlkZWQgYnkgT0F1dGggaXMgc3VpdGFibGUg Zm9yIHVzZSB3aXRoIHRoZSBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBTQVNMIGlzIGluY29y cG9yYXRlZCBpbnRvLjwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjYucC4yIj5BdCB0aGUgdGltZSBv ZiB3cml0aW5nIHRoZSBzdGFuZGFyZGl6YXRpb24gb2YgdGhlIHZhcmlvdXMgY2xhaW1zIGluIHRo ZSBhY2Nlc3MgdG9rZW4gKGluIEpTT04gZm9ybWF0KSBpcyBzdGlsbCBvbmdvaW5nLCBzZWUgPGEg aHJlZj0iI0ktRC5pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuIj5bSS1ELmlldGYtb2F1dGgtanNv bi13ZWItdG9rZW5dPC9hPi4gT25jZSBjb21wbGV0ZWQgaXQgd2lsbCBwcm92aWRlIGEgc3RhbmRh cmRpemVkIGZvcm1hdCBmb3IgZXhjaGFuZ2luZyBpZGVudGl0eSBpbmZvcm1hdGlvbiBiZXR3ZWVu IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGhlIHJlc291cmNlIHNlcnZlci48L3A+Cjxo MSBpZD0icmZjLnNlY3Rpb24uNyI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi43Ij43LjwvYT4gSUFO QSBDb25zaWRlcmF0aW9uczwvaDE+CjxoMSBpZD0icmZjLnNlY3Rpb24uNy4xIj4KPGEgaHJlZj0i I3JmYy5zZWN0aW9uLjcuMSI+Ny4xLjwvYT4gU0FTTCBSZWdpc3RyYXRpb248L2gxPgo8cCBpZD0i cmZjLnNlY3Rpb24uNy4xLnAuMSI+VGhlIElBTkEgaXMgcmVxdWVzdGVkIHRvIHJlZ2lzdGVyIHRo ZSBmb2xsb3dpbmcgU0FTTCBwcm9maWxlOiA8L3A+Cgo8dWwgY2xhc3M9ImVtcHR5Ij4KPGxpPlNB U0wgbWVjaGFuaXNtIHByb2ZpbGU6IE9BVVRIQkVBUkVSPC9saT4KPGxpPlNlY3VyaXR5IENvbnNp ZGVyYXRpb25zOiBTZWUgdGhpcyBkb2N1bWVudDwvbGk+CjxsaT5QdWJsaXNoZWQgU3BlY2lmaWNh dGlvbjogU2VlIHRoaXMgZG9jdW1lbnQ8L2xpPgo8bGk+Rm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246 IENvbnRhY3QgdGhlIGF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudC48L2xpPgo8bGk+T3duZXIvQ2hh bmdlIGNvbnRyb2xsZXI6IHRoZSBJRVRGPC9saT4KPGxpPk5vdGU6IE5vbmU8L2xpPgo8L3VsPgoK PHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjcuMS5wLjIiPlRoZSBJQU5BIGlzIHJlcXVlc3Rl ZCB0byByZWdpc3RlciB0aGUgZm9sbG93aW5nIFNBU0wgcHJvZmlsZTogPC9wPgoKPHVsIGNsYXNz PSJlbXB0eSI+CjxsaT5TQVNMIG1lY2hhbmlzbSBwcm9maWxlOiBPQVVUSDEwQTwvbGk+CjxsaT5T ZWN1cml0eSBDb25zaWRlcmF0aW9uczogU2VlIHRoaXMgZG9jdW1lbnQ8L2xpPgo8bGk+UHVibGlz aGVkIFNwZWNpZmljYXRpb246IFNlZSB0aGlzIGRvY3VtZW50PC9saT4KPGxpPkZvciBmdXJ0aGVy IGluZm9ybWF0aW9uOiBDb250YWN0IHRoZSBhdXRob3JzIG9mIHRoaXMgZG9jdW1lbnQuPC9saT4K PGxpPk93bmVyL0NoYW5nZSBjb250cm9sbGVyOiB0aGUgSUVURjwvbGk+CjxsaT5Ob3RlOiBOb25l PC9saT4KPC91bD4KCjxwPiA8L3A+CjxoMSBpZD0icmZjLnJlZmVyZW5jZXMiPgo8YSBocmVmPSIj cmZjLnJlZmVyZW5jZXMiPjguPC9hPiBSZWZlcmVuY2VzPC9oMT4KPGgxIGlkPSJyZmMucmVmZXJl bmNlcy4xIj4KPGEgaHJlZj0iI3JmYy5yZWZlcmVuY2VzLjEiPjguMS48L2E+IE5vcm1hdGl2ZSBS ZWZlcmVuY2VzPC9oMT4KPHRhYmxlPjx0Ym9keT4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+ PGIgaWQ9IlJGQzIxMTkiPltSRkMyMTE5XTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhIGhy ZWY9Im1haWx0bzpzb2JAaGFydmFyZC5lZHUiIHRpdGxlPSJIYXJ2YXJkIFVuaXZlcnNpdHkiPkJy YWRuZXIsIFMuPC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIx MTkiPktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2 ZWxzPC9hPiIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuPC90ZD4KPC90cj4KPHRyPgo8 dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzMxNzQiPltSRkMzMTc0XTwvYj48L3RkPgo8 dGQgY2xhc3M9InRvcCI+CjxhPkVhc3RsYWtlLCBELjwvYT4gYW5kIDxhPlAuIEpvbmVzPC9hPiwg IjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNzQiPlVTIFNlY3VyZSBI YXNoIEFsZ29yaXRobSAxIChTSEExKTwvYT4iLCBSRkMgMzE3NCwgU2VwdGVtYmVyIDIwMDEuPC90 ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzQ0MjIiPltSRkM0 NDIyXTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPk1lbG5pa292LCBBLjwvYT4gYW5kIDxh PksuIFplaWxlbmdhPC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzQ0MjIiPlNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNBU0wpPC9h PiIsIFJGQyA0NDIyLCBKdW5lIDIwMDYuPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVy ZW5jZSI+PGIgaWQ9IlJGQzQ2MjciPltSRkM0NjI3XTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+ CjxhPkNyb2NrZm9yZCwgRC48L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNDYyNyI+VGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEgVHlwZSBmb3IgSmF2YVNjcmlw dCBPYmplY3QgTm90YXRpb24gKEpTT04pPC9hPiIsIFJGQyA0NjI3LCBKdWx5IDIwMDYuPC90ZD4K PC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzUyNDYiPltSRkM1MjQ2 XTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPkRpZXJrcywgVC48L2E+IGFuZCA8YT5FLiBS ZXNjb3JsYTwvYT4sICI8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2 Ij5UaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFByb3RvY29sIFZlcnNpb24gMS4y PC9hPiIsIFJGQyA1MjQ2LCBBdWd1c3QgMjAwOC48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBjbGFzcz0i cmVmZXJlbmNlIj48YiBpZD0iUkZDNTIzNCI+W1JGQzUyMzRdPC9iPjwvdGQ+Cjx0ZCBjbGFzcz0i dG9wIj4KPGE+Q3JvY2tlciwgRC48L2E+IGFuZCA8YT5QLiBPdmVyZWxsPC9hPiwgIjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMzQiPkF1Z21lbnRlZCBCTkYgZm9yIFN5 bnRheCBTcGVjaWZpY2F0aW9uczogQUJORjwvYT4iLCBTVEQgNjgsIFJGQyA1MjM0LCBKYW51YXJ5 IDIwMDguPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzU4 NDkiPltSRkM1ODQ5XTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPkhhbW1lci1MYWhhdiwg RS48L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg0OSI+VGhl IE9BdXRoIDEuMCBQcm90b2NvbDwvYT4iLCBSRkMgNTg0OSwgQXByaWwgMjAxMC48L3RkPgo8L3Ry Pgo8dHI+Cjx0ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iUkZDNTgwMSI+W1JGQzU4MDFdPC9i PjwvdGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+Sm9zZWZzc29uLCBTLjwvYT4gYW5kIDxhPk4uIFdp bGxpYW1zPC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4MDEi PlVzaW5nIEdlbmVyaWMgU2VjdXJpdHkgU2VydmljZSBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVy ZmFjZSAoR1NTLUFQSSkgTWVjaGFuaXNtcyBpbiBTaW1wbGUgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyaXR5IExheWVyIChTQVNMKTogVGhlIEdTMiBNZWNoYW5pc20gRmFtaWx5PC9hPiIsIFJGQyA1 ODAxLCBKdWx5IDIwMTAuPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIg aWQ9IlJGQzQ2NDgiPltSRkM0NjQ4XTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPkpvc2Vm c3NvbiwgUy48L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDY0 OCI+VGhlIEJhc2UxNiwgQmFzZTMyLCBhbmQgQmFzZTY0IERhdGEgRW5jb2RpbmdzPC9hPiIsIFJG QyA0NjQ4LCBPY3RvYmVyIDIwMDYuPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5j ZSI+PGIgaWQ9IlJGQzY3NDkiPltSRkM2NzQ5XTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+Cjxh PkhhcmR0LCBELjwvYT4sICI8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 NzQ5Ij5UaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrPC9hPiIsIFJGQyA2NzQ5 LCBPY3RvYmVyIDIwMTIuPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIg aWQ9IlJGQzY3NTAiPltSRkM2NzUwXTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPkpvbmVz LCBNLjwvYT4gYW5kIDxhPkQuIEhhcmR0PC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzY3NTAiPlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcms6 IEJlYXJlciBUb2tlbiBVc2FnZTwvYT4iLCBSRkMgNjc1MCwgT2N0b2JlciAyMDEyLjwvdGQ+Cjwv dHI+Cjx0cj4KPHRkIGNsYXNzPSJyZWZlcmVuY2UiPjxiIGlkPSJPcGVuSUQuRGlzY292ZXJ5Ij5b T3BlbklELkRpc2NvdmVyeV08L2I+PC90ZD4KPHRkIGNsYXNzPSJ0b3AiPgo8YSB0aXRsZT0iTm9t dXJhIFJlc2VhcmNoIEluc3RpdHV0ZSwgTHRkLiI+U2FraW11cmEsIE4uPC9hPiwgPGEgdGl0bGU9 IlByb3Rpdml0aSBHb3Zlcm5tZW50IFNlcnZpY2VzIj5CcmFkbGV5LCBKLjwvYT4sIDxhIHRpdGxl PSJNaWNyb3NvZnQiPkpvbmVzLCBNLkIuPC9hPiBhbmQgPGEgdGl0bGU9Ik1HSTEiPkUuIEpheTwv YT4sICI8YT5PcGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnkgMS4wPC9hPiIsIEp1bHkgMjAxMS48L3Rk Pgo8L3RyPgo8dHI+Cjx0ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iT3BlbklELkNvcmUiPltP cGVuSUQuQ29yZV08L2I+PC90ZD4KPHRkIGNsYXNzPSJ0b3AiPgo8YSB0aXRsZT0iTm9tdXJhIFJl c2VhcmNoIEluc3RpdHV0ZSwgTHRkLiI+U2FraW11cmEsIE4uPC9hPiwgPGEgdGl0bGU9IlBpbmcg SWRlbnRpdHkiPkJyYWRsZXksIEouPC9hPiwgPGEgdGl0bGU9Ik1pY3Jvc29mdCI+Sm9uZXMsIE0u Qi48L2E+LCA8YSB0aXRsZT0iR29vZ2xlIj5kZSBNZWRlaXJvcywgQi48L2E+IGFuZCA8YSB0aXRs ZT0iU2FsZXNmb3JjZSI+Qy4gTW9ydGltb3JlPC9hPiwgIjxhPk9wZW5JRCBDb25uZWN0IENvcmUg MS4wPC9hPiIsIEZlYnJ1YXJ5IDIwMTQuPC90ZD4KPC90cj4KPC90Ym9keT48L3RhYmxlPgo8aDEg aWQ9InJmYy5yZWZlcmVuY2VzLjIiPgo8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMuMiI+OC4yLjwv YT4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvaDE+Cjx0YWJsZT48dGJvZHk+Cjx0cj4KPHRkIGNs YXNzPSJyZWZlcmVuY2UiPjxiIGlkPSJSRkMyNjE2Ij5bUkZDMjYxNl08L2I+PC90ZD4KPHRkIGNs YXNzPSJ0b3AiPgo8YSBocmVmPSJtYWlsdG86ZmllbGRpbmdAaWNzLnVjaS5lZHUiIHRpdGxlPSJE ZXBhcnRtZW50IG9mIEluZm9ybWF0aW9uIGFuZCBDb21wdXRlciBTY2llbmNlIj5GaWVsZGluZywg Ui48L2E+LCA8YSBocmVmPSJtYWlsdG86amdAdzMub3JnIiB0aXRsZT0iV29ybGQgV2lkZSBXZWIg Q29uc29ydGl1bSI+R2V0dHlzLCBKLjwvYT4sIDxhIGhyZWY9Im1haWx0bzptb2d1bEB3cmwuZGVj LmNvbSIgdGl0bGU9IkNvbXBhcSBDb21wdXRlciBDb3Jwb3JhdGlvbiI+TW9ndWwsIEouPC9hPiwg PGEgaHJlZj0ibWFpbHRvOmZyeXN0eWtAdzMub3JnIiB0aXRsZT0iV29ybGQgV2lkZSBXZWIgQ29u c29ydGl1bSI+RnJ5c3R5aywgSC48L2E+LCA8YSBocmVmPSJtYWlsdG86bWFzaW50ZXJAcGFyYy54 ZXJveC5jb20iIHRpdGxlPSJYZXJveCBDb3Jwb3JhdGlvbiI+TWFzaW50ZXIsIEwuPC9hPiwgPGEg aHJlZj0ibWFpbHRvOnBhdWxsZUBtaWNyb3NvZnQuY29tIiB0aXRsZT0iTWljcm9zb2Z0IENvcnBv cmF0aW9uIj5MZWFjaCwgUC48L2E+IGFuZCA8YSBocmVmPSJtYWlsdG86dGltYmxAdzMub3JnIiB0 aXRsZT0iV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSI+VC4gQmVybmVycy1MZWU8L2E+LCAiPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNiI+SHlwZXJ0ZXh0IFRyYW5z ZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xPC9hPiIsIFJGQyAyNjE2LCBKdW5lIDE5OTkuPC90ZD4K PC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzUzMjEiPltSRkM1MzIx XTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPktsZW5zaW4sIEouPC9hPiwgIjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzMjEiPlNpbXBsZSBNYWlsIFRyYW5zZmVy IFByb3RvY29sPC9hPiIsIFJGQyA1MzIxLCBPY3RvYmVyIDIwMDguPC90ZD4KPC90cj4KPHRyPgo8 dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzM1MDEiPltSRkMzNTAxXTwvYj48L3RkPgo8 dGQgY2xhc3M9InRvcCI+CjxhPkNyaXNwaW4sIE0uPC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzM1MDEiPklOVEVSTkVUIE1FU1NBR0UgQUNDRVNTIFBST1RPQ09M IC0gVkVSU0lPTiA0cmV2MTwvYT4iLCBSRkMgMzUwMSwgTWFyY2ggMjAwMy48L3RkPgo8L3RyPgo8 dHI+Cjx0ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iUkZDNjEyMCI+W1JGQzYxMjBdPC9iPjwv dGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+U2FpbnQtQW5kcmUsIFAuPC9hPiwgIjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxMjAiPkV4dGVuc2libGUgTWVzc2FnaW5nIGFu ZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCk6IENvcmU8L2E+IiwgUkZDIDYxMjAsIE1hcmNoIDIw MTEuPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzcwMzMi PltSRkM3MDMzXTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPkpvbmVzLCBQLjwvYT4sIDxh PlNhbGd1ZWlybywgRy48L2E+LCA8YT5Kb25lcywgTS48L2E+IGFuZCA8YT5KLiBTbWFycjwvYT4s ICI8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDMzIj5XZWJGaW5nZXI8 L2E+IiwgUkZDIDcwMzMsIFNlcHRlbWJlciAyMDEzLjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNz PSJyZWZlcmVuY2UiPjxiIGlkPSJJLUQuaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbiI+W0ktRC5p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuXTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPkpv bmVzLCBNPC9hPiwgPGE+QnJhZGxleSwgSjwvYT4gYW5kIDxhPk4gU2FraW11cmE8L2E+LCAiPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdl Yi10b2tlbi0yNSI+SlNPTiBXZWIgVG9rZW4gKEpXVCk8L2E+IiwgSW50ZXJuZXQtRHJhZnQgZHJh ZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNSwgSnVseSAyMDE0LjwvdGQ+CjwvdHI+Cjx0 cj4KPHRkIGNsYXNzPSJyZWZlcmVuY2UiPjxiIGlkPSJJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1h YyI+W0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFjXTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+ CjxhPlJpY2hlciwgSjwvYT4sIDxhPk1pbGxzLCBXPC9hPiwgPGE+VHNjaG9mZW5pZywgSDwvYT4g YW5kIDxhPlAgSHVudDwvYT4sICI8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLXYyLWh0dHAtbWFjLTA1Ij5PQXV0aCAyLjAgTWVzc2FnZSBBdXRoZW50 aWNhdGlvbiBDb2RlIChNQUMpIFRva2VuczwvYT4iLCBJbnRlcm5ldC1EcmFmdCBkcmFmdC1pZXRm LW9hdXRoLXYyLWh0dHAtbWFjLTA1LCBKYW51YXJ5IDIwMTQuPC90ZD4KPC90cj4KPHRyPgo8dGQg Y2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IkktRC5pZXRmLW9hdXRoLWR5bi1yZWciPltJLUQuaWV0 Zi1vYXV0aC1keW4tcmVnXTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPlJpY2hlciwgSjwv YT4sIDxhPkpvbmVzLCBNPC9hPiwgPGE+QnJhZGxleSwgSjwvYT4sIDxhPk1hY2h1bGFrLCBNPC9h PiBhbmQgPGE+UCBIdW50PC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0yMCI+T0F1dGggMi4wIER5bmFtaWMgQ2xpZW50IFJl Z2lzdHJhdGlvbiBQcm90b2NvbDwvYT4iLCBJbnRlcm5ldC1EcmFmdCBkcmFmdC1pZXRmLW9hdXRo LWR5bi1yZWctMjAsIEF1Z3VzdCAyMDE0LjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNzPSJyZWZl cmVuY2UiPjxiIGlkPSJSRkM2ODE5Ij5bUkZDNjgxOV08L2I+PC90ZD4KPHRkIGNsYXNzPSJ0b3Ai Pgo8YT5Mb2RkZXJzdGVkdCwgVC48L2E+LCA8YT5NY0dsb2luLCBNLjwvYT4gYW5kIDxhPlAuIEh1 bnQ8L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjgxOSI+T0F1 dGggMi4wIFRocmVhdCBNb2RlbCBhbmQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L2E+IiwgUkZD IDY4MTksIEphbnVhcnkgMjAxMy48L3RkPgo8L3RyPgo8L3Rib2R5PjwvdGFibGU+CjxoMSBpZD0i cmZjLmFwcGVuZGl4LkFwcGVuZGl4IEEiPgo8YSBocmVmPSIjcmZjLmFwcGVuZGl4LkFwcGVuZGl4 JTIwQSI+QXBwZW5kaXggQS48L2E+IEFja25vd2xlZ2VtZW50czwvaDE+CjxwIGlkPSJyZmMuc2Vj dGlvbi5BcHBlbmRpeCBBLnAuMSI+VGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUg bWVtYmVycyBvZiB0aGUgS2l0dGVuIHdvcmtpbmcgZ3JvdXAsIGFuZCBpbiBhZGRpdGlvbiBhbmQg c3BlY2lmaWNhbGx5OiBTaW1vbiBKb3NlZnNvbiwgVG9yc3RlbiBMb2RkZXJzdGFkdCwgUnlhbiBU cm9sbCwgQWxleGV5IE1lbG5pa292LCBKZWZmcmV5IEh1dHplbG1hbiwgTmljbyBXaWxsaWFtcywg TWF0dCBNaWxsZXIsIGFuZCBCZW5qYW1pbiBLYWR1ay4gIDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9u LkFwcGVuZGl4IEEucC4yIj5UaGlzIGRvY3VtZW50IHdhcyBwcm9kdWNlZCB1bmRlciB0aGUgY2hh aXJtYW5zaGlwIG9mIEFsZXhleSBNZWxuaWtvdiwgVG9tIFl1LCBTaGF3biBFbWVyeSwgSm9zaCBI b3dsZXR0LCBTYW0gSGFydG1hbi4gIFRoZSBzdXBlcnZpc2luZyBhcmVhIGRpcmVjdG9yIHdhcyBT dGVwaGVuIEZhcnJlbGwuICA8L3A+CjxoMSBpZD0icmZjLmFwcGVuZGl4LkFwcGVuZGl4IEIiPgo8 YSBocmVmPSIjcmZjLmFwcGVuZGl4LkFwcGVuZGl4JTIwQiI+QXBwZW5kaXggQi48L2E+IERvY3Vt ZW50IEhpc3Rvcnk8L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5wLjEiPltbIHRv IGJlIHJlbW92ZWQgYnkgUkZDIGVkaXRvciBiZWZvcmUgcHVibGljYXRpb24gYXMgYW4gUkZDIF1d IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIucC4yIj4tMTcgPC9wPgo8cD48L3A+ Cgo8dWw+PGxpPkxhc3QgY2FsbCBmZWVkYmFjayBhZ2Fpbi4gIGVyYWRpY2F0ZWQgY29tbWEgc3Bs aWNpbmcuICBSZW1vdmVkIGV4dHJhIHNlcnZlciBtZXNzYWdlIGluIGV4YW1wbGUgNC4zLiAgPC9s aT48L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIucC40Ij4tMTYg PC9wPgo8cD48L3A+Cgo8dWw+PGxpPkxhc3QgY2FsbCBmZWVkYmFjayBhZ2Fpbi4gIFByaW1hcmls eSBlZGl0b3JpYWwgY2hhbmdlcy4gIENvcnJlY3RlZCBleGFtcGxlcy4gIDwvbGk+PC91bD4KCjxw PiA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuNiI+LTE1IDwvcD4KPHA+PC9w PgoKPHVsPgo8bGk+TGFzdCBjYWxsIGZlZWRhY2sgb24gdGhlIEdTMiBzdHVmZiBiZWluZyByaXBw ZWQgb3V0IGNvbXBsZXRlbHkuICA8L2xpPgo8bGk+UmVtb3ZlZCB0aGUgInVzZXIiIHBhcmFtZXRl ciBhbmQgcHV0IHN0dWZmIGJhY2sgaW50byB0aGUgZ3MyLWhlYWRlci4gIENhbGwgb3V0IHRoYXQg dGhlIGF1dGh6aWQgZ29lcyBpbiB0aGUgZ3MyLWhlYWRlciB3aXRoIHNvbWUgcHJvc2UgYWJvdXQg d2hlbiBpdCBtaWdodCBiZSByZXF1aXJlZC4gVmVyeSBjb21wYXJhYmxlIHRvIC0xMC4gIDwvbGk+ CjxsaT5BZGRlZCBhbiBPQXV0aCAxLjBBIGV4YW1wbGUgZXhwbGljaXRseS4gIDwvbGk+CjwvdWw+ Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5wLjgiPi0xNCA8L3A+Cjxw PjwvcD4KCjx1bD4KPGxpPkxhc3QgY2FsbCBmZWVkYWNrIG9uIFJGQyBjaXRhdGlvbnMgbmVlZGVk LCBzbWFsbCBlZGl0b3JpYWwuICA8L2xpPgo8bGk+QWRkZWQgdGhlICJ1c2VyIiBwYXJhbWV0ZXIg YmFjaywgd2hpY2ggd2FzIHB1bGxlZCB3aGVuIHdlIHN0YXJ0ZWQgZG93biB0aGUgR1MyIHBhdGgu ICBTYW1lIGxhbmd1YWdlIGFzIC0wMy4gIDwvbGk+CjxsaT5EZWZpbmVkIGEgc3R1YiBHUzIgaGVh ZGVyIHRvIG1ha2Ugc3VyZSB0aGF0IHdoZW4gdGhlIEdTMiBicmlkZSBpcyBkZWZpbmVkIGZvciB0 aGlzIHRoYXQgbm90aGluZyB3aWxsIGJyZWFrIHdoZW4gaXQgYWN0dWFsbHkgc3RhcnRzIHRvIGdl dCBwb3B1bGF0ZWQuICA8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFw cGVuZGl4IEIucC4xMCI+LTEzIDwvcD4KPHA+PC9wPgoKPHVsPjxsaT5DaGFuZ2VkIGFmZmlsaWF0 aW9uLiAgPC9saT48L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIu cC4xMiI+LTEyIDwvcD4KPHA+PC9wPgoKPHVsPjxsaT5SZW1vdmVkIC1QTFVTIGNvbXBvbmVudHMg ZnJvbSB0aGUgc3BlY2lmaWNhdGlvbi4gIDwvbGk+PC91bD4KCjxwPiA8L3A+CjxwIGlkPSJyZmMu c2VjdGlvbi5BcHBlbmRpeCBCLnAuMTQiPi0xMSA8L3A+CjxwPjwvcD4KCjx1bD4KPGxpPlJlbW92 ZWQgR1NTLUFQSSBjb21wb25lbnRzIGZyb20gdGhlIHNwZWNpZmljYXRpb24uICA8L2xpPgo8bGk+ VXBkYXRlZCBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24uICA8L2xpPgo8L3VsPgoKPHA+ IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIucC4xNiI+LTEwIDwvcD4KPHA+PC9w PgoKPHVsPjxsaT5DbGFyaWZpY2F0aW9ucyB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCBpbiByZXNw b25zZSB0byB0aGUgZmVlZGJhY2sgZnJvbSBKZWZmcmV5IEh1dHplbG1hbi4gIDwvbGk+PC91bD4K CjxwPiA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuMTgiPi0wOSA8L3A+Cjxw PjwvcD4KCjx1bD4KPGxpPkluY29ycG9yYXRlZCByZXZpZXcgYnkgQWxleGV5IGFuZCBIYW5uZXMu ICA8L2xpPgo8bGk+Q2xhcmlmaWVkIHRoZSB0aHJlZSBPQXV0aCBTQVNMIG1lY2hhbmlzbXMuICA8 L2xpPgo8bGk+VXBkYXRlZCByZWZlcmVuY2VzPC9saT4KPGxpPkV4dGVuZGVkIGFja25vd2xlZGdl bWVudHM8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIu cC4yMCI+LTA4IDwvcD4KPHA+PC9wPgoKPHVsPgo8bGk+Rml4ZWQgdGhlIGNoYW5uZWwgYmluZGlu ZyBleGFtcGxlcyBmb3IgcD0kY2J0eXBlIDwvbGk+CjxsaT5Nb3JlIHR1bmluZyBvZiB0aGUgYXV0 aGNpZCBsYW5ndWFnZSBhbmQgZWRpdGVkIGFuZCByZW5hbWVkIDMuMi4xLiAgPC9saT4KPC91bD4K CjxwPiA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuMjIiPi0wNyA8L3A+Cjxw PjwvcD4KCjx1bD4KPGxpPlN0cnVjayB0aGUgTVVTVCBsYW5naWFnZSBmcm9tIGF1dGh6aWQuICA8 L2xpPgo8bGk+CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5w LjI0Ij4tMDYgPC9wPgo8cD48L3A+Cgo8dWw+CjxsaT5SZW1vdmVkIHRoZSB1c2VyIGZpZWxkLiAg Rml4ZWQgdGhlIGV4YW1wbGVzIGFnYWluLiAgPC9saT4KPGxpPkFkZGVkIGNhbm9uaWNhbGl6YXRp b24gbGFuZ3VhZ2UuICA8L2xpPgo8bGk+CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rp b24uQXBwZW5kaXggQi5wLjI2Ij4tMDUgPC9wPgo8cD48L3A+Cgo8dWw+CjxsaT5GaXhlZCB0aGUg R1MyIGhlYWRlciBsYW5ndWFnZSBhZ2Fpbi4gIDwvbGk+CjxsaT5TZXBhcmF0ZWQgb3V0IGRpZmZl cmVudCBPQXV0aCBzY2hlbWVzIGludG8gZGlmZmVyZW50IFNBU0wgbWVjaGFuaXNtcy4gIFRvb2sg b3V0IHRoZSBzY2hlbWUgaW4gdGhlIGVycm9yIHJldHVybi4gIFR1bmVkIHVwIHRoZSBJQU5BIHJl Z2lzdHJhdGlvbnMuICA8L2xpPgo8bGk+QWRkZWQgdGhlIHVzZXIgZmllbGQgYmFjayBpbnRvIHRo ZSBTQVNMIG1lc3NhZ2UuICA8L2xpPgo8bGk+Rml4ZWQgdGhlIGV4YW1wbGVzIChhZ2FpbikuICA8 L2xpPgo8bGk+CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5w LjI4Ij4tMDQgPC9wPgo8cD48L3A+Cgo8dWw+CjxsaT5DaGFuZ2VkIHVzZXIgZmllbGQgdG8gYmUg Y2FycmllZCBpbiB0aGUgZ3MyLWhlYWRlciwgYW5kIG1hZGUgZ3MyIGhlYWRlciBleHBsaWNpdCBp biBhbGwgY2FzZXMuICA8L2xpPgo8bGk+Q29udmVydGVkIE1BQyBleGFtcGxlcyB0byBPQXV0aCAx LjBhLiAgTW92ZWQgTUFDIHRvIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZS4gIDwvbGk+CjxsaT5D aGFuZ2VkIHRvIHNlbmRpbmcgYW4gZW1wdHkgY2xpZW50IHJlc3BvbnNlIChzaW5nbGUgY29udHJv bC1BKSBhcyB0aGUgc2Vjb25kIG1lc3NhZ2Ugb2YgYSBmYWlsZWQgc2VxdWVuY2UuICA8L2xpPgo8 bGk+Rml4ZWQgY2hhbm5lbCBiaW5kaW5nIHByb3NlIHRvIHJlZmVyIHRvIHRoZSBub3JtYXRpdmUg c3BlY3MgYW5kIHJlbW92ZWQgdGhlIGhhc2hpbmcgb2YgbGFyZ2UgY2hhbm5lbCBiaW5kaW5nIGRh dGEsIHdoaWNoIGJyb3VnaHQgbXJvZSBwcm9ibGVtcyB0aGFuIGl0IHNvbHZlZC4gIDwvbGk+Cjxs aT5BZGRlZCBhIFNNVFAgZXhhbXBsZXMgZm9yIEJlYXJlciB1c2UgY2FzZS4gIDwvbGk+CjwvdWw+ Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5wLjMwIj4tMDMgPC9wPgo8 cD48L3A+Cgo8dWw+CjxsaT5BZGRlZCB1c2VyIGZpZWxkIGludG8gZXhhbXBsZXMgYW5kIGZpeGVk IGVncmVnaW91cyBlcnJvcnMgdGhlcmUgYXMgd2VsbC4gIDwvbGk+CjxsaT5BZGRlZCB0ZXh0IHJl bWluZGluZyBkZXZlbG9wZXJzIHRoYXQgQXV0aG9yaXphdGlvbiBzY2hlbWUgbmFtZXMgYXJlIGNh c2UgaW5zZW5zaXRpdmUuICA8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9u LkFwcGVuZGl4IEIucC4zMiI+LTAyIDwvcD4KPHA+PC9wPgoKPHVsPgo8bGk+QWRkZWQgdGhlIHVz ZXIgZGF0YSBlbGVtZW50IGJhY2sgaW4uICA8L2xpPgo8bGk+TWlub3IgZWRpdG9yaWFsIGNoYW5n ZXMuICA8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIu cC4zNCI+LTAxIDwvcD4KPHA+PC9wPgoKPHVsPgo8bGk+UmlwcGluZyBvdXQgZGlzY292ZXJ5LiAg Q2hhbmdlZCB0byByZWZlciB0byBJLUQuam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXIgaW5zdGVhZCBv ZiBXRiBhbmQgU1dEIG9sZGVyIGRyYWZ0cy4gIDwvbGk+CjxsaT5SZXBsYWNpbmcgSFRUUCBhcyB0 aGUgbWVzc2FnZSBmb3JtYXQgYW5kIGFkanVzdGVkIGFsbCBleGFtcGxlcy4gIDwvbGk+CjwvdWw+ Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5wLjM2Ij4tMDAgPC9wPgo8 cD48L3A+Cgo8dWw+CjxsaT5SZW5hbWVkIGRyYWZ0IGludG8gcHJvcGVyIElFVEYgbmFtaW5nIGZv cm1hdCBub3cgdGhhdCBpdCdzIGFkb3B0ZWQuICA8L2xpPgo8bGk+TWlub3IgZml4ZXMuICA8L2xp Pgo8L3VsPgoKPHA+IDwvcD4KPGgxIGlkPSJyZmMuYXV0aG9ycyI+PGEgaHJlZj0iI3JmYy5hdXRo b3JzIj5BdXRob3JzJyBBZGRyZXNzZXM8L2E+PC9oMT4KPGRpdiBjbGFzcz0iYXZvaWRicmVhayI+ CiAgPGFkZHJlc3MgY2xhc3M9InZjYXJkIj4KCTxzcGFuIGNsYXNzPSJ2Y2FyZGxpbmUiPgoJICA8 c3BhbiBjbGFzcz0iZm4iPldpbGxpYW0gTWlsbHM8L3NwYW4+IAoJICA8c3BhbiBjbGFzcz0ibiBo aWRkZW4iPgoJCTxzcGFuIGNsYXNzPSJmYW1pbHktbmFtZSI+TWlsbHM8L3NwYW4+CgkgIDwvc3Bh bj4KCTwvc3Bhbj4KCTxzcGFuIGNsYXNzPSJvcmcgdmNhcmRsaW5lIj5NaWNyb3NvZnQ8L3NwYW4+ Cgk8c3BhbiBjbGFzcz0iYWRyIj4KCSAgCgkgIDxzcGFuIGNsYXNzPSJ2Y2FyZGxpbmUiPgoJCTxz cGFuIGNsYXNzPSJsb2NhbGl0eSI+PC9zcGFuPiAKCQk8c3BhbiBjbGFzcz0icmVnaW9uIj48L3Nw YW4+CgkJPHNwYW4gY2xhc3M9ImNvZGUiPjwvc3Bhbj4KCSAgPC9zcGFuPgoJICA8c3BhbiBjbGFz cz0iY291bnRyeS1uYW1lIHZjYXJkbGluZSI+PC9zcGFuPgoJPC9zcGFuPgoJPHNwYW4gY2xhc3M9 InZjYXJkbGluZSI+RU1haWw6IDxhIGhyZWY9Im1haWx0bzp3aW1pbGxzQG1pY3Jvc29mdC5jb20i PndpbWlsbHNAbWljcm9zb2Z0LmNvbTwvYT48L3NwYW4+CgogIDwvYWRkcmVzcz4KPC9kaXY+PGRp diBjbGFzcz0iYXZvaWRicmVhayI+CiAgPGFkZHJlc3MgY2xhc3M9InZjYXJkIj4KCTxzcGFuIGNs YXNzPSJ2Y2FyZGxpbmUiPgoJICA8c3BhbiBjbGFzcz0iZm4iPlRpbSBTaG93YWx0ZXI8L3NwYW4+ IAoJICA8c3BhbiBjbGFzcz0ibiBoaWRkZW4iPgoJCTxzcGFuIGNsYXNzPSJmYW1pbHktbmFtZSI+ U2hvd2FsdGVyPC9zcGFuPgoJICA8L3NwYW4+Cgk8L3NwYW4+Cgk8c3BhbiBjbGFzcz0ib3JnIHZj YXJkbGluZSI+PC9zcGFuPgoJPHNwYW4gY2xhc3M9ImFkciI+CgkgIAoJICA8c3BhbiBjbGFzcz0i dmNhcmRsaW5lIj4KCQk8c3BhbiBjbGFzcz0ibG9jYWxpdHkiPjwvc3Bhbj4gCgkJPHNwYW4gY2xh c3M9InJlZ2lvbiI+PC9zcGFuPgoJCTxzcGFuIGNsYXNzPSJjb2RlIj48L3NwYW4+CgkgIDwvc3Bh bj4KCSAgPHNwYW4gY2xhc3M9ImNvdW50cnktbmFtZSB2Y2FyZGxpbmUiPjwvc3Bhbj4KCTwvc3Bh bj4KCTxzcGFuIGNsYXNzPSJ2Y2FyZGxpbmUiPkVNYWlsOiA8YSBocmVmPSJtYWlsdG86dGpzQHBz YXV4LmNvbSI+dGpzQHBzYXV4LmNvbTwvYT48L3NwYW4+CgogIDwvYWRkcmVzcz4KPC9kaXY+PGRp diBjbGFzcz0iYXZvaWRicmVhayI+CiAgPGFkZHJlc3MgY2xhc3M9InZjYXJkIj4KCTxzcGFuIGNs YXNzPSJ2Y2FyZGxpbmUiPgoJICA8c3BhbiBjbGFzcz0iZm4iPkhhbm5lcyBUc2Nob2ZlbmlnIDwv c3Bhbj4gCgkgIDxzcGFuIGNsYXNzPSJuIGhpZGRlbiI+CgkJPHNwYW4gY2xhc3M9ImZhbWlseS1u YW1lIj5Uc2Nob2ZlbmlnPC9zcGFuPgoJICA8L3NwYW4+Cgk8L3NwYW4+Cgk8c3BhbiBjbGFzcz0i b3JnIHZjYXJkbGluZSI+QVJNIEx0ZC48L3NwYW4+Cgk8c3BhbiBjbGFzcz0iYWRyIj4KCSAgPHNw YW4+MTEwIEZ1bGJvdXJuIFJkPC9zcGFuPgoKCSAgPHNwYW4gY2xhc3M9InZjYXJkbGluZSI+CgkJ PHNwYW4gY2xhc3M9ImxvY2FsaXR5Ij5DYW1icmlkZ2U8L3NwYW4+LCAgCgkJPHNwYW4gY2xhc3M9 InJlZ2lvbiI+PC9zcGFuPgoJCTxzcGFuIGNsYXNzPSJjb2RlIj5DQjEgOU5KIDwvc3Bhbj4KCSAg PC9zcGFuPgoJICA8c3BhbiBjbGFzcz0iY291bnRyeS1uYW1lIHZjYXJkbGluZSI+R3JlYXQgQnJp dGFpbjwvc3Bhbj4KCTwvc3Bhbj4KCTxzcGFuIGNsYXNzPSJ2Y2FyZGxpbmUiPkVNYWlsOiA8YSBo cmVmPSJtYWlsdG86SGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCUyMCI+SGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldCA8L2E+PC9zcGFuPgoKPHNwYW4gY2xhc3M9InZjYXJkbGluZSI+VVJJOiA8YSBo cmVmPSJodHRwOi8vd3d3LnRzY2hvZmVuaWcucHJpdi5hdCI+aHR0cDovL3d3dy50c2Nob2Zlbmln LnByaXYuYXQ8L2E+PC9zcGFuPgoKICA8L2FkZHJlc3M+CjwvZGl2PgoKPC9ib2R5Pgo8L2h0bWw+ ------=_Part_819475_1041334597.1414534802287 Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=draft-ietf-kitten-sasl-oauth-17.txt Content-ID: <29f5dd9d-8f2f-8799-f7e5-969317d1272d@yahoo.com> DQ0KDQ0KDQ0KS0lUVEVOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFcuIE1pbGxzDQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0DQ0KSW50ZW5kZWQgc3Rh dHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gU2hvd2Fs dGVyDQ0KRXhwaXJlczogQXByaWwgMjksIDIwMTUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSC5ULiBUc2Nob2ZlbmlnDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFSTSBMdGQuDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI4LCAyMDE0 DQ0KDQ0KICAgICAgICAgICAgICAgICAgIEEgc2V0IG9mIFNBU0wgTWVjaGFuaXNtcyBmb3IgT0F1 dGgNDQogICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTE3LnR4 dA0NCg0NCkFic3RyYWN0DQ0KDQ0KICAgT0F1dGggZW5hYmxlcyBhIHRoaXJkLXBhcnR5IGFwcGxp Y2F0aW9uIHRvIG9idGFpbiBsaW1pdGVkIGFjY2VzcyB0byBhDQ0KICAgcHJvdGVjdGVkIHJlc291 cmNlLCBlaXRoZXIgb24gYmVoYWxmIG9mIGEgcmVzb3VyY2Ugb3duZXIgYnkNDQogICBvcmNoZXN0 cmF0aW5nIGFuIGFwcHJvdmFsIGludGVyYWN0aW9uLCBvciBieSBhbGxvd2luZyB0aGUgdGhpcmQt cGFydHkNDQogICBhcHBsaWNhdGlvbiB0byBvYnRhaW4gYWNjZXNzIG9uIGl0cyBvd24gYmVoYWxm Lg0NCg0NCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBob3cgYW4gYXBwbGljYXRpb24gY2xpZW50 IHVzZXMgY3JlZGVudGlhbHMNDQogICBvYnRhaW5lZCB2aWEgT0F1dGggb3ZlciB0aGUgU2ltcGxl IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cml0eSBMYXllcg0NCiAgIChTQVNMKSB0byBhY2Nlc3Mg YSBwcm90ZWN0ZWQgcmVzb3VyY2UgYXQgYSByZXNvdXJjZSBzZXJ2ZS4gIFRoZXJlYnksDQ0KICAg aXQgZW5hYmxlcyBzY2hlbWVzIGRlZmluZWQgd2l0aGluIHRoZSBPQXV0aCBmcmFtZXdvcmsgZm9y IG5vbi1IVFRQLQ0NCiAgIGJhc2VkIGFwcGxpY2F0aW9uIHByb3RvY29scy4NDQoNDQogICBDbGll bnRzIHR5cGljYWxseSBzdG9yZSB0aGUgdXNlcidzIGxvbmctdGVybSBjcmVkZW50aWFsLiAgVGhp cyBkb2VzLA0NCiAgIGhvd2V2ZXIsIGxlYWQgdG8gc2lnbmlmaWNhbnQgc2VjdXJpdHkgdnVsbmVy YWJpbGl0aWVzLCBmb3IgZXhhbXBsZSwNDQogICB3aGVuIHN1Y2ggYSBjcmVkZW50aWFsIGxlYWtz LiAgQSBzaWduaWZpY2FudCBiZW5lZml0IG9mIE9BdXRoIGZvcg0NCiAgIHVzYWdlIGluIHRob3Nl IGNsaWVudHMgaXMgdGhhdCB0aGUgcGFzc3dvcmQgaXMgcmVwbGFjZWQgYnkgYSBzaGFyZWQNDQog ICBzZWNyZXQgd2l0aCBoaWdoZXIgZW50cm9weSwgaS5lLiwgdGhlIHRva2VuLiAgVG9rZW5zIHR5 cGljYWxseQ0NCiAgIHByb3ZpZGUgbGltaXRlZCBhY2Nlc3MgcmlnaHRzIGFuZCBjYW4gYmUgbWFu YWdlZCBhbmQgcmV2b2tlZA0NCiAgIHNlcGFyYXRlbHkgZnJvbSB0aGUgdXNlcidzIGxvbmctdGVy bSBwYXNzd29yZC4NDQoNDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQ0KDQ0KICAgVGhpcyBJbnRlcm5l dC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0NCiAgIHBy b3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQ0KDQ0KICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNDQogICBUYXNr IEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0 ZQ0NCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtDQ0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQ0KDQ0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQ0KICAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBh dCBhbnkNDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQ0NCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzICJ3b3JrIGluIHByb2dyZXNzLiINDQoNDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIEFwcmlsIDI5LCAyMDE1Lg0NCg0NCkNvcHlyaWdodCBOb3RpY2UNDQoNDQoNDQoN DQoNDQpNaWxscywgU2hvd2FsdGVyICYgVHNjaG9mRXhwaXJlcyBBcHJpbCAyOSwgMjAxNSAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0NDQoMDQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg IFNBU0wgT0F1dGggICAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDE0DQ0KDQ0KICAgQ29weXJp Z2h0IChjKSAyMDE0IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl DQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQ0KDQ0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bA0NCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnLw0NCiAgIGxpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9m IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQ0KICAgUGxlYXNlIHJldmlldyB0aGVzZSBk b2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzDQ0KICAgYW5k IHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cw0NCiAgIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdCBpbmNsdWRlIFNpbXBs aWZpZWQgQlNEIExpY2Vuc2UgdGV4dA0NCiAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBv ZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlDQ0KICAgcHJvdmlkZWQgd2l0aG91 dCB3YXJyYW50eSBhcyBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQ0K DQ0KVGFibGUgb2YgQ29udGVudHMNDQoNDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDINDQogICAyLiAgVGVybWlu b2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDUNDQogICAzLiAgT0F1dGggU0FTTCBNZWNoYW5pc20gU3BlY2lmaWNhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUNDQogICAgIDMuMS4gIEluaXRpYWwgQ2xpZW50IFJlc3BvbnNl ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNDQogICAgICAgMy4xLjEuICBS ZXNlcnZlZCBLZXkvVmFsdWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcN DQogICAgIDMuMi4gIFNlcnZlcidzIFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDcNDQogICAgICAgMy4yLjEuICBPQXV0aCBJZGVudGlmaWVycyBpbiB0 aGUgU0FTTCBDb250ZXh0ICAuIC4gLiAuIC4gLiAuIC4gIDgNDQogICAgICAgMy4yLjIuICBTZXJ2 ZXIgUmVzcG9uc2UgdG8gRmFpbGVkIEF1dGhlbnRpY2F0aW9uIC4gLiAuIC4gLiAuIC4gIDgNDQog ICAgICAgMy4yLjMuICBDb21wbGV0aW5nIGFuIEVycm9yIE1lc3NhZ2UgU2VxdWVuY2UgLiAuIC4g LiAuIC4gLiAuIC4gIDkNDQogICAgIDMuMy4gIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlcyB1c2lu ZyBLZXllZCBNZXNzYWdlIERpZ2VzdHMgLiAuIC4gIDkNDQogICA0LiAgRXhhbXBsZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANDQogICAg IDQuMS4gIFN1Y2Nlc3NmdWwgQmVhcmVyIFRva2VuIEV4Y2hhbmdlIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTENDQogICAgIDQuMi4gIFN1Y2Nlc3NmdWwgT0F1dGggMS4wYSBUb2tlbiBFeGNo YW5nZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENDQogICAgIDQuMy4gIEZhaWxlZCBFeGNoYW5n ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINDQogICAgIDQu NC4gIFNNVFAgRXhhbXBsZSBvZiBhIEZhaWxlZCBOZWdvdGlhdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTMNDQogICA1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNDQogICA2LiAgSW50ZXJuYXRpb25hbGl6YXRpb24g Q29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNDQogICA3LiAgSUFO QSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTUNDQogICAgIDcuMS4gIFNBU0wgUmVnaXN0cmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNDQogICA4LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNDQogICAgIDguMS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTUNDQogICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTYNDQogICBBcHBlbmRpeCBBLiBBY2tub3dsZWdlbWVudHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNDQogICBBcHBlbmRpeCBCLiBE b2N1bWVudCBIaXN0b3J5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcN DQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjANDQoNDQoxLiAgSW50cm9kdWN0aW9uDQ0KDQ0KICAgT0F1dGggMS4w YSBbUkZDNTg0OV0gYW5kIE9BdXRoIDIuMCBbUkZDNjc0OV0gYXJlIHByb3RvY29sIGZyYW1ld29y a3MNDQogICB0aGF0IGVuYWJsZSBhIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBs aW1pdGVkIGFjY2VzcyB0byBhDQ0KICAgcHJvdGVjdGVkIHJlc291cmNlLCBlaXRoZXIgb24gYmVo YWxmIG9mIGEgcmVzb3VyY2Ugb3duZXIgYnkNDQogICBvcmNoZXN0cmF0aW5nIGFuIGFwcHJvdmFs IGludGVyYWN0aW9uLCBvciBieSBhbGxvd2luZyB0aGUgdGhpcmQtcGFydHkNDQogICBhcHBsaWNh dGlvbiB0byBvYnRhaW4gYWNjZXNzIG9uIGl0cyBvd24gYmVoYWxmLg0NCg0NCg0NCg0NCg0NCg0N Cg0NCg0NCg0NCk1pbGxzLCBTaG93YWx0ZXIgJiBUc2Nob2ZFeHBpcmVzIEFwcmlsIDI5LCAyMDE1 ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0NCgwNDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgU0FTTCBPQXV0aCAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTQNDQoNDQoNDQog ICBUaGUgY29yZSBPQXV0aCAyLjAgc3BlY2lmaWNhdGlvbiBbUkZDNjc0OV0gc3BlY2lmaWVzIHRo ZSBpbnRlcmFjdGlvbg0NCiAgIGJldHdlZW4gdGhlIE9BdXRoIGNsaWVudCBhbmQgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyOyBpdCBkb2VzIG5vdA0NCiAgIGRlZmluZSB0aGUgaW50ZXJhY3Rpb24g YmV0d2VlbiB0aGUgT0F1dGggY2xpZW50IGFuZCB0aGUgcmVzb3VyY2UNDQogICBzZXJ2ZXIgZm9y IHRoZSBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2UgdXNpbmcgYW4gQWNjZXNzIFRva2Vu Lg0NCiAgIEluc3RlYWQsIHRoZSBPQXV0aCBjbGllbnQgdG8gcmVzb3VyY2Ugc2VydmVyIGludGVy YWN0aW9uIGlzIGRlc2NyaWJlZA0NCiAgIGluIHNlcGFyYXRlIHNwZWNpZmljYXRpb25zLCBzdWNo IGFzIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbg0NCiAgIFtSRkM2NzUwXSBhbmQgdGhl IE1BQyBUb2tlbiBzcGVjaWZpY2F0aW9uIFtJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLQ0NCiAgIG1h Y10uICBPQXV0aCAxLjBhIGluY2x1ZGVkIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGZvciB0 aGUNDQogICBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIE9BdXRoIGNsaWVudCBhbmQgdGhlIHJl c291cmNlIHNlcnZlciBpbg0NCiAgIFtSRkM1ODQ5XS4NDQoNDQogICBUaGUgbWFpbiB1c2UgY2Fz ZXMgZm9yIE9BdXRoIDIuMCBhbmQgT0F1dGggMS4wYSBoYXZlIHNvIGZhciBmb2N1c2VkDQ0KICAg b24gYW4gSFRUUC1iYXNlZCBbUkZDMjYxNl0gZW52aXJvbm1lbnQgb25seS4gIFRoaXMgZG9jdW1l bnQNDQogICBpbnRlZ3JhdGVzIE9BdXRoIDEuMGEgYW5kIE9BdXRoIDIuMCBpbnRvIG5vbi1IVFRQ LWJhc2VkIGFwcGxpY2F0aW9ucw0NCiAgIHVzaW5nIHRoZSBpbnRlZ3JhdGlvbiBpbnRvIFNBU0wu ICBIZW5jZSwgdGhpcyBkb2N1bWVudCAgdGFrZXMNDQogICBhZHZhbnRhZ2Ugb2YgdGhlIE9BdXRo IHByb3RvY29sIGFuZCBpdHMgZGVwbG95bWVudCBiYXNlIHRvIHByb3ZpZGUgYQ0NCiAgIHdheSB0 byB1c2UgdGhlIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNBU0wp DQ0KICAgW1JGQzQ0MjJdIHRvIGdhaW4gYWNjZXNzIHRvIHJlc291cmNlcyB3aGVuIHVzaW5nIG5v bi1IVFRQLWJhc2VkDQ0KICAgcHJvdG9jb2xzLCBzdWNoIGFzIHRoZSBJbnRlcm5ldCBNZXNzYWdl IEFjY2VzcyBQcm90b2NvbCAoSU1BUCkNDQogICBbUkZDMzUwMV0gYW5kIHRoZSBTaW1wbGUgTWFp bCBUcmFuc2ZlciBQcm90b2NvbCAoU01UUCkgW1JGQzUzMjFdLA0NCiAgIHdoaWNoIGlzIHdoYXQg dGhpcyBtZW1vIHVzZXMgaW4gdGhlIGV4YW1wbGVzLg0NCg0NCiAgIFRvIGlsbHVzdHJhdGUgdGhl IGltcGFjdCBvZiBpbnRlZ3JhdGluZyB0aGlzIHNwZWNpZmljYXRpb24gaW50byBhbg0NCiAgIE9B dXRoLWVuYWJsZWQgYXBwbGljYXRpb24gZW52aXJvbm1lbnQsIEZpZ3VyZSAxIHNob3dzIHRoZSBh YnN0cmFjdA0NCiAgIG1lc3NhZ2UgZmxvdyBvZiBPQXV0aCAyLjAgW1JGQzY3NDldLiAgQXMgaW5k aWNhdGVkIGluIHRoZSBmaWd1cmUsDQ0KICAgdGhpcyBkb2N1bWVudCBpbXBhY3RzIHRoZSBleGNo YW5nZSBvZiBtZXNzYWdlcyAoRSkgYW5kIChGKSBzaW5jZSBTQVNMDQ0KICAgaXMgdXNlZCBmb3Ig aW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVzb3VyY2Ugc2VydmVyDQ0K ICAgaW5zdGVhZCBvZiBIVFRQLg0NCg0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLSsNDQogICArLS0tLS0tLS0rICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICB8DQ0KICAgfCAg ICAgICAgfC0tKEEpLS0gQXV0aG9yaXphdGlvbiBSZXF1ZXN0IC0tLT58ICAgUmVzb3VyY2UgICAg fCAgfA0NCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgT3duZXIgICAgIHwgIHxQbGFpbg0NCiAgIHwgICAgICAgIHw8LShCKS0tLS0tLSBBY2Nlc3Mg R3JhbnQgLS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwgIHxPQXV0aA0NCiAgIHwgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwyLjAN DQogICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQ0KICAgfCAgICAgICAgfCAgICAgICAgIENsaWVudCBDcmVkZW50aWFscyAm ICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfA0NCiAgIHwgICAgICAgIHwtLShDKS0tLS0tLSBBY2Nl c3MgR3JhbnQgLS0tLS0tLS0+fCBBdXRob3JpemF0aW9uIHwgIHwNDQogICB8IENsaWVudCB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8ICB8DQ0KICAg fCAgICAgICAgfDwtKEQpLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS18ICAgICAgICAgICAg ICAgfCAgfA0NCiAgIHwgICAgICAgIHwgICAgICAody8gT3B0aW9uYWwgUmVmcmVzaCBUb2tlbikg Ky0tLS0tLS0tLS0tLS0tLSsgIHwNDQogICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0rDQ0KICAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tKw0NCiAgIHwgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsg IHwNDQogICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICB8ICB8T0F1dGgNDQogICB8ICAgICAgICB8LS0oRSktLS0tLS0gQWNjZXNzIFRv a2VuIC0tLS0tLS0tPnwgICAgUmVzb3VyY2UgICB8ICB8b3Zlcg0NCiAgIHwgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwgIHxTQVNMDQ0K ICAgfCAgICAgICAgfDwtKEYpLS0tLSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0tLS18ICAgICAgICAg ICAgICAgfCAgfA0NCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwgIHwNDQoNDQoNDQoNDQoNDQoNDQpNaWxscywgU2hvd2FsdGVy ICYgVHNjaG9mRXhwaXJlcyBBcHJpbCAyOSwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgM10N DQoMDQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFNBU0wgT0F1dGggICAgICAgICAg ICAgICAgICAgT2N0b2JlciAyMDE0DQ0KDQ0KICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfA0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLSsNDQoNDQog ICBUaGUgU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cml0eSBMYXllciAoU0FTTCkgaXMg YSBmcmFtZXdvcmsNDQogICBmb3IgcHJvdmlkaW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBkYXRhIHNl Y3VyaXR5IHNlcnZpY2VzIGluDQ0KICAgY29ubmVjdGlvbi1vcmllbnRlZCBwcm90b2NvbHMgdmlh IHJlcGxhY2VhYmxlIGF1dGhlbnRpY2F0aW9uDQ0KICAgbWVjaGFuaXNtcy4gIEl0IHByb3ZpZGVz IGEgc3RydWN0dXJlZCBpbnRlcmZhY2UgYmV0d2VlbiBwcm90b2NvbHMgYW5kDQ0KICAgbWVjaGFu aXNtcy4gIFRoZSByZXN1bHRpbmcgZnJhbWV3b3JrIGFsbG93cyBuZXcgcHJvdG9jb2xzIHRvIHJl dXNlDQ0KICAgZXhpc3RpbmcgYXV0aGVudGljYXRpb24gcHJvdG9jb2xzIGFuZCBhbGxvd3Mgb2xk IHByb3RvY29scyB0byBtYWtlDQ0KICAgdXNlIG9mIG5ldyBhdXRoZW50aWNhdGlvbiBtZWNoYW5p c21zLiAgVGhlIGZyYW1ld29yayBhbHNvIHByb3ZpZGVzIGENDQogICBwcm90b2NvbCBmb3Igc2Vj dXJpbmcgc3Vic2VxdWVudCBleGNoYW5nZXMgd2l0aGluIGEgZGF0YSBzZWN1cml0eQ0NCiAgIGxh eWVyLg0NCg0NCiAgIFdoZW4gT0F1dGggaXMgaW50ZWdyYXRlZCBpbnRvIFNBU0wgdGhlIGhpZ2gt bGV2ZWwgc3RlcHMgYXJlIGFzDQ0KICAgZm9sbG93czoNDQoNDQogICAgICAoQSkgIFRoZSBjbGll bnQgcmVxdWVzdHMgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4NDQogICAg ICBUaGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGNhbiBiZSBtYWRlIGRpcmVjdGx5IHRvIHRoZSBy ZXNvdXJjZQ0NCiAgICAgIG93bmVyIChhcyBzaG93biksIG9yIHByZWZlcmFibHkgaW5kaXJlY3Rs eSB2aWEgdGhlIGF1dGhvcml6YXRpb24NDQogICAgICBzZXJ2ZXIgYXMgYW4gaW50ZXJtZWRpYXJ5 Lg0NCg0NCiAgICAgIChCKSAgVGhlIGNsaWVudCByZWNlaXZlcyBhbiBhdXRob3JpemF0aW9uIGdy YW50IHdoaWNoIGlzIGENDQogICAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3Vy Y2Ugb3duZXIncyBhdXRob3JpemF0aW9uLA0NCiAgICAgIGV4cHJlc3NlZCB1c2luZyBvbmUgb2Yg dGhlIGdyYW50IHR5cGVzIGRlZmluZWQgaW4gW1JGQzY3NDldIG9yDQ0KICAgICAgW1JGQzU4NDld IG9yIHVzaW5nIGFuIGV4dGVuc2lvbiBncmFudCB0eXBlLiAgVGhlIGF1dGhvcml6YXRpb24NDQog ICAgICBncmFudCB0eXBlIGRlcGVuZHMgb24gdGhlIG1ldGhvZCB1c2VkIGJ5IHRoZSBjbGllbnQg dG8gcmVxdWVzdA0NCiAgICAgIGF1dGhvcml6YXRpb24gYW5kIHRoZSB0eXBlcyBzdXBwb3J0ZWQg YnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0NCg0NCiAgICAgIChDKSAgVGhlIGNsaWVudCBy ZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aA0NCiAgICAgIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcHJlc2VudGluZyB0aGUgYXV0aG9yaXphdGlvbiBn cmFudC4NDQoNDQogICAgICAoRCkgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNh dGVzIHRoZSBjbGllbnQgYW5kDQ0KICAgICAgdmFsaWRhdGVzIHRoZSBhdXRob3JpemF0aW9uIGdy YW50LCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2Vzcw0NCiAgICAgIHRva2VuLg0NCg0NCiAg ICAgIChFKSAgVGhlIGNsaWVudCByZXF1ZXN0cyB0aGUgcHJvdGVjdGVkIHJlc291cmNlIGZyb20g dGhlIHJlc291cmNlDQ0KICAgICAgc2VydmVyIGFuZCBhdXRoZW50aWNhdGVzIGJ5IHByZXNlbnRp bmcgdGhlIGFjY2VzcyB0b2tlbi4NDQoNDQogICAgICAoRikgIFRoZSByZXNvdXJjZSBzZXJ2ZXIg dmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwNDQogICAgICBpbmRpY2F0 ZXMgYSBzdWNjZXNzZnVsIGF1dGhlbnRpY2F0aW9uLg0NCg0NCg0NCg0NCg0NCg0NCg0NCg0NCg0N Cg0NCg0NCg0NCg0NCg0NCg0NCg0NCk1pbGxzLCBTaG93YWx0ZXIgJiBUc2Nob2ZFeHBpcmVzIEFw cmlsIDI5LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0NCgwNDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgU0FTTCBPQXV0aCAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIw MTQNDQoNDQoNDQogICBBZ2Fpbiwgc3RlcHMgKEUpIGFuZCAoRikgYXJlIG5vdCBkZWZpbmVkIGlu IFtSRkM2NzQ5XSAoYnV0IGFyZQ0NCiAgIGRlc2NyaWJlZCBpbiwgZm9yIGV4YW1wbGUsIFtSRkM2 NzUwXSBmb3IgdGhlIE9BdXRoIEJlYXJlciBUb2tlbg0NCiAgIGluc3RlYWQpIGFuZCBhcmUgdGhl IG1haW4gZnVuY3Rpb25hbGl0eSBzcGVjaWZpZWQgd2l0aGluIHRoaXMNDQogICBkb2N1bWVudC4g IENvbnNlcXVlbnRseSwgdGhlIG1lc3NhZ2UgZXhjaGFuZ2Ugc2hvd24gaW4gRmlndXJlIDEgaXMN DQogICB0aGUgcmVzdWx0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBjbGllbnQgd2lsbCBn ZW5lcmFsbHkgbmVlZCB0bw0NCiAgIGRldGVybWluZSB0aGUgYXV0aGVudGljYXRpb24gZW5kcG9p bnRzIChhbmQgcGVyaGFwcyB0aGUgc2VydmljZQ0NCiAgIGVuZHBvaW50cykgYmVmb3JlIHRoZSBP QXV0aCAyLjAgcHJvdG9jb2wgZXhjaGFuZ2UgbWVzc2FnZXMgaW4gc3RlcHMNDQogICAoQSktKEQp IGFyZSBleGVjdXRlZC4gIFRoZSBkaXNjb3Zlcnkgb2YgdGhlIHJlc291cmNlIG93bmVyLA0NCiAg IGF1dGhvcml6YXRpb24gc2VydmVyIGVuZHBvaW50cywgYW5kIGNsaWVudCByZWdpc3RyYXRpb24g YXJlIG91dHNpZGUNDQogICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhlIGNs aWVudCBtdXN0IGRpc2NvdmVyIHRoZQ0NCiAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnRzIHVzaW5n IGEgZGlzY292ZXJ5IG1lY2hhbmlzbSBzdWNoIGFzIE9wZW5JRA0NCiAgIENvbm5lY3QgRGlzY292 ZXJ5IFtPcGVuSUQuRGlzY292ZXJ5XSBvciBXZWJmaW5nZXIgdXNpbmcgaG9zdC1tZXRhDQ0KICAg W1JGQzcwMzNdLiAgT25jZSBjcmVkZW50aWFscyBhcmUgb2J0YWluZWQgdGhlIGNsaWVudCBwcm9j ZWVkcyB0bw0NCiAgIHN0ZXBzIChFKSBhbmQgKEYpIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0 aW9uLiAgQXV0aG9yaXphdGlvbg0NCiAgIGVuZHBvaW50cyBNQVkgcmVxdWlyZSBjbGllbnQgcmVn aXN0cmF0aW9uIGFuZCBnZW5lcmljIGNsaWVudHMgU0hPVUxEDQ0KICAgc3VwcG9ydCB0aGUgRHlu YW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHByb3RvY29sICBbSS1ELmlldGYtb2F1dGgtDQ0KICAg ZHluLXJlZ10uDQ0KDQ0KICAgT0F1dGggMS4wIGZvbGxvd3MgYSBzaW1pbGFyIG1vZGVsIGJ1dCB1 c2VzIGEgZGlmZmVyZW50IHRlcm1pbm9sb2d5DQ0KICAgYW5kIGRvZXMgbm90IHNlcGFyYXRlIHRo ZSByZXNvdXJjZSBzZXJ2ZXIgZnJvbSB0aGUgYXV0aG9yaXphdGlvbg0NCiAgIHNlcnZlci4NDQoN DQoyLiAgVGVybWlub2xvZ3kNDQoNDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQ0KICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNDQog ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5 XS4NDQoNDQogICBUaGUgcmVhZGVyIGlzIGFzc3VtZWQgdG8gYmUgZmFtaWxpYXIgd2l0aCB0aGUg dGVybXMgdXNlZCBpbiB0aGUgT0F1dGgNDQogICAyLjAgc3BlY2lmaWNhdGlvbiBbUkZDNjc0OV0g YW5kIFNBU0wgW1JGQzQ0MjJdLg0NCg0NCiAgIEluIGV4YW1wbGVzLCAiQzoiIGFuZCAiUzoiIGlu ZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQNDQogICBzZXJ2ZXIgcmVzcGVjdGl2 ZWx5LiAgTGluZSBicmVha3MgaGF2ZSBiZWVuIGluc2VydGVkIGZvciByZWFkYWJpbGl0eS4NDQoN DQogICBOb3RlIHRoYXQgdGhlIElNQVAgU0FTTCBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIGJhc2U2 NCBlbmNvZGluZywgc2VlDQ0KICAgU2VjdGlvbiA0IG9mIFtSRkM0NjQ4XSwgbm90IHRoaXMgbWVt by4NDQoNDQozLiAgT0F1dGggU0FTTCBNZWNoYW5pc20gU3BlY2lmaWNhdGlvbnMNDQoNDQogICBT QVNMIGlzIHVzZWQgYXMgYW4gYXV0aGVudGljYXRpb24gZnJhbWV3b3JrIGluIGEgdmFyaWV0eSBv Zg0NCiAgIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29scy4gIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyB0aGUgZm9sbG93aW5nDQ0KICAgU0FTTCBtZWNoYW5pc21zIGZvciB1c2FnZSB3aXRoIE9BdXRo Og0NCg0NCiAgICAgIA0NCg0NCiAgICAgIE9BVVRIQkVBUkVSOiBPQXV0aCAyLjAgYmVhcmVyIHRv a2VucywgYXMgZGVzY3JpYmVkIGluIFtSRkM2NzUwXS4NDQogICAgICAgICBSRkMgNjc1MCB1c2Vz IFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSB0byBzZWN1cmUgdGhlDQ0KICAgICAgICAg cHJvdG9jb2wgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVzb3VyY2UN DQogICAgICAgICBzZXJ2ZXIuDQ0KDQ0KICAgICAgT0FVVEgxMEE6IE9BdXRoIDEuMGEgTUFDIHRv a2VucyAodXNpbmcgdGhlIEhNQUMtU0hBMSBrZXllZCBtZXNzYWdlDQ0KICAgICAgICAgZGlnZXN0 KSwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LjIgb2YgW1JGQzU4NDldLg0NCg0NCg0NCk1p bGxzLCBTaG93YWx0ZXIgJiBUc2Nob2ZFeHBpcmVzIEFwcmlsIDI5LCAyMDE1ICAgICAgICAgICAg ICAgICBbUGFnZSA1XQ0NCgwNDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgU0FTTCBP QXV0aCAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTQNDQoNDQoNDQogICBOZXcgZXh0ZW5z aW9ucyBtYXkgYmUgZGVmaW5lZCB0byBhZGQgYWRkaXRpb25hbCBPQXV0aCBBY2Nlc3MgVG9rZW4N DQogICBUeXBlcy4gIFN1Y2ggYSBuZXcgU0FTTCBPQXV0aCBtZWNoYW5pc20gY2FuIGJlIGFkZGVk IGJ5IHNpbXBseQ0NCiAgIHJlZ2lzdGVyaW5nIHRoZSBuZXcgbmFtZShzKSBhbmQgY2l0aW5nIHRo aXMgc3BlY2lmaWNhdGlvbiBmb3IgdGhlDQ0KICAgZnVydGhlciBkZWZpbml0aW9uLg0NCg0NCiAg IFRoZXNlIG1lY2hhbmlzbXMgYXJlIGNsaWVudCBpbml0aWF0ZWQgYW5kIGxvY2stc3RlcCwgdGhl IHNlcnZlcg0NCiAgIGFsd2F5cyByZXBseWluZyB0byBhIGNsaWVudCBtZXNzYWdlLiAgSW4gdGhl IGNhc2Ugd2hlcmUgdGhlIGNsaWVudA0NCiAgIGhhcyBhbmQgY29ycmVjdGx5IHVzZXMgYSB2YWxp ZCB0b2tlbiB0aGUgZmxvdyBpczoNDQoNDQogICAxLiAgQ2xpZW50IHNlbmRzIGEgdmFsaWQgYW5k IGNvcnJlY3QgaW5pdGlhbCBjbGllbnQgcmVzcG9uc2UuDQ0KDQ0KICAgMi4gIFNlcnZlciByZXNw b25kcyB3aXRoIGEgc3VjY2Vzc2Z1bCBhdXRoZW50aWNhdGlvbi4NDQoNDQogICBJbiB0aGUgY2Fz ZSB3aGVyZSBhdXRob3JpemF0aW9uIGZhaWxzIHRoZSBzZXJ2ZXIgc2VuZHMgYW4gZXJyb3INDQog ICByZXN1bHQsIHRoZW4gY2xpZW50IE1VU1QgdGhlbiBzZW5kIGFuIGFkZGl0aW9uYWwgbWVzc2Fn ZSB0byB0aGUNDQogICBzZXJ2ZXIgaW4gb3JkZXIgdG8gYWxsb3cgdGhlIHNlcnZlciB0byBmaW5p c2ggdGhlIGV4Y2hhbmdlLiAgU29tZQ0NCiAgIHByb3RvY29scyBhbmQgY29tbW9uIFNBU0wgaW1w bGVtZW50YXRpb25zIGRvIG5vdCBzdXBwb3J0IGJvdGggc2VuZGluZw0NCiAgIGEgU0FTTCBtZXNz YWdlIGFuZCBmaW5hbGl6aW5nIGEgU0FTTCBuZWdvdGlhdGlvbiwgdGhlIGFkZGl0aW9uYWwNDQog ICBjbGllbnQgbWVzc2FnZSBpbiB0aGUgZXJyb3IgY2FzZSBkZWFscyB3aXRoIHRoaXMgcHJvYmxl bS4gIFRoaXMNDQogICBleGNoYW5nZSBpczoNDQoNDQogICAxLiAgQ2xpZW50IHNlbmRzIGFuIGlu dmFsaWQgaW5pdGlhbCBjbGllbnQgcmVzcG9uc2UuDQ0KDQ0KICAgMi4gIFNlcnZlciByZXNwb25k cyB3aXRoIGFuIGVycm9yIG1lc3NhZ2UuDQ0KDQ0KICAgMy4gIENsaWVudCBzZW5kcyBhIGR1bW15 IGNsaWVudCByZXNwb25zZS4NDQoNDQogICA0LiAgU2VydmVyIGZhaWxzIHRoZSBhdXRoZW50aWNh dGlvbi4NDQoNDQozLjEuICBJbml0aWFsIENsaWVudCBSZXNwb25zZQ0NCg0NCiAgIENsaWVudCBy ZXNwb25zZXMgYXJlIGEgR1MyIFtSRkM1ODAxXSBoZWFkZXIgZm9sbG93ZWQgYnkgemVybyBvciBt b3JlDQ0KICAga2V5L3ZhbHVlIHBhaXJzLCBvciBtYXkgYmUgZW1wdHkuICBUaGUgZ3MyLWhlYWRl ciBpcyBkZWZpbmVkIGhlcmUgZm9yDQ0KICAgY29tcGF0aWJpbGl0eSB3aXRoIEdTMiBpZiBhIEdT MiBtZWNoYW5pc20gaXMgZm9ybWFsbHkgZGVmaW5lZCwgYnV0DQ0KICAgdGhpcyBkb2N1bWVudCBk b2VzIG5vdCBkZWZpbmUgb25lLiAgVGhlc2Uga2V5L3ZhbHVlIHBhaXJzIHRha2UgdGhlDQ0KICAg cGxhY2Ugb2YgdGhlIGNvcnJlc3BvbmRpbmcgSFRUUCBoZWFkZXJzIGFuZCB2YWx1ZXMgdG8gY29u dmV5IHRoZQ0NCiAgIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSB0byBjb21wbGV0ZSBhbiBPQXV0aCBz dHlsZSBIVFRQIGF1dGhvcml6YXRpb24uDQ0KICAgVW5rbm93biBrZXkvdmFsdWUgcGFpcnMgTVVT VCBiZSBpZ25vcmVkIGJ5IHRoZSBzZXJ2ZXIuICBUaGUgQUJORg0NCiAgIFtSRkM1MjM0XSBzeW50 YXggaXM6DQ0KDQ0KICAgDQ0KICAgICBrdnNlcCAgICAgICAgICA9ICV4MDENDQogICAgIGtleSAg ICAgICAgICAgID0gMSooQUxQSEEgLyAiLCIpDQ0KICAgICB2YWx1ZSAgICAgICAgICA9ICooVkNI QVIgLyBTUCAvIEhUQUIgLyBDUiAvIExGICkNDQogICAgIGt2cGFpciAgICAgICAgID0ga2V5ICI9 IiB2YWx1ZSBrdnNlcA0NCiAgIDs7Z3MyLWhlYWRlciAgICAgPSBTZWUgUkZDIDU4MDENDQogICAg IGNsaWVudF9yZXNwICAgID0gKGdzMi1oZWFkZXIga3ZzZXAgMCprdnBhaXIga3ZzZXApIC8ga3Zz ZXANDQoNDQogICBUaGUgR1MyIGhlYWRlciBNQVkgaW5jbHVkZSB0aGUgdXNlciBuYW1lIGFzc29j aWF0ZWQgd2l0aCB0aGUgcmVzb3VyY2UNDQogICBiZWluZyBhY2Nlc3NlZCwgdGhlICJhdXRoemlk Ii4gIEl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IGFwcGxpY2F0aW9uDQ0KDQ0KDQ0KDQ0KDQ0KTWls bHMsIFNob3dhbHRlciAmIFRzY2hvZkV4cGlyZXMgQXByaWwgMjksIDIwMTUgICAgICAgICAgICAg ICAgIFtQYWdlIDZdDQ0KDA0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBTQVNMIE9B dXRoICAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNA0NCg0NCiAgIHByb3RvY29scyBhcmUg YWxsb3dlZCB0byByZXF1aXJlIGFuIGF1dGh6aWQsIGFzIGFyZSBzcGVjaWZpYyBzZXJ2ZXINDQog ICBpbXBsZW1lbnRhdGlvbnMuDQ0KDQ0KICAgVGhlIGZvbGxvd2luZyBrZXlzIGFuZCBjb3JyZXNw b25kaW5nIHZhbHVlcyBhcmUgZGVmaW5lZCBpbiB0aGUgY2xpZW50DQ0KICAgcmVzcG9uc2U6DQ0K DQ0KICAgICAgDQ0KDQ0KICAgICAgYXV0aCAoUkVRVUlSRUQpOiBUaGUgcGF5bG9hZCB0aGF0IHdv dWxkIGJlIGluIHRoZSBIVFRQDQ0KICAgICAgICAgQXV0aG9yaXphdGlvbiBoZWFkZXIgaWYgdGhp cyBPQXV0aCBleGNoYW5nZSB3YXMgYmVpbmcgY2FycmllZA0NCiAgICAgICAgIG91dCBvdmVyIEhU VFAuDQ0KDQ0KICAgICAgaG9zdDogQ29udGFpbnMgdGhlIGhvc3QgbmFtZSB0byB3aGljaCB0aGUg Y2xpZW50IGNvbm5lY3RlZC4gIEluIGFuDQ0KICAgICAgICAgSFRUUCBjb250ZXh0IHRoaXMgaXMg dGhlIHZhbHVlIG9mIHRoZSBIVFRQIEhvc3QgaGVhZGVyLg0NCg0NCiAgICAgIHBvcnQ6IENvbnRh aW5zIHRoZSBwb3J0IG51bWJlciByZXByZXNlbnRlZCBhcyBhIGRlY2ltYWwgcG9zaXRpdmUNDQog ICAgICAgICBpbnRlZ2VyIHN0cmluZyB3aXRob3V0IGxlYWRpbmcgemVyb3MgdG8gd2hpY2ggdGhl IGNsaWVudA0NCiAgICAgICAgIGNvbm5lY3RlZC4NDQoNDQogICBGb3IgT0F1dGggdG9rZW4gdHlw ZXMgc3VjaCBhcyBPQXV0aCAxLjBhIHRoYXQgdXNlIGtleWVkIG1lc3NhZ2UNDQogICBkaWdlc3Rz IHRoZSBjbGllbnQgTVVTVCBzZW5kIGhvc3QgYW5kIHBvcnQgbnVtYmVyIGtleS92YWx1ZXMsIGFu ZCB0aGUNDQogICBzZXJ2ZXIgTVVTVCBmYWlsIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCByZXF1 aXJpbmcga2V5ZWQgbWVzc2FnZQ0NCiAgIGRpZ2VzdHMgdGhhdCBhcmUgbm90IGFjY29tcGFuaWVk IGJ5IGhvc3QgYW5kIHBvcnQgdmFsdWVzLiAgIEluIE9BdXRoDQ0KICAgMS4wYSBmb3IgZXhhbXBs ZSwgdGhlIHNvLWNhbGxlZCAic2lnbmF0dXJlIGJhc2Ugc3RyaW5nIGNhbGN1bGF0aW9uIg0NCiAg IGluY2x1ZGVzIHRoZSByZWNvbnN0cnVjdGVkIEhUVFAgVVJMLg0NCg0NCjMuMS4xLiAgUmVzZXJ2 ZWQgS2V5L1ZhbHVlcw0NCg0NCiAgIEluIHRoZXNlIG1lY2hhbmlzbXMgdmFsdWVzIGZvciBwYXRo LCBxdWVyeSBzdHJpbmcgYW5kIHBvc3QgYm9keSBhcmUNDQogICBhc3NpZ25lZCBkZWZhdWx0IHZh bHVlcy4gIE9BdXRoIGF1dGhvcml6YXRpb24gc2NoZW1lcyBNQVkgZGVmaW5lDQ0KICAgdXNhZ2Ug b2YgdGhlc2UgaW4gdGhlIFNBU0wgY29udGV4dCBhbmQgZXh0ZW5kIHRoaXMgc3BlY2lmaWNhdGlv bi4NDQogICBGb3IgT0F1dGggQWNjZXNzIFRva2VuIFR5cGVzIHRoYXQgdXNlIHJlcXVlc3Qga2V5 ZWQgbWVzc2FnZSBkaWdlc3QNDQogICB0aGUgZGVmYXVsdCB2YWx1ZXMgTVVTVCBiZSB1c2VkIHVu bGVzcyBleHBsaWNpdCB2YWx1ZXMgYXJlIHByb3ZpZGVkDQ0KICAgaW4gdGhlIGNsaWVudCByZXNw b25zZS4gIFRoZSBmb2xsb3dpbmcga2V5IHZhbHVlcyBhcmUgcmVzZXJ2ZWQgZm9yDQ0KICAgZnV0 dXJlIHVzZToNDQoNDQogICAgICANDQoNDQogICAgICBtdGhkIChSRVNFUlZFRCk6IEhUVFAgbWV0 aG9kLCB0aGUgZGVmYXVsdCB2YWx1ZSBpcyAiUE9TVCIuDQ0KDQ0KICAgICAgcGF0aCAoUkVTRVJW RUQpOiBIVFRQIHBhdGggZGF0YSwgdGhlIGRlZmF1bHQgdmFsdWUgaXMgIi8iLg0NCg0NCiAgICAg IHBvc3QgKFJFU0VSVkVEKTogSFRUUCBwb3N0IGRhdGEsIHRoZSBkZWZhdWx0IHZhbHVlIGlzICIi Lg0NCg0NCiAgICAgIHFzIChSRVNFUlZFRCk6IFRoZSBIVFRQIHF1ZXJ5IHN0cmluZywgdGhlIGRl ZmF1bHQgdmFsdWUgaXMgIiIuDQ0KDQ0KMy4yLiAgU2VydmVyJ3MgUmVzcG9uc2UNDQoNDQogICBU aGUgc2VydmVyIHZhbGlkYXRlcyB0aGUgcmVzcG9uc2UgYWNjb3JkaW5nIHRoZSBzcGVjaWZpY2F0 aW9uIGZvciB0aGUNDQogICBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZXMgdXNlZC4gIElmIHRoZSBP QXV0aCBBY2Nlc3MgVG9rZW4gVHlwZQ0NCiAgIHV0aWxpemVzIGEga2V5ZWQgbWVzc2FnZSBkaWdl c3Qgb2YgdGhlIHJlcXVlc3QgcGFyYW1ldGVycyB0aGVuIHRoZQ0NCiAgIGNsaWVudCBtdXN0IHBy b3ZpZGUgYSBjbGllbnQgcmVzcG9uc2UgdGhhdCBzYXRpc2ZpZXMgdGhlIGRhdGENDQogICByZXF1 aXJlbWVudHMgZm9yIHRoZSBzY2hlbWUgaW4gdXNlLg0NCg0NCg0NCk1pbGxzLCBTaG93YWx0ZXIg JiBUc2Nob2ZFeHBpcmVzIEFwcmlsIDI5LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0N CgwNDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgU0FTTCBPQXV0aCAgICAgICAgICAg ICAgICAgICBPY3RvYmVyIDIwMTQNDQoNDQoNDQogICBUaGUgc2VydmVyIHJlc3BvbmRzIHRvIGEg c3VjY2Vzc2Z1bGx5IHZlcmlmaWVkIGNsaWVudCBtZXNzYWdlIGJ5DQ0KICAgY29tcGxldGluZyB0 aGUgU0FTTCBuZWdvdGlhdGlvbi4gIFRoZSBhdXRoZW50aWNhdGVkIGlkZW50aXR5IHJlcG9ydGVk DQ0KICAgYnkgdGhlIFNBU0wgbWVjaGFuaXNtIGlzIHRoZSBpZGVudGl0eSBzZWN1cmVseSBlc3Rh Ymxpc2hlZCBmb3IgdGhlDQ0KICAgY2xpZW50IHdpdGggdGhlIE9BdXRoIGNyZWRlbnRpYWwuICBU aGUgYXBwbGljYXRpb24sIG5vdCB0aGUgU0FTTA0NCiAgIG1lY2hhbmlzbSwgYmFzZWQgb24gbG9j YWwgYWNjZXNzIHBvbGljeSBkZXRlcm1pbmVzIHdoZXRoZXIgdGhlDQ0KICAgaWRlbnRpdHkgcmVw b3J0ZWQgYnkgdGhlIG1lY2hhbmlzbSBpcyBhbGxvd2VkIGFjY2VzcyB0byB0aGUgcmVxdWVzdGVk DQ0KICAgcmVzb3VyY2UuICBOb3RlIHRoYXQgdGhlIHNlbWFudGljcyBvZiB0aGUgYXV0aHotaWQg aXMgc3BlY2lmaWVkIGJ5DQ0KICAgdGhlIFNBU0wgZnJhbWV3b3JrIFtSRkM0NDIyXS4NDQoNDQoz LjIuMS4gIE9BdXRoIElkZW50aWZpZXJzIGluIHRoZSBTQVNMIENvbnRleHQNDQoNDQogICBJbiB0 aGUgT0F1dGggZnJhbWV3b3JrIHRoZSBjbGllbnQgbWF5IGJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhl DQ0KICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZSByZXNvdXJjZSBvd25lciBpcyBhdXRo ZW50aWNhdGVkIHRvIHRoZQ0NCiAgIGF1dGhvcml6YXRpb24gc2VydmVyLiAgT0F1dGggYWNjZXNz IHRva2VucyBtYXkgY29udGFpbiBpbmZvcm1hdGlvbg0NCiAgIGFib3V0IHRoZSBhdXRoZW50aWNh dGlvbiBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIGFib3V0IHRoZSBjbGllbnQNDQogICBhbmQg bWF5IHRoZXJlZm9yZSBtYWtlIHRoaXMgaW5mb3JtYXRpb24gYWNjZXNzaWJsZSB0byB0aGUgcmVz b3VyY2UNDQogICBzZXJ2ZXIuDQ0KDQ0KICAgSWYgYm90aCBpZGVudGlmaWVycyBhcmUgbmVlZGVk IGJ5IGFuIGFwcGxpY2F0aW9uIHRoZSBkZXZlbG9wZXIgd2lsbA0NCiAgIG5lZWQgdG8gcHJvdmlk ZSBhIHdheSB0byBjb21tdW5pY2F0ZSB0aGF0IGZyb20gdGhlIFNBU0wgbWVjaGFuaXNtDQ0KICAg YmFjayB0byB0aGUgYXBwbGljYXRpb24uDQ0KDQ0KMy4yLjIuICBTZXJ2ZXIgUmVzcG9uc2UgdG8g RmFpbGVkIEF1dGhlbnRpY2F0aW9uDQ0KDQ0KICAgRm9yIGEgZmFpbGVkIGF1dGhlbnRpY2F0aW9u IHRoZSBzZXJ2ZXIgcmV0dXJucyBhIEpTT04gW1JGQzQ2MjddDQ0KICAgZm9ybWF0dGVkIGVycm9y IHJlc3VsdCwgYW5kIGZhaWxzIHRoZSBhdXRoZW50aWNhdGlvbi4gIFRoZSBlcnJvcg0NCiAgIHJl c3VsdCBjb25zaXN0cyBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczoNDQoNDQogICAgICANDQoNDQog ICAgICBzdGF0dXMgKFJFUVVJUkVEKTogVGhlIGF1dGhvcml6YXRpb24gZXJyb3IgY29kZS4gIFZh bGlkIGVycm9yDQ0KICAgICAgICAgY29kZXMgYXJlIGRlZmluZWQgaW4gdGhlIElBTkEgIk9BdXRo IEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnkiDQ0KICAgICAgICAgc3BlY2lmaWVkIGluIHRoZSBP QXV0aCAyIGNvcmUgc3BlY2lmaWNhdGlvbi4NDQoNDQogICAgICBzY29wZSAoT1BUSU9OQUwpOiBB biBPQXV0aCBzY29wZSB3aGljaCBpcyB2YWxpZCB0byBhY2Nlc3MgdGhlDQ0KICAgICAgICAgc2Vy dmljZS4gIFRoaXMgbWF5IGJlIGVtcHR5IHdoaWNoIGltcGxpZXMgdGhhdCB1bnNjb3BlZCB0b2tl bnMNDQogICAgICAgICBhcmUgcmVxdWlyZWQsIG9yIGEgc2NvcGUgdmFsdWUuICBJZiBhIHNjb3Bl IGlzIHNwZWNpZmllZCB0aGVuIGENDQogICAgICAgICBzaW5nbGUgc2NvcGUgaXMgcHJlZmVycmVk LCB1c2Ugb2YgYSBzcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZg0NCiAgICAgICAgIHNjb3BlcyBpcyBO T1QgUkVDT01NRU5ERUQuDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0K DQ0KDQ0KTWlsbHMsIFNob3dhbHRlciAmIFRzY2hvZkV4cGlyZXMgQXByaWwgMjksIDIwMTUgICAg ICAgICAgICAgICAgIFtQYWdlIDhdDQ0KDA0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICBTQVNMIE9BdXRoICAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNA0NCg0NCg0NCiAgICAg IG9hdXRoLWNvbmZpZ3VyYXRpb24gKE9QVElPTkFMKTogVGhlIFVSTCBmb3IgZm9yIGEgZG9jdW1l bnQNDQogICAgICAgICBmb2xsb3dpbmcgdGhlIE9wZW5JRCBQcm92aWRlciBDb25maWd1cmF0aW9u IEluZm9ybWF0aW9uIHNjaGVtYQ0NCiAgICAgICAgIGFzIGRlc2NyaWJlZCBpbiBPcGVuSUQgQ29u bmVjdCBEaXNjb3ZlcnkgW09wZW5JRC5EaXNjb3ZlcnldDQ0KICAgICAgICAgc2VjdGlvbiAzIHRo YXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSB1c2VyLiAgVGhpcyBkb2N1bWVudCBNVVNUDQ0KICAg ICAgICAgaGF2ZSBhbGwgT0F1dGggcmVsYXRlZCBkYXRhIGVsZW1lbnRzIHBvcHVsYXRlZC4gIFRo ZSBzZXJ2ZXIgTUFZDQ0KICAgICAgICAgcmV0dXJuIGRpZmZlcmVudCBVUkxzIGZvciB1c2VycyBp biBkaWZmZXJlbnQgZG9tYWlucyBhbmQgdGhlDQ0KICAgICAgICAgY2xpZW50IFNIT1VMRCBOT1Qg Y2FjaGUgYSBzaW5nbGUgcmV0dXJuZWQgdmFsdWUgYW5kIGFzc3VtZSBpdA0NCiAgICAgICAgIGFw cGxpZXMgZm9yIGFsbCB1c2Vycy9kb21haW5zIHRoYXQgdGhlIHNlcnZlciBzdXBvcnRzLiAgVGhl DQ0KICAgICAgICAgcmV0dXJuZWQgZGlzY292ZXJ5IGRvY3VtZW50IFNIT1VMRCBoYXZlIGFsbCBk YXRhIGVsZW1lbnRzDQ0KICAgICAgICAgcmVxdWlyZWQgYnkgdGhlIE9wZW5JRCBDb25uZWN0IERp c2NvdmVyeSBzcGVjaWZpY2F0aW9uDQ0KICAgICAgICAgcG9wdWxhdGVkLiAgSW4gYWRkaXRpb24s IHRoZSBkaXNjb3ZlcnkgZG9jdW1lbnQgU0hPVUxEIGNvbnRhaW4NDQogICAgICAgICB0aGUgJ3Jl Z2lzdHJhdGlvbl9lbmRwb2ludCcgZWxlbWVudCB0byBsZWFybiBhYm91dCB0aGUgZW5kcG9pbnQN DQogICAgICAgICB0byBiZSB1c2VkIHdpdGggdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlv biBwcm90b2NvbCBbSS1EDQ0KICAgICAgICAgLmlldGYtb2F1dGgtZHluLXJlZ10gdG8gb2J0YWlu IHRoZSBtaW5pbXVtIG51bWJlciBvZiBwYXJhbWV0ZXJzDQ0KICAgICAgICAgbmVjZXNzYXJ5IGZv ciB0aGUgT0F1dGggcHJvdG9jb2wgZXhjaGFuZ2UgdG8gZnVuY3Rpb24uICBBbm90aGVyDQ0KICAg ICAgICAgY29tcGFyYWJsZSBkaXNjb3Zlcnkgb3IgY2xpZW50IHJlZ2lzdHJhdGlvbiBtZWNoYW5p c20gTUFZIGJlDQ0KICAgICAgICAgdXNlZCBpZiBhdmFpbGFibGUuDQ0KDQ0KICAgICAgICAgVGhl IHVzZSBvZiB0aGUgJ29mZmxpbmVfYWNjZXNzJyBzY29wZSwgYXMgZGVmaW5lZCBpbg0NCiAgICAg ICAgIFtPcGVuSUQuQ29yZV0gaXMgUkVDT01NRU5ERUQgdG8gZ2l2ZSBjbGllbnRzIHRoZSBjYXBh YmlsaXR5IHRvDQ0KICAgICAgICAgZXhwbGljaXRseSByZXF1ZXN0IGEgcmVmcmVzaCB0b2tlbi4N DQoNDQogICBJZiB0aGUgcmVzb3VyY2Ugc2VydmVyIHByb3ZpZGVzIGEgc2NvcGUgdGhlbiB0aGUg Y2xpZW50IE1VU1QgYWx3YXlzDQ0KICAgcmVxdWVzdCBzY29wZWQgdG9rZW5zIGZyb20gdGhlIHRv a2VuIGVuZHBvaW50LiAgSWYgdGhlIHJlc291cmNlDQ0KICAgc2VydmVyIHByb3ZpZGVzIG5vIHNj b3BlIHRvIHRoZSBjbGllbnQgdGhlbiB0aGUgY2xpZW50IFNIT1VMRCBwcmVzdW1lDQ0KICAgYW4g ZW1wdHkgc2NvcGUgKHVuc2NvcGVkIHRva2VuKSBpcyByZXF1aXJlZCB0byBhY2Nlc3MgdGhlIHJl c291cmNlLg0NCg0NCiAgIFNpbmNlIGNsaWVudHMgbWF5IGludGVyYWN0IHdpdGggYSBudW1iZXIg b2YgYXBwbGljYXRpb24gc2VydmVycywgc3VjaA0NCiAgIGFzIGVtYWlsIHNlcnZlcnMgYW5kIFhN UFAgc2VydmVycywgdGhleSBuZWVkIHRvIGhhdmUgYSB3YXkgdG8NDQogICBkZXRlcm1pbmUgd2hl dGhlciBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gaGFzIGJlZW4gcGVyZm9ybWVkDQ0KICAg YWxyZWFkeSBhbmQgd2hldGhlciBhbiBhbHJlYWR5IGF2YWlsYWJsZSByZWZyZXNoIHRva2VuIGNh biBiZSByZS11c2VkDQ0KICAgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbiBmb3IgdGhlIGRlc2ly ZWQgcmVzb3VyY2Ugc2VydmVyLiAgVGhpcw0NCiAgIHNwZWNpZmljYXRpb24gUkVDT01NRU5EcyB0 aGF0IGEgY2xpZW50IHVzZXMgdGhlIGluZm9ybWF0aW9uIGluIHRoZQ0NCiAgICdpc3N1ZScgZWxl bWVudCB0byBtYWtlIHRoaXMgZGV0ZXJtaW5hdGlvbi4NDQoNDQozLjIuMy4gIENvbXBsZXRpbmcg YW4gRXJyb3IgTWVzc2FnZSBTZXF1ZW5jZQ0NCg0NCiAgIFNlY3Rpb24gMy42IG9mIFtSRkM0NDIy XSBleHBsaWNpdGx5IHByb2hpYml0cyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uDQ0KICAgaW4gYW4g dW5zdWNjZXNzZnVsIGF1dGhlbnRpY2F0aW9uIG91dGNvbWUuICBUaGVyZWZvcmUsIHRoZSBlcnJv cg0NCiAgIG1lc3NhZ2UgaXMgc2VudCBpbiBhIG5vcm1hbCBtZXNzYWdlLiAgVGhlIGNsaWVudCBN VVNUIHRoZW4gc2VuZCBhbg0NCiAgIGFkZGl0aW9uYWwgY2xpZW50IHJlc3BvbnNlIGNvbnNpc3Rp bmcgb2YgYSBzaW5nbGUgJXgwMSAoY29udHJvbCBBKQ0NCiAgIGNoYXJhY3RlciB0byB0aGUgc2Vy dmVyIGluIG9yZGVyIHRvIGFsbG93IHRoZSBzZXJ2ZXIgdG8gZmluaXNoIHRoZQ0NCiAgIGV4Y2hh bmdlLg0NCg0NCjMuMy4gIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlcyB1c2luZyBLZXllZCBNZXNz YWdlIERpZ2VzdHMNDQoNDQogICBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZXMgbWF5IHVzZSBrZXll ZCBtZXNzYWdlIGRpZ2VzdHMgYW5kIHRoZSBjbGllbnQNDQogICBhbmQgdGhlIHJlc291cmNlIHNl cnZlciBtYXkgbmVlZCB0byBwZXJmb3JtIGEgY3J5cHRvZ3JhcGhpYw0NCiAgIGNvbXB1dGF0aW9u IGZvciBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhbmQgZGF0YSBvcmlnaW4gYXV0aGVudGljYXRpb24u DQ0KDQ0KDQ0KDQ0KDQ0KDQ0KTWlsbHMsIFNob3dhbHRlciAmIFRzY2hvZkV4cGlyZXMgQXByaWwg MjksIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDldDQ0KDA0NCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICBTQVNMIE9BdXRoICAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNA0N Cg0NCg0NCiAgIE9BdXRoIGlzIGRlc2lnbmVkIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzIGlkZW50 aWZpZWQgYnkgVVJJcy4gIFNBU0wNDQogICBpcyBkZXNpZ25lZCBmb3IgdXNlciBhdXRoZW50aWNh dGlvbiwgYW5kIGhhcyBubyBmYWNpbGl0eSBmb3IgbW9yZQ0NCiAgIGZpbmUtZ3JhaW5lZCBhY2Nl c3MgY29udHJvbC4gIEluIHRoaXMgc3BlY2lmaWNhdGlvbiB3ZSByZXF1aXJlIG9yDQ0KICAgZGVm aW5lIGRlZmF1bHQgdmFsdWVzIGZvciB0aGUgZGF0YSBlbGVtZW50cyBmcm9tIGFuIEhUVFAgcmVx dWVzdA0NCiAgIHdoaWNoIGFsbG93IHRoZSBzaWduYXR1cmUgYmFzZSBzdHJpbmcgdG8gYmUgY29u c3RydWN0ZWQgcHJvcGVybHkuDQ0KICAgVGhlIGRlZmF1bHQgSFRUUCBwYXRoIGlzICIvIiBhbmQg dGhlIGRlZmF1bHQgcG9zdCBib2R5IGlzIGVtcHR5Lg0NCiAgIFRoZXNlIGF0b21zIGFyZSBkZWZp bmVkIGFzIGV4dGVuc2lvbiBwb2ludHMgc28gdGhhdCBubyBjaGFuZ2VzIGFyZQ0NCiAgIG5lZWRl ZCBpZiB0aGVyZSBpcyBhIHJldmlzaW9uIG9mIFNBU0wgd2hpY2ggc3VwcG9ydHMgbW9yZSBzcGVj aWZpYw0NCiAgIHJlc291cmNlIGF1dGhvcml6YXRpb24sIGUuZy4sIElNQVAgYWNjZXNzIHRvIGEg c3BlY2lmaWMgZm9sZGVyIG9yIEZUUA0NCiAgIGFjY2VzcyBsaW1pdGVkIHRvIGEgc3BlY2lmaWMg ZGlyZWN0b3J5Lg0NCg0NCiAgIFVzaW5nIHRoZSBleGFtcGxlIGluIHRoZSBPQXV0aCAxLjBhIHNw ZWNpZmljYXRpb24gYXMgYSBzdGFydGluZw0NCiAgIHBvaW50LCBvbiBhbiBJTUFQIHNlcnZlciBy dW5uaW5nIG9uIHBvcnQgMTQzIGFuZCBnaXZlbiB0aGUgT0F1dGggMS4wYQ0NCiAgIHN0eWxlIGF1 dGhvcml6YXRpb24gcmVxdWVzdCAod2l0aCAleDAxIHNob3duIGFzIF5BIGFuZCBsaW5lIGJyZWFr cw0NCiAgIGFkZGVkIGZvciByZWFkYWJpbGl0eSkgYmVsb3c6DQ0KDQ0KICAgbixhPXVzZXJAZXhh bXBsZS5jb20sXkENDQogICBob3N0PWV4YW1wbGUuY29tXkENDQogICBwb3J0PTE0M15BDQ0KICAg YXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsDQ0KICAgICAgICAgICAgICBvYXV0aF9jb25zdW1l cl9rZXk9IjlkamRqODJoNDhkanM5ZDIiLA0NCiAgICAgICAgICAgICAgb2F1dGhfdG9rZW49Imtr azlkN2RoM2szOXNqdjciLA0NCiAgICAgICAgICAgICAgb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0i SE1BQy1TSEExIiwNDQogICAgICAgICAgICAgIG9hdXRoX3RpbWVzdGFtcD0iMTM3MTMxMjAxIiwN DQogICAgICAgICAgICAgIG9hdXRoX25vbmNlPSI3ZDhmM2U0YSIsDQ0KICAgICAgICAgICAgICBv YXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1WVhSMWNtVSJeQV5BDQ0KDQ0KICAg VGhlIHNpZ25hdHVyZSBiYXNlIHN0cmluZyB3b3VsZCBiZSBjb25zdHJ1Y3RlZCBwZXIgdGhlIE9B dXRoIDEuMA0NCiAgIHNwZWNpZmljYXRpb24gW1JGQzU4NDldIHdpdGggdGhlIGZvbGxvd2luZyB0 aGluZ3Mgbm90ZWQ6DQ0KDQ0KICAgbyAgVGhlIG1ldGhvZCB2YWx1ZSBpcyBkZWZhdWx0ZWQgdG8g UE9TVC4NDQoNDQogICBvICBUaGUgc2NoZW1lIGRlZmF1bHRzIHRvIGJlICJodHRwIiwgYW5kIGFu eSBwb3J0IG51bWJlciBvdGhlciB0aGFuDQ0KICAgICAgODAgaXMgaW5jbHVkZWQuDQ0KDQ0KICAg byAgVGhlIHBhdGggZGVmYXVsdHMgdG8gIi8iLg0NCg0NCiAgIG8gIFRoZSBxdWVyeSBzdHJpbmcg ZGVmYXVsdHMgdG8gIiIuDQ0KDQ0KICAgSW4gdGhpcyBleGFtcGxlIHRoZSBzaWduYXR1cmUgYmFz ZSBzdHJpbmcgd2l0aCBsaW5lIGJyZWFrcyBhZGRlZCBmb3INDQogICByZWFkYWJpbGl0eSB3b3Vs ZCBiZToNDQoNDQogICBQT1NUJmh0dHAlM0ElMkYlMkZleGFtcGxlLmNvbToxNDMlMkYmb2F1dGhf Y29uc3VtZXJfa2V5JTNEOWRqZGo4Mmg0DQ0KICAgOGRqczlkMiUyNm9hdXRoX25vbmNlJTNEN2Q4 ZjNlNGElMjZvYXV0aF9zaWduYXR1cmVfbWV0aG9kJTNESE1BQy1TSA0NCiAgIEExJTI2b2F1dGhf dGltZXN0YW1wJTNEMTM3MTMxMjAxJTI2b2F1dGhfdG9rZW4lM0Rra2s5ZDdkaDNrMzlzanY3DQ0K DQ0KNC4gIEV4YW1wbGVzDQ0KDQ0KICAgVGhlc2UgZXhhbXBsZXMgaWxsdXN0cmF0ZSBleGNoYW5n ZXMgYmV0d2VlbiBJTUFQIGFuZCBTTVRQIGNsaWVudHMgYW5kDQ0KICAgc2VydmVycy4NDQoNDQoN DQoNDQoNDQpNaWxscywgU2hvd2FsdGVyICYgVHNjaG9mRXhwaXJlcyBBcHJpbCAyOSwgMjAxNSAg ICAgICAgICAgICAgICBbUGFnZSAxMF0NDQoMDQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgIFNBU0wgT0F1dGggICAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDE0DQ0KDQ0KDQ0KICAg Tm90ZSB0byBpbXBsZW1lbnRlcnM6ICBUaGUgU0FTTCBPQXV0aCBtZXRob2QgbmFtZXMgYXJlIGNh c2UNDQogICBpbnNlbnNpdGl2ZS4gIE9uZSBleGFtcGxlIHVzZXMgIkJlYXJlciIgYnV0IHRoYXQg Y291bGQgYXMgZWFzaWx5IGJlDQ0KICAgImJlYXJlciIsICJCRUFSRVIiLCBvciAiQmVBckVyIi4N DQoNDQo0LjEuICBTdWNjZXNzZnVsIEJlYXJlciBUb2tlbiBFeGNoYW5nZQ0NCg0NCiAgIFRoaXMg ZXhhbXBsZSBzaG93cyBhIHN1Y2Nlc3NmdWwgT0F1dGggMi4wIGJlYXJlciB0b2tlbiBleGNoYW5n ZSBpbg0NCiAgIElNQVAuIE5vdGUgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5zZXJ0ZWQgZm9yIHJl YWRhYmlsaXR5IGFuZCB0aGUNDQogICB1bmRlcmx5aW5nIFRMUyBlc3RhYmxpc2htZW50IGlzIG5v dCBzaG93biBlaXRoZXIuDQ0KDQ0KICAgUzogKiBPSyBJTUFQNHJldjEgU2VydmVyIFJlYWR5DQ0K ICAgQzogdDAgQ0FQQUJJTElUWQ0NCiAgIFM6ICogQ0FQQUJJTElUWSBJTUFQNHJldjEgQVVUSD1P QVVUSEJFQVJFUiBTQVNMLUlSDQ0KICAgUzogdDAgT0sgQ29tcGxldGVkDQ0KICAgQzogdDEgQVVU SEVOVElDQVRFIE9BVVRIQkVBUkVSIGJpeGhQWFZ6WlhKQVpYaGhiWEJzWlM1amIyMHNBV2h2YzNR OWMyDQ0KICAgICAgICAgVnlkbVZ5TG1WNFlXMXdiR1V1WTI5dEFYQnZjblE5TVRRekFXRjFkR2c5 UW1WaGNtVnlJSFpHT1dSbWREUnhiDQ0KICAgICAgICAgVlJqTWs1MllqTlNiR05yUW1oaVNGSm9a RzFzZW1SSFJYVlpNamwwUTJjOVBRRUINDQogICBTOiB0MSBPSyBTQVNMIGF1dGhlbnRpY2F0aW9u IHN1Y2NlZWRlZA0NCg0NCiAgIEFzIHJlcXVpcmVkIGJ5IElNQVAgW1JGQzM1MDFdLCB0aGUgcGF5 bG9hZHMgYXJlIGJhc2U2NC1lbmNvZGVkLiAgVGhlDQ0KICAgZGVjb2RlZCBpbml0aWFsIGNsaWVu dCByZXNwb25zZSAod2l0aCAleDAxIHJlcHJlc2VudGVkIGFzIF5BIGFuZCBsb25nDQ0KICAgbGlu ZXMgd3JhcHBlZCBmb3IgcmVhZGFiaWxpdHkpIGlzOg0NCg0NCiAgIG4sYT11c2VyQGV4YW1wbGUu Y29tLF5BaG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb21eQXBvcnQ9MTQzXkENDQogICBhdXRoPUJlYXJl ciB2RjlkZnQ0cW1UYzJOdmIzUmxja0JoYkhSaGRtbHpkR0V1WTI5dENnPT1eQV5BDQ0KDQ0KICAg VGhlIHNhbWUgY3JlZGVudGlhbCB1c2VkIGluIGFuIFNNVFAgZXhjaGFuZ2UgaXMgc2hvd24gYmVs b3cuICBOb3RlDQ0KICAgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5zZXJ0ZWQgZm9yIHJlYWRhYmls aXR5LCBhbmQgdGhhdCB0aGUgU01UUA0NCiAgIHByb3RvY29sIHRlcm1pbmF0ZXMgbGluZXMgd2l0 aCBDUiBhbmQgTEYgY2hhcmFjdGVycyAoQVNDSUkgdmFsdWVzDQ0KICAgMHgwRCBhbmQgMHgwQSks IHRoZXNlIGFyZSBub3QgZGlzcGxheWVkIGV4cGxpY2l0bHkgaW4gdGhlIGV4YW1wbGUuDQ0KDQ0K ICAgW2Nvbm5lY3Rpb24gYmVnaW5zXQ0NCiAgIFM6IDIyMCBteC5leGFtcGxlLmNvbSBFU01UUCAx MnNtMjA5NTYwM2Zrcy45DQ0KICAgQzogRUhMTyBzZW5kZXIuZXhhbXBsZS5jb20NDQogICBTOiAy NTAtbXguZXhhbXBsZS5jb20gYXQgeW91ciBzZXJ2aWNlLFsxNzIuMzEuMTM1LjQ3XQ0NCiAgIFM6 IDI1MC1TSVpFIDM1NjUxNTg0DQ0KICAgUzogMjUwLThCSVRNSU1FDQ0KICAgUzogMjUwLUFVVEgg TE9HSU4gUExBSU4gT0FVVEhCRUFSRVINDQogICBTOiAyNTAtRU5IQU5DRURTVEFUVVNDT0RFUw0N CiAgIFM6IDI1MCBQSVBFTElOSU5HDQ0KICAgQzogdDEgQVVUSEVOVElDQVRFIE9BVVRIQkVBUkVS IGJpeGhQWFZ6WlhKQVpYaGhiWEJzWlM1amIyMHNBV2h2YzNROWMNDQogICAgICAgICAyVnlkbVZ5 TG1WNFlXMXdiR1V1WTI5dEFYQnZjblE5TVRRekFXRjFkR2c5UW1WaGNtVnlJSFpHT1dSbWREUg0N CiAgICAgICAgIHhiVlJqTWs1MllqTlNiR05yUW1oaVNGSm9aRzFzZW1SSFJYVlpNamwwUTJjOVBR RUINDQogICBTOiAyMzUgQXV0aGVudGljYXRpb24gc3VjY2Vzc2Z1bC4NDQogICBbY29ubmVjdGlv biBjb250aW51ZXMuLi5dDQ0KDQ0KNC4yLiAgU3VjY2Vzc2Z1bCBPQXV0aCAxLjBhIFRva2VuIEV4 Y2hhbmdlDQ0KDQ0KICAgVGhpcyBJTUFQIGV4YW1wbGUgc2hvd3MgYSBzdWNjZXNzZnVsIE9BdXRo IDEuMGEgdG9rZW4gZXhjaGFuZ2UuICBOb3RlDQ0KICAgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5z ZXJ0ZWQgZm9yIHJlYWRhYmlsaXR5IGFuZCB0aGUgdW5kZXJseWluZyBUTFMNDQogICBlc3RhYmxp c2htZW50IGlzIG5vdCBzaG93bi4gIFNpZ25hdHVyZSBjb21wdXRhdGlvbiBpcyBkaXNjdXNzZWQg aW4NDQogICBTZWN0aW9uIDMuMy4NDQoNDQoNDQpNaWxscywgU2hvd2FsdGVyICYgVHNjaG9mRXhw aXJlcyBBcHJpbCAyOSwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAxMV0NDQoMDQ0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgIFNBU0wgT0F1dGggICAgICAgICAgICAgICAgICAgT2N0 b2JlciAyMDE0DQ0KDQ0KDQ0KICAgUzogKiBPSyBJTUFQNHJldjEgU2VydmVyIFJlYWR5DQ0KICAg QzogdDAgQ0FQQUJJTElUWQ0NCiAgIFM6ICogQ0FQQUJJTElUWSBJTUFQNHJldjEgQVVUSD1PQVVU SEJFQVJFUiBPQVVUSDEwQSBTQVNMLUlSDQ0KICAgUzogdDAgT0sgQ29tcGxldGVkDQ0KICAgQzog dDEgQVVUSEVOVElDQVRFIE9BVVRIMTBBIGJpeGhQWFZ6WlhKQVpYaGhiWEJzWlM1amIyMHNBV2h2 YzNROVpYaGhiDQ0KICAgICAgICAgWEJzWlM1amIyMEJjRzl5ZEQweE5ETUJZWFYwYUQxUFFYVjBh Q0J5WldGc2JUMGlSWGhoYlhCc1pTSXNiMkYxDQ0KICAgICAgICAgZEdoZlkyOXVjM1Z0WlhKZmEy VjVQU0k1Wkdwa2FqZ3lhRFE0Wkdwek9XUXlJaXh2WVhWMGFGOTBiMnRsYmowDQ0KICAgICAgICAg aWEydHJPV1EzWkdnemF6TTVjMnAyTnlJc2IyRjFkR2hmYzJsbmJtRjBkWEpsWDIxbGRHaHZaRDBp U0UxQlF5DQ0KICAgICAgICAgMVRTRUV4SWl4dllYVjBhRjkwYVcxbGMzUmhiWEE5SWpFek56RXpN VEl3TVNJc2IyRjFkR2hmYm05dVkyVTlJDQ0KICAgICAgICAgamRrT0dZelpUUmhJaXh2WVhWMGFG OXphV2R1WVhSMWNtVTlJbFJ0T1RCSlIwVm5ZMjFXYUdKRFFucGhWMlIxDQ0KICAgICAgICAgV1Zo U01XTnRWU1V6UkNJQkFRPT0NDQogICBTOiB0MSBPSyBTQVNMIGF1dGhlbnRpY2F0aW9uIHN1Y2Nl ZWRlZA0NCg0NCiAgIEFzIHJlcXVpcmVkIGJ5IElNQVAgW1JGQzM1MDFdLCB0aGUgcGF5bG9hZHMg YXJlIGJhc2U2NC1lbmNvZGVkLiAgVGhlDQ0KICAgZGVjb2RlZCBpbml0aWFsIGNsaWVudCByZXNw b25zZSAod2l0aCAleDAxIHJlcHJlc2VudGVkIGFzIF5BIGFuZA0NCiAgIGxpbmVzIHdyYXBwZWQg Zm9yIHJlYWRhYmlsaXR5KSBpczoNDQoNDQogICBuLGE9dXNlckBleGFtcGxlLmNvbSxeQQ0NCiAg IGhvc3Q9ZXhhbXBsZS5jb21eQQ0NCiAgIHBvcnQ9MTQzXkENDQogICBhdXRoPU9BdXRoIHJlYWxt PSJFeGFtcGxlIiwNDQogICAgICAgICAgICAgIG9hdXRoX2NvbnN1bWVyX2tleT0iOWRqZGo4Mmg0 OGRqczlkMiIsDQ0KICAgICAgICAgICAgICBvYXV0aF90b2tlbj0ia2trOWQ3ZGgzazM5c2p2NyIs DQ0KICAgICAgICAgICAgICBvYXV0aF9zaWduYXR1cmVfbWV0aG9kPSJITUFDLVNIQTEiLA0NCiAg ICAgICAgICAgICAgb2F1dGhfdGltZXN0YW1wPSIxMzcxMzEyMDEiLA0NCiAgICAgICAgICAgICAg b2F1dGhfbm9uY2U9IjdkOGYzZTRhIiwNDQogICAgICAgICAgICAgIG9hdXRoX3NpZ25hdHVyZT0i U1NkdElHRWdiR2wwZEd4bElIUmxZU0J3YjNRdSJeQV5BDQ0KDQ0KNC4zLiAgRmFpbGVkIEV4Y2hh bmdlDQ0KDQ0KICAgVGhpcyBJTUFQIGV4YW1wbGUgc2hvd3MgYSBmYWlsZWQgZXhjaGFuZ2UgYmVj YXVzZSBvZiB0aGUgZW1wdHkNDQogICBBdXRob3JpemF0aW9uIGhlYWRlciwgd2hpY2ggaXMgaG93 IGEgY2xpZW50IGNhbiBxdWVyeSBmb3IgdGhlIG5lZWRlZA0NCiAgIHNjb3BlLiAgTm90ZSB0aGF0 IGxpbmUgYnJlYWtzIGFyZSBpbnNlcnRlZCBmb3IgcmVhZGFiaWxpdHkuDQ0KDQ0KICAgUzogKiBP SyBJTUFQNHJldjEgU2VydmVyIFJlYWR5DQ0KICAgQzogdDAgQ0FQQUJJTElUWQ0NCiAgIFM6ICog Q0FQQUJJTElUWSBJTUFQNHJldjEgQVVUSD1PQVVUSEJFQVJFUiBTQVNMLUlSIElNQVA0cmV2MSBT ZXJ2ZXINDQogICAgICAgIFJlYWR5DQ0KICAgUzogdDAgT0sgQ29tcGxldGVkDQ0KICAgQzogdDEg QVVUSEVOVElDQVRFIE9BVVRIQkVBUkVSIGJpeGhQWFZ6WlhKQVpYaGhiWEJzWlM1amIyMHNBVw0N CiAgICAgICAgIGh2YzNROWMyVnlkbVZ5TG1WNFlXMXdiR1V1WTI5dEFYQnZjblE5TVRRekFXRjFk R2c5QVFFPQ0NCiAgIFM6ICsgZXlKemRHRjBkWE1pT2lKcGJuWmhiR2xrWDNSdmEyVnVJaXdpYzJO dmNHVWlPaUpsZUdGdGNHeGwNDQogICAgICAgIFgzTmpiM0JsSWl3aWIzQmxibWxrTFdOdmJtWnBa M1Z5WVhScGIyNGlPaUpvZEhSd2N6b3ZMMlY0DQ0KICAgICAgICBZVzF3YkdVdVkyOXRMeTUzWld4 c0xXdHViM2R1TDI5d1pXNXBaQzFqYjI1bWFXZDFjbUYwYVc5dQ0NCiAgICAgICAgSW4wPQ0NCiAg IEM6ICsgQVE9PQ0NCiAgIFM6IHQxIE5PIFNBU0wgYXV0aGVudGljYXRpb24gZmFpbGVkDQ0KDQ0K ICAgVGhlIGRlY29kZWQgaW5pdGlhbCBjbGllbnQgcmVzcG9uc2UgaXM6DQ0KDQ0KICAgbixhPXVz ZXJAZXhhbXBsZS5jb20sXkFob3N0PXNlcnZlci5leGFtcGxlLmNvbV5BDQ0KICAgcG9ydD0xNDNe QWF1dGg9XkFeQQ0NCg0NCg0NCk1pbGxzLCBTaG93YWx0ZXIgJiBUc2Nob2ZFeHBpcmVzIEFwcmls IDI5LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0NCgwNDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgU0FTTCBPQXV0aCAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTQN DQoNDQoNDQogICBUaGUgZGVjb2RlZCBzZXJ2ZXIgZXJyb3IgcmVzcG9uc2UgaXM6DQ0KDQ0KICAg ew0NCiAgICJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwNDQogICAic2NvcGUiOiJleGFtcGxlX3Nj b3BlIiwNDQogICAib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4YW1wbGUuY29tLy53 ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uIg0NCiAgIH0NDQoNDQogICBUaGUgY2xpZW50 IHJlc3BvbmRzIHdpdGggdGhlIHJlcXVpcmVkIGR1bW15IHJlc3BvbnNlLCAiQVE9PSIgaXMgdGhl DQ0KICAgYmFzZTY0IGVuY29kaW5nIG9mIHRoZSBBU0NJSSB2YWx1ZSAweDAxLg0NCg0NCjQuNC4g IFNNVFAgRXhhbXBsZSBvZiBhIEZhaWxlZCBOZWdvdGlhdGlvbg0NCg0NCiAgIFRoaXMgZXhhbXBs ZSBzaG93cyBhbiBhdXRob3JpemF0aW9uIGZhaWx1cmUgaW4gYW4gU01UUCBleGNoYW5nZS4NDQog ICBOb3RlIHRoYXQgbGluZSBicmVha3MgYXJlIGluc2VydGVkIGZvciByZWFkYWJpbGl0eSwgYW5k IHRoYXQgdGhlIFNNVFANDQogICBwcm90b2NvbCB0ZXJtaW5hdGVzIGxpbmVzIHdpdGggQ1IgYW5k IExGIGNoYXJhY3RlcnMgKEFTQ0lJIHZhbHVlcw0NCiAgIDB4MEQgYW5kIDB4MEEpLCB0aGVzZSBh cmUgbm90IGRpc3BsYXllZCBleHBsaWNpdGx5IGluIHRoZSBleGFtcGxlLg0NCg0NCiAgIFtjb25u ZWN0aW9uIGJlZ2luc10NDQogICBTOiAyMjAgbXguZXhhbXBsZS5jb20gRVNNVFAgMTJzbTIwOTU2 MDNma3MuOQ0NCiAgIEM6IEVITE8gc2VuZGVyLmV4YW1wbGUuY29tDQ0KICAgUzogMjUwLW14LmV4 YW1wbGUuY29tIGF0IHlvdXIgc2VydmljZSxbMTcyLjMxLjEzNS40N10NDQogICBTOiAyNTAtU0la RSAzNTY1MTU4NA0NCiAgIFM6IDI1MC04QklUTUlNRQ0NCiAgIFM6IDI1MC1BVVRIIExPR0lOIFBM QUlOIE9BVVRIQkVBUkVSDQ0KICAgUzogMjUwLUVOSEFOQ0VEU1RBVFVTQ09ERVMNDQogICBTOiAy NTAgUElQRUxJTklORw0NCiAgIEM6IEFVVEggT0FVVEhCRUFSRVIgYml4MWMyVnlQWE52YldWMWMy VnlRR1Y0WVcxd2JHVXVZMjl0TEFGaGRYUm9QVUpsWVhKbA0NCiAgICAgICAgICBjaUIyUmpsa1pu UTBjVzFVWXpKT2RtSXpVbXhqYTBKb1pFaFNhR1J0Ykhwa1IwVjFXVEk1ZEVOblBUMEJBUT09DQ0K ICAgUzogMzM0IGV5SnpkR0YwZFhNaU9pSTBNREVpTENKelkyaGxiV1Z6SWpvaVltVmhjbVZ5SUcx aFl5SXNJbk5qYjNCbElqb2lhDQ0KICAgICAgICAgIEhSMGNITTZMeTl0WVdsc0xtZHZiMmRzWlM1 amIyMHZJbjBLDQ0KICAgQzogQVE9PQ0NCiAgIFM6IDUzNS01LjcuMSBVc2VybmFtZSBhbmQgUGFz c3dvcmQgbm90IGFjY2VwdGVkLiBMZWFybiBtb3JlIGF0DQ0KICAgUzogNTM1IDUuNy4xIGh0dHA6 Ly9zdXBwb3J0LmV4YW1wbGUuY29tL21haWwvb2F1dGgNDQogICBbY29ubmVjdGlvbiBjb250aW51 ZXMuLi5dDQ0KDQ0KICAgVGhlIHNlcnZlciByZXR1cm5lZCBhbiBlcnJvciBtZXNzYWdlIGluIHRo ZSAzMzQgU0FTTCBtZXNzYWdlLCB0aGUNDQogICBjbGllbnQgcmVzcG9uZHMgd2l0aCB0aGUgcmVx dWlyZWQgZHVtbXkgcmVzcG9uc2UsIGFuZCB0aGUgc2VydmVyDQ0KICAgZmluYWxpemVzIHRoZSBu ZWdvdGlhdGlvbi4NDQoNDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNDQoNDQogICBPQXV0 aCAxLjBhIGFuZCBPQXV0aCAyIGFsbG93cyBmb3IgYSB2YXJpZXR5IG9mIGRlcGxveW1lbnQgc2Nl bmFyaW9zLA0NCiAgIGFuZCB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiB0aGVzZSBwcm9maWxl cyB2YXJ5LiAgQXMgc2hvd24gaW4NDQogICBGaWd1cmUgMSB0aGlzIHNwZWNpZmljYXRpb24gaXMg YWltZWQgdG8gYmUgaW50ZWdyYXRlZCBpbnRvIGEgbGFyZ2VyDQ0KICAgT0F1dGggZGVwbG95bWVu dC4gIEFwcGxpY2F0aW9uIGRldmVsb3BlcnMgdGhlcmVmb3JlIG5lZWQgdG8NDQogICB1bmRlcnN0 YW5kIHRoZSBuZWVkcyBvZiB0aGVpciBzZWN1cml0eSByZXF1aXJlbWVudHMgYmFzZWQgb24gYSB0 aHJlYXQNDQogICBhc3Nlc3NtZW50IGJlZm9yZSBzZWxlY3RpbmcgYSBzcGVjaWZpYyBTQVNMIE9B dXRoIG1lY2hhbmlzbS4gIEZvcg0NCiAgIE9BdXRoIDIuMCBhIGRldGFpbGVkIHNlY3VyaXR5IGRv Y3VtZW50IFtSRkM2ODE5XSBwcm92aWRlcyBndWlkYW5jZSB0bw0NCiAgIHNlbGVjdCB0aG9zZSBP QXV0aCAyLjAgY29tcG9uZW50cyB0aGF0IGhlbHAgdG8gbWl0aWdhdGUgdGhyZWF0cyBmb3IgYQ0N CiAgIGdpdmVuIGRlcGxveW1lbnQuICBGb3IgT0F1dGggMS4wYSBTZWN0aW9uIDQgb2YgUkZDIDU4 NDkgW1JGQzU4NDldDQ0KDQ0KDQ0KDQ0KTWlsbHMsIFNob3dhbHRlciAmIFRzY2hvZkV4cGlyZXMg QXByaWwgMjksIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQ0KDA0NCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICBTQVNMIE9BdXRoICAgICAgICAgICAgICAgICAgIE9jdG9iZXIg MjAxNA0NCg0NCiAgIHByb3ZpZGVzIGd1aWRhbmNlIHNwZWNpZmljIHRvIE9BdXRoIDEuMC4NDQoN DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0d28gU0FTTCAgTWVjaGFuaXNtcyBmb3IgT0F1 dGggYW5kIGVhY2ggY29tZXMNDQogICB3aXRoIGRpZmZlcmVudCBzZWN1cml0eSBwcm9wZXJ0aWVz Lg0NCg0NCiAgIE9BVVRIQkVBUkVSOiBUaGlzIG1lY2hhbmlzbSBib3Jyb3dzIGZyb20gT0F1dGgg Mi4wIGJlYXJlciB0b2tlbnMNDQogICAgICBbUkZDNjc1MF0uICBJdCByZWxpZXMgb24gdGhlIGFw cGxpY2F0aW9uIHVzaW5nIFRMUyB0byBwcm90ZWN0IHRoZQ0NCiAgICAgIE9BdXRoIDIuMCBCZWFy ZXIgVG9rZW4gZXhjaGFuZ2U7IHdpdGhvdXQgVExTIHVzYWdlIGF0IHRoZQ0NCiAgICAgIGFwcGxp Y2F0aW9uIGxheWVyIHRoaXMgbWV0aG9kIGlzIGNvbXBsZXRlbHkgaW5zZWN1cmUuDQ0KICAgICAg Q29uc2VxdWVudGx5LCBUTFMgTVVTVCBiZSBwcm92aWRlZCBieSB0aGUgYXBwbGljYXRpb24gd2hl bg0NCiAgICAgIGNob29zaW5nIHRoaXMgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLg0NCg0NCiAg IE9BVVRIMTBBOiBUaGlzIG1lY2hhbmlzbSByZS11c2VzIE9BdXRoIDEuMGEgTUFDIHRva2VucyAo dXNpbmcgdGhlDQ0KICAgICAgSE1BQy1TSEExIGtleWVkIG1lc3NhZ2UgZGlnZXN0KSwgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gMy40LjIgb2YNDQogICAgICBbUkZDNTg0OV0uICBUbyBjb21wdXRl IHRoZSBrZXllZCBtZXNzYWdlIGRpZ2VzdCBpbiB0aGUgc2FtZSB3YXkNDQogICAgICB3YXMgaW4g UkZDIDU4MzkgdGhpcyBzcGVjaWZpY2F0aW9uIGNvbnZleXMgYWRkaXRpb25hbCBwYXJhbWV0ZXJz DQ0KICAgICAgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyLiAgVGhpcyBTQVNMIG1l Y2hhbmlzbSBvbmx5DQ0KICAgICAgc3VwcG9ydHMgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiAgSWYg c2VydmVyLXNpZGUgYXV0aGVudGljYXRpb24gaXMNDQogICAgICBkZXNpcmVhYmxlIHRoZW4gaXQg bXVzdCBiZSBwcm92aWRlZCBieSB0aGUgYXBwbGljYXRpb24gdW5kZXJuZWF0aA0NCiAgICAgIHRo ZSBTQVNMIGxheWVyLiAgVGhlIHVzZSBvZiBUTFMgaXMgc3Ryb25nbHkgUkVDT01NRU5ERUQuDQ0K DQ0KICAgQWRkaXRpb25hbGx5LCB0aGUgZm9sbG93aW5nIGFzcGVjdHMgYXJlIHdvcnRoIHBvaW50 aW5nIG91dDoNDQoNDQogICBBbiBhY2Nlc3MgdG9rZW4gaXMgbm90IGVxdWl2YWxlbnQgdG8gdGhl IHVzZXIncyBsb25nIHRlcm0gcGFzc3dvcmQuIA0NCg0NCiAgICAgIENhcmUgaGFzIHRvIGJlIHRh a2VuIHdoZW4gdGhlc2UgT0F1dGggY3JlZGVudGlhbHMgYXJlIHVzZWQgZm9yDQ0KICAgICAgYWN0 aW9ucyBsaWtlIGNoYW5naW5nIHBhc3N3b3JkcyAoYXMgaXQgaXMgcG9zc2libGUgd2l0aCBzb21l DQ0KICAgICAgcHJvdG9jb2xzLCBlLmcuLCBYTVBQIFtSRkM2MTIwXSkuIFRoZSByZXNvdXJjZSBz ZXJ2ZXIgc2hvdWxkDQ0KICAgICAgZW5zdXJlIHRoYXQgYWN0aW9ucyB0YWtlbiBpbiB0aGUgYXV0 aGVudGljYXRlZCBjaGFubmVsIGFyZQ0NCiAgICAgIGFwcHJvcHJpYXRlIHRvIHRoZSBzdHJlbmd0 aCBvZiB0aGUgcHJlc2VudGVkIGNyZWRlbnRpYWwuDQ0KDQ0KICAgTGlmZXRpbWUgb2YgdGhlIGFw cGxpYXRpb24gc2Vzc2lvbnMuIA0NCg0NCiAgICAgIEl0IGlzIHBvc3NpYmxlIHRoYXQgU0FTTCB3 aWxsIGJlIGF1dGhlbnRpY2F0aW5nIGEgY29ubmVjdGlvbiBhbmQNDQogICAgICB0aGUgbGlmZSBv ZiB0aGF0IGNvbm5lY3Rpb24gbWF5IG91dGxhc3QgdGhlIGxpZmUgb2YgdGhlIGFjY2Vzcw0NCiAg ICAgIHRva2VuIHVzZWQgdG8gZXN0YWJsaXNoIGl0LiAgVGhpcyBpcyBhIGNvbW1vbiBwcm9ibGVt IGluDQ0KICAgICAgYXBwbGljYXRpb24gcHJvdG9jb2xzIHdoZXJlIGNvbm5lY3Rpb25zIGFyZSBs b25nLWxpdmVkLCBhbmQgbm90IGENDQogICAgICBwcm9ibGVtIHdpdGggdGhpcyBtZWNoYW5pc20g cGVyIHNlLiAgUmVzb3VyY2Ugc2VydmVycyBtYXkNDQogICAgICB1bmlsYXRlcmFsbHkgZGlzY29u bmVjdCBjbGllbnRzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgYXBwbGljYXRpb24NDQogICAgICBw cm90b2NvbC4NDQoNDQogICBBY2Nlc3MgdG9rZW5zIGhhdmUgYSBsaWZldGltZS4gDQ0KDQ0KICAg ICAgUmVkdWNpbmcgdGhlIGxpZmV0aW1lIG9mIGFuIGFjY2VzcyB0b2tlbiBwcm92aWRlcyBzZWN1 cml0eQ0NCiAgICAgIGJlbmVmaXRzIGFuZCBPQXV0aCAyLjAgaW50cm9kdWNlcyByZWZyZXNoIHRv a2VucyB0byBvYnRhaW4gbmV3DQ0KICAgICAgYWNjZXNzIHRva2VuIG9uIHRoZSBmbHkgd2l0aG91 dCBhbnkgbmVlZCBmb3IgYSBodW1hbiBpbnRlcmFjdGlvbi4NDQogICAgICBBZGRpdGlvbmFsbHks IGEgcHJldmlvdXNseSBvYnRhaW5lZCBhY2Nlc3MgdG9rZW4gbWlnaHQgYmUgcmV2b2tlZA0NCiAg ICAgIG9yIHJlbmRlcmVkIGludmFsaWQgYXQgYW55IHRpbWUuICBUaGUgY2xpZW50IE1BWSByZXF1 ZXN0IGEgbmV3DQ0KICAgICAgYWNjZXNzIHRva2VuIGZvciBlYWNoIGNvbm5lY3Rpb24gdG8gYSBy ZXNvdXJjZSBzZXJ2ZXIsIGJ1dCBpdA0NCiAgICAgIFNIT1VMRCBjYWNoZSBhbmQgcmUtdXNlIHZh bGlkIGNyZWRlbnRpYWxzLg0NCg0NCjYuICBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb25zaWRlcmF0 aW9ucw0NCg0NCg0NCg0NCk1pbGxzLCBTaG93YWx0ZXIgJiBUc2Nob2ZFeHBpcmVzIEFwcmlsIDI5 LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0NCgwNDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgU0FTTCBPQXV0aCAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTQNDQoN DQoNDQogICBUaGUgaWRlbnRpZmVyIGFzc2VydGVkIGJ5IHRoZSBPQXV0aCBhdXRob3JpemF0aW9u IHNlcnZlciBhYm91dCB0aGUNDQogICByZXNvdXJjZSBvd25lciBpbnNpZGUgdGhlIGFjY2VzcyB0 b2tlbiBtYXkgYmUgZGlzcGxheWVkIHRvIGEgaHVtYW4uDQ0KICAgRm9yIGV4YW1wbGUsIHdoZW4g U0FTTCBpcyB1c2VkIGluIHRoZSBjb250ZXh0IG9mIElNQVAgdGhlIGNsaWVudCBtYXkNDQogICBh c3NlcnQgdGhlIHJlc291cmNlIG93bmVyJ3MgZW1haWwgYWRkcmVzcyB0byB0aGUgSU1BUCBzZXJ2 ZXIgZm9yDQ0KICAgdXNhZ2UgaW4gYW4gZW1haWwtYmFzZWQgYXBwbGljYXRpb24uICBUaGUgaWRl bnRpZmllciBtYXkgdGhlcmVmb3JlDQ0KICAgY29udGFpbiBpbnRlcm5hdGlvbmFsaXplZCBjaGFy YWN0ZXJzIGFuZCBhbiBhcHBsaWNhdGlvbiBuZWVkcyB0bw0NCiAgIGVuc3VyZSB0aGF0IHRoZSBt YXBwaW5nIGJldHdlZW4gdGhlIGlkZW50aWZpZXIgcHJvdmlkZWQgYnkgT0F1dGggaXMNDQogICBz dWl0YWJsZSBmb3IgdXNlIHdpdGggdGhlIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIFNBU0wg aXMNDQogICBpbmNvcnBvcmF0ZWQgaW50by4NDQoNDQogICBBdCB0aGUgdGltZSBvZiB3cml0aW5n IHRoZSBzdGFuZGFyZGl6YXRpb24gb2YgdGhlIHZhcmlvdXMgY2xhaW1zIGluDQ0KICAgdGhlIGFj Y2VzcyB0b2tlbiAoaW4gSlNPTiBmb3JtYXQpIGlzIHN0aWxsIG9uZ29pbmcsIHNlZSBbSS1ELmll dGYtDQ0KICAgb2F1dGgtanNvbi13ZWItdG9rZW5dLiAgT25jZSBjb21wbGV0ZWQgaXQgd2lsbCBw cm92aWRlIGEgc3RhbmRhcmRpemVkDQ0KICAgZm9ybWF0IGZvciBleGNoYW5naW5nIGlkZW50aXR5 IGluZm9ybWF0aW9uIGJldHdlZW4gdGhlIGF1dGhvcml6YXRpb24NDQogICBzZXJ2ZXIgYW5kIHRo ZSByZXNvdXJjZSBzZXJ2ZXIuDQ0KDQ0KNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMNDQoNDQo3LjEu ICBTQVNMIFJlZ2lzdHJhdGlvbg0NCg0NCiAgIFRoZSBJQU5BIGlzIHJlcXVlc3RlZCB0byByZWdp c3RlciB0aGUgZm9sbG93aW5nIFNBU0wgcHJvZmlsZToNDQoNDQogICAgICBTQVNMIG1lY2hhbmlz bSBwcm9maWxlOiBPQVVUSEJFQVJFUg0NCg0NCiAgICAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z OiBTZWUgdGhpcyBkb2N1bWVudA0NCg0NCiAgICAgIFB1Ymxpc2hlZCBTcGVjaWZpY2F0aW9uOiBT ZWUgdGhpcyBkb2N1bWVudA0NCg0NCiAgICAgIEZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOiBDb250 YWN0IHRoZSBhdXRob3JzIG9mIHRoaXMgZG9jdW1lbnQuDQ0KDQ0KICAgICAgT3duZXIvQ2hhbmdl IGNvbnRyb2xsZXI6IHRoZSBJRVRGDQ0KDQ0KICAgICAgTm90ZTogTm9uZQ0NCg0NCiAgIFRoZSBJ QU5BIGlzIHJlcXVlc3RlZCB0byByZWdpc3RlciB0aGUgZm9sbG93aW5nIFNBU0wgcHJvZmlsZToN DQoNDQogICAgICBTQVNMIG1lY2hhbmlzbSBwcm9maWxlOiBPQVVUSDEwQQ0NCg0NCiAgICAgIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zOiBTZWUgdGhpcyBkb2N1bWVudA0NCg0NCiAgICAgIFB1Ymxp c2hlZCBTcGVjaWZpY2F0aW9uOiBTZWUgdGhpcyBkb2N1bWVudA0NCg0NCiAgICAgIEZvciBmdXJ0 aGVyIGluZm9ybWF0aW9uOiBDb250YWN0IHRoZSBhdXRob3JzIG9mIHRoaXMgZG9jdW1lbnQuDQ0K DQ0KICAgICAgT3duZXIvQ2hhbmdlIGNvbnRyb2xsZXI6IHRoZSBJRVRGDQ0KDQ0KICAgICAgTm90 ZTogTm9uZQ0NCg0NCjguICBSZWZlcmVuY2VzDQ0KDQ0KOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMNDQoNDQogICBbT3BlbklELkNvcmVdDQ0KDQ0KTWlsbHMsIFNob3dhbHRlciAmIFRzY2hvZkV4 cGlyZXMgQXByaWwgMjksIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQ0KDA0NCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICBTQVNMIE9BdXRoICAgICAgICAgICAgICAgICAgIE9j dG9iZXIgMjAxNA0NCg0NCiAgICAgICAgICAgICAgU2FraW11cmEsIE4uLCBCcmFkbGV5LCBKLiwg Sm9uZXMsIE0uQi4sIGRlIE1lZGVpcm9zLCBCLg0NCiAgICAgICAgICAgICAgYW5kIEMuIE1vcnRp bW9yZSwgIk9wZW5JRCBDb25uZWN0IENvcmUgMS4wIiwgRmVicnVhcnkNDQogICAgICAgICAgICAg IDIwMTQuDQ0KDQ0KICAgW09wZW5JRC5EaXNjb3ZlcnldDQ0KICAgICAgICAgICAgICBTYWtpbXVy YSwgTi4sIEJyYWRsZXksIEouLCBKb25lcywgTS5CLiBhbmQgRS4gSmF5LCAiT3BlbklEDQ0KICAg ICAgICAgICAgICBDb25uZWN0IERpc2NvdmVyeSAxLjAiLCBKdWx5IDIwMTEuDQ0KDQ0KICAgW1JG QzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNh dGUNDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks IE1hcmNoIDE5OTcuDQ0KDQ0KICAgW1JGQzMxNzRdICBFYXN0bGFrZSwgRC4gYW5kIFAuIEpvbmVz LCAiVVMgU2VjdXJlIEhhc2ggQWxnb3JpdGhtIDENDQogICAgICAgICAgICAgIChTSEExKSIsIFJG QyAzMTc0LCBTZXB0ZW1iZXIgMjAwMS4NDQoNDQogICBbUkZDNDQyMl0gIE1lbG5pa292LCBBLiBh bmQgSy4gWmVpbGVuZ2EsICJTaW1wbGUgQXV0aGVudGljYXRpb24gYW5kDQ0KICAgICAgICAgICAg ICBTZWN1cml0eSBMYXllciAoU0FTTCkiLCBSRkMgNDQyMiwgSnVuZSAyMDA2Lg0NCg0NCiAgIFtS RkM0NjI3XSAgQ3JvY2tmb3JkLCBELiwgIlRoZSBhcHBsaWNhdGlvbi9qc29uIE1lZGlhIFR5cGUg Zm9yDQ0KICAgICAgICAgICAgICBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTikiLCBS RkMgNDYyNywgSnVseSAyMDA2Lg0NCg0NCiAgIFtSRkM0NjQ4XSAgSm9zZWZzc29uLCBTLiwgIlRo ZSBCYXNlMTYsIEJhc2UzMiwgYW5kIEJhc2U2NCBEYXRhDQ0KICAgICAgICAgICAgICBFbmNvZGlu Z3MiLCBSRkMgNDY0OCwgT2N0b2JlciAyMDA2Lg0NCg0NCiAgIFtSRkM1MjM0XSAgQ3JvY2tlciwg RC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNDQogICAgICAgICAg ICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgU1REIDY4LCBSRkMgNTIzNCwgSmFudWFyeSAyMDA4 Lg0NCg0NCiAgIFtSRkM1MjQ2XSAgRGllcmtzLCBULiBhbmQgRS4gUmVzY29ybGEsICJUaGUgVHJh bnNwb3J0IExheWVyIFNlY3VyaXR5DQ0KICAgICAgICAgICAgICAoVExTKSBQcm90b2NvbCBWZXJz aW9uIDEuMiIsIFJGQyA1MjQ2LCBBdWd1c3QgMjAwOC4NDQoNDQogICBbUkZDNTgwMV0gIEpvc2Vm c3NvbiwgUy4gYW5kIE4uIFdpbGxpYW1zLCAiVXNpbmcgR2VuZXJpYyBTZWN1cml0eQ0NCiAgICAg ICAgICAgICAgU2VydmljZSBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZSAoR1NTLUFQSSkg TWVjaGFuaXNtcw0NCiAgICAgICAgICAgICAgaW4gU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cml0eSBMYXllciAoU0FTTCk6IFRoZQ0NCiAgICAgICAgICAgICAgR1MyIE1lY2hhbmlzbSBG YW1pbHkiLCBSRkMgNTgwMSwgSnVseSAyMDEwLg0NCg0NCiAgIFtSRkM1ODQ5XSAgSGFtbWVyLUxh aGF2LCBFLiwgIlRoZSBPQXV0aCAxLjAgUHJvdG9jb2wiLCBSRkMgNTg0OSwNDQogICAgICAgICAg ICAgIEFwcmlsIDIwMTAuDQ0KDQ0KICAgW1JGQzY3NDldICBIYXJkdCwgRC4sICJUaGUgT0F1dGgg Mi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrIiwgUkZDDQ0KICAgICAgICAgICAgICA2NzQ5LCBP Y3RvYmVyIDIwMTIuDQ0KDQ0KICAgW1JGQzY3NTBdICBKb25lcywgTS4gYW5kIEQuIEhhcmR0LCAi VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uDQ0KICAgICAgICAgICAgICBGcmFtZXdvcms6IEJl YXJlciBUb2tlbiBVc2FnZSIsIFJGQyA2NzUwLCBPY3RvYmVyIDIwMTIuDQ0KDQ0KOC4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcw0NCg0NCiAgIFtJLUQuaWV0Zi1vYXV0aC1keW4tcmVnXQ0NCiAg ICAgICAgICAgICAgUmljaGVyLCBKLiwgSm9uZXMsIE0uLCBCcmFkbGV5LCBKLiwgTWFjaHVsYWss IE0uIGFuZCBQLg0NCiAgICAgICAgICAgICAgSHVudCwgIk9BdXRoIDIuMCBEeW5hbWljIENsaWVu dCBSZWdpc3RyYXRpb24gUHJvdG9jb2wiLA0NCiAgICAgICAgICAgICAgSW50ZXJuZXQtRHJhZnQg ZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTIwLCBBdWd1c3QgMjAxNC4NDQoNDQogICBbSS1ELmll dGYtb2F1dGgtanNvbi13ZWItdG9rZW5dDQ0KICAgICAgICAgICAgICBKb25lcywgTS4sIEJyYWRs ZXksIEouIGFuZCBOLiBTYWtpbXVyYSwgIkpTT04gV2ViIFRva2VuDQ0KICAgICAgICAgICAgICAo SldUKSIsIEludGVybmV0LURyYWZ0IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjUs DQ0KICAgICAgICAgICAgICBKdWx5IDIwMTQuDQ0KDQ0KTWlsbHMsIFNob3dhbHRlciAmIFRzY2hv ZkV4cGlyZXMgQXByaWwgMjksIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQ0KDA0NCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBTQVNMIE9BdXRoICAgICAgICAgICAgICAgICAg IE9jdG9iZXIgMjAxNA0NCg0NCg0NCiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY10NDQog ICAgICAgICAgICAgIFJpY2hlciwgSi4sIE1pbGxzLCBXLiwgVHNjaG9mZW5pZywgSC4gYW5kIFAu IEh1bnQsICJPQXV0aA0NCiAgICAgICAgICAgICAgMi4wIE1lc3NhZ2UgQXV0aGVudGljYXRpb24g Q29kZSAoTUFDKSBUb2tlbnMiLCBJbnRlcm5ldC0NDQogICAgICAgICAgICAgIERyYWZ0IGRyYWZ0 LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDUsIEphbnVhcnkgMjAxNC4NDQoNDQogICBbUkZDMjYx Nl0gIEZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwNDQog ICAgICAgICAgICAgIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuIGFuZCBULiBCZXJuZXJzLUxlZSwg Ikh5cGVydGV4dA0NCiAgICAgICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEi LCBSRkMgMjYxNiwgSnVuZSAxOTk5Lg0NCg0NCiAgIFtSRkMzNTAxXSAgQ3Jpc3BpbiwgTS4sICJJ TlRFUk5FVCBNRVNTQUdFIEFDQ0VTUyBQUk9UT0NPTCAtIFZFUlNJT04NDQogICAgICAgICAgICAg IDRyZXYxIiwgUkZDIDM1MDEsIE1hcmNoIDIwMDMuDQ0KDQ0KICAgW1JGQzUzMjFdICBLbGVuc2lu LCBKLiwgIlNpbXBsZSBNYWlsIFRyYW5zZmVyIFByb3RvY29sIiwgUkZDIDUzMjEsDQ0KICAgICAg ICAgICAgICBPY3RvYmVyIDIwMDguDQ0KDQ0KICAgW1JGQzYxMjBdICBTYWludC1BbmRyZSwgUC4s ICJFeHRlbnNpYmxlIE1lc3NhZ2luZyBhbmQgUHJlc2VuY2UNDQogICAgICAgICAgICAgIFByb3Rv Y29sIChYTVBQKTogQ29yZSIsIFJGQyA2MTIwLCBNYXJjaCAyMDExLg0NCg0NCiAgIFtSRkM2ODE5 XSAgTG9kZGVyc3RlZHQsIFQuLCBNY0dsb2luLCBNLiBhbmQgUC4gSHVudCwgIk9BdXRoIDIuMA0N CiAgICAgICAgICAgICAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIs IFJGQyA2ODE5LA0NCiAgICAgICAgICAgICAgSmFudWFyeSAyMDEzLg0NCg0NCiAgIFtSRkM3MDMz XSAgSm9uZXMsIFAuLCBTYWxndWVpcm8sIEcuLCBKb25lcywgTS4gYW5kIEouIFNtYXJyLA0NCiAg ICAgICAgICAgICAgIldlYkZpbmdlciIsIFJGQyA3MDMzLCBTZXB0ZW1iZXIgMjAxMy4NDQoNDQpB cHBlbmRpeCBBLiAgQWNrbm93bGVnZW1lbnRzDQ0KDQ0KICAgVGhlIGF1dGhvcnMgd291bGQgbGlr ZSB0byB0aGFuayB0aGUgbWVtYmVycyBvZiB0aGUgS2l0dGVuIHdvcmtpbmcNDQogICBncm91cCwg YW5kIGluIGFkZGl0aW9uIGFuZCBzcGVjaWZpY2FsbHk6IFNpbW9uIEpvc2Vmc29uLCBUb3JzdGVu DQ0KICAgTG9kZGVyc3RhZHQsIFJ5YW4gVHJvbGwsIEFsZXhleSBNZWxuaWtvdiwgSmVmZnJleSBI dXR6ZWxtYW4sIE5pY28NDQogICBXaWxsaWFtcywgTWF0dCBNaWxsZXIsIGFuZCBCZW5qYW1pbiBL YWR1ay4NDQoNDQogICBUaGlzIGRvY3VtZW50IHdhcyBwcm9kdWNlZCB1bmRlciB0aGUgY2hhaXJt YW5zaGlwIG9mIEFsZXhleSBNZWxuaWtvdiwNDQogICBUb20gWXUsIFNoYXduIEVtZXJ5LCBKb3No IEhvd2xldHQsIFNhbSBIYXJ0bWFuLiAgVGhlIHN1cGVydmlzaW5nIGFyZWENDQogICBkaXJlY3Rv ciB3YXMgU3RlcGhlbiBGYXJyZWxsLg0NCg0NCkFwcGVuZGl4IEIuICBEb2N1bWVudCBIaXN0b3J5 DQ0KDQ0KICAgW1sgdG8gYmUgcmVtb3ZlZCBieSBSRkMgZWRpdG9yIGJlZm9yZSBwdWJsaWNhdGlv biBhcyBhbiBSRkMgXV0NDQoNDQogICAtMTcNDQoNDQogICBvICBMYXN0IGNhbGwgZmVlZGJhY2sg YWdhaW4uICBlcmFkaWNhdGVkIGNvbW1hIHNwbGljaW5nLiAgUmVtb3ZlZA0NCiAgICAgIGV4dHJh IHNlcnZlciBtZXNzYWdlIGluIGV4YW1wbGUgNC4zLg0NCg0NCiAgIC0xNg0NCg0NCiAgIG8gIExh c3QgY2FsbCBmZWVkYmFjayBhZ2Fpbi4gIFByaW1hcmlseSBlZGl0b3JpYWwgY2hhbmdlcy4gIENv cnJlY3RlZA0NCiAgICAgIGV4YW1wbGVzLg0NCg0NCiAgIC0xNQ0NCg0NCiAgIG8gIExhc3QgY2Fs bCBmZWVkYWNrIG9uIHRoZSBHUzIgc3R1ZmYgYmVpbmcgcmlwcGVkIG91dCBjb21wbGV0ZWx5Lg0N Cg0NCk1pbGxzLCBTaG93YWx0ZXIgJiBUc2Nob2ZFeHBpcmVzIEFwcmlsIDI5LCAyMDE1ICAgICAg ICAgICAgICAgIFtQYWdlIDE3XQ0NCgwNDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg U0FTTCBPQXV0aCAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTQNDQoNDQoNDQogICBvICBS ZW1vdmVkIHRoZSAidXNlciIgcGFyYW1ldGVyIGFuZCBwdXQgc3R1ZmYgYmFjayBpbnRvIHRoZQ0N CiAgICAgIGdzMi1oZWFkZXIuICBDYWxsIG91dCB0aGF0IHRoZSBhdXRoemlkIGdvZXMgaW4gdGhl IGdzMi1oZWFkZXIgd2l0aA0NCiAgICAgIHNvbWUgcHJvc2UgYWJvdXQgd2hlbiBpdCBtaWdodCBi ZSByZXF1aXJlZC4gIFZlcnkgY29tcGFyYWJsZSB0bw0NCiAgICAgIC0xMC4NDQoNDQogICBvICBB ZGRlZCBhbiBPQXV0aCAxLjBBIGV4YW1wbGUgZXhwbGljaXRseS4NDQoNDQogICAtMTQNDQoNDQog ICBvICBMYXN0IGNhbGwgZmVlZGFjayBvbiBSRkMgY2l0YXRpb25zIG5lZWRlZCwgc21hbGwgZWRp dG9yaWFsLg0NCg0NCiAgIG8gIEFkZGVkIHRoZSAidXNlciIgcGFyYW1ldGVyIGJhY2ssIHdoaWNo IHdhcyBwdWxsZWQgd2hlbiB3ZSBzdGFydGVkDQ0KICAgICAgZG93biB0aGUgR1MyIHBhdGguICBT YW1lIGxhbmd1YWdlIGFzIC0wMy4NDQoNDQogICBvICBEZWZpbmVkIGEgc3R1YiBHUzIgaGVhZGVy IHRvIG1ha2Ugc3VyZSB0aGF0IHdoZW4gdGhlIEdTMiBicmlkZSBpcw0NCiAgICAgIGRlZmluZWQg Zm9yIHRoaXMgdGhhdCBub3RoaW5nIHdpbGwgYnJlYWsgd2hlbiBpdCBhY3R1YWxseSBzdGFydHMN DQogICAgICB0byBnZXQgcG9wdWxhdGVkLg0NCg0NCiAgIC0xMw0NCg0NCiAgIG8gIENoYW5nZWQg YWZmaWxpYXRpb24uDQ0KDQ0KICAgLTEyDQ0KDQ0KICAgbyAgUmVtb3ZlZCAtUExVUyBjb21wb25l bnRzIGZyb20gdGhlIHNwZWNpZmljYXRpb24uDQ0KDQ0KICAgLTExDQ0KDQ0KICAgbyAgUmVtb3Zl ZCBHU1MtQVBJIGNvbXBvbmVudHMgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbi4NDQoNDQogICBvICBV cGRhdGVkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbi4NDQoNDQogICAtMTANDQoNDQog ICBvICBDbGFyaWZpY2F0aW9ucyB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCBpbiByZXNwb25zZSB0 byB0aGUgZmVlZGJhY2sNDQogICAgICBmcm9tIEplZmZyZXkgSHV0emVsbWFuLg0NCg0NCiAgIC0w OQ0NCg0NCiAgIG8gIEluY29ycG9yYXRlZCByZXZpZXcgYnkgQWxleGV5IGFuZCBIYW5uZXMuDQ0K DQ0KICAgbyAgQ2xhcmlmaWVkIHRoZSB0aHJlZSBPQXV0aCBTQVNMIG1lY2hhbmlzbXMuDQ0KDQ0K ICAgbyAgVXBkYXRlZCByZWZlcmVuY2VzDQ0KDQ0KICAgbyAgRXh0ZW5kZWQgYWNrbm93bGVkZ2Vt ZW50cw0NCg0NCiAgIC0wOA0NCg0NCiAgIG8gIEZpeGVkIHRoZSBjaGFubmVsIGJpbmRpbmcgZXhh bXBsZXMgZm9yIHA9JGNidHlwZQ0NCg0NCiAgIG8gIE1vcmUgdHVuaW5nIG9mIHRoZSBhdXRoY2lk IGxhbmd1YWdlIGFuZCBlZGl0ZWQgYW5kIHJlbmFtZWQgMy4yLjEuDQ0KDQ0KDQ0KTWlsbHMsIFNo b3dhbHRlciAmIFRzY2hvZkV4cGlyZXMgQXByaWwgMjksIDIwMTUgICAgICAgICAgICAgICAgW1Bh Z2UgMThdDQ0KDA0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBTQVNMIE9BdXRoICAg ICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNA0NCg0NCg0NCiAgIC0wNw0NCg0NCiAgIG8gIFN0 cnVjayB0aGUgTVVTVCBsYW5naWFnZSBmcm9tIGF1dGh6aWQuDQ0KDQ0KICAgLTA2DQ0KDQ0KICAg byAgUmVtb3ZlZCB0aGUgdXNlciBmaWVsZC4gIEZpeGVkIHRoZSBleGFtcGxlcyBhZ2Fpbi4NDQoN DQogICBvICBBZGRlZCBjYW5vbmljYWxpemF0aW9uIGxhbmd1YWdlLg0NCg0NCiAgIC0wNQ0NCg0N CiAgIG8gIEZpeGVkIHRoZSBHUzIgaGVhZGVyIGxhbmd1YWdlIGFnYWluLg0NCg0NCiAgIG8gIFNl cGFyYXRlZCBvdXQgZGlmZmVyZW50IE9BdXRoIHNjaGVtZXMgaW50byBkaWZmZXJlbnQgU0FTTA0N CiAgICAgIG1lY2hhbmlzbXMuICBUb29rIG91dCB0aGUgc2NoZW1lIGluIHRoZSBlcnJvciByZXR1 cm4uICBUdW5lZCB1cA0NCiAgICAgIHRoZSBJQU5BIHJlZ2lzdHJhdGlvbnMuDQ0KDQ0KICAgbyAg QWRkZWQgdGhlIHVzZXIgZmllbGQgYmFjayBpbnRvIHRoZSBTQVNMIG1lc3NhZ2UuDQ0KDQ0KICAg byAgRml4ZWQgdGhlIGV4YW1wbGVzIChhZ2FpbikuDQ0KDQ0KICAgLTA0DQ0KDQ0KICAgbyAgQ2hh bmdlZCB1c2VyIGZpZWxkIHRvIGJlIGNhcnJpZWQgaW4gdGhlIGdzMi1oZWFkZXIsIGFuZCBtYWRl IGdzMg0NCiAgICAgIGhlYWRlciBleHBsaWNpdCBpbiBhbGwgY2FzZXMuDQ0KDQ0KICAgbyAgQ29u dmVydGVkIE1BQyBleGFtcGxlcyB0byBPQXV0aCAxLjBhLiAgTW92ZWQgTUFDIHRvIGFuIGluZm9y bWF0aXZlDQ0KICAgICAgcmVmZXJlbmNlLg0NCg0NCiAgIG8gIENoYW5nZWQgdG8gc2VuZGluZyBh biBlbXB0eSBjbGllbnQgcmVzcG9uc2UgKHNpbmdsZSBjb250cm9sLUEpIGFzDQ0KICAgICAgdGhl IHNlY29uZCBtZXNzYWdlIG9mIGEgZmFpbGVkIHNlcXVlbmNlLg0NCg0NCiAgIG8gIEZpeGVkIGNo YW5uZWwgYmluZGluZyBwcm9zZSB0byByZWZlciB0byB0aGUgbm9ybWF0aXZlIHNwZWNzIGFuZA0N CiAgICAgIHJlbW92ZWQgdGhlIGhhc2hpbmcgb2YgbGFyZ2UgY2hhbm5lbCBiaW5kaW5nIGRhdGEs IHdoaWNoIGJyb3VnaHQNDQogICAgICBtcm9lIHByb2JsZW1zIHRoYW4gaXQgc29sdmVkLg0NCg0N CiAgIG8gIEFkZGVkIGEgU01UUCBleGFtcGxlcyBmb3IgQmVhcmVyIHVzZSBjYXNlLg0NCg0NCiAg IC0wMw0NCg0NCiAgIG8gIEFkZGVkIHVzZXIgZmllbGQgaW50byBleGFtcGxlcyBhbmQgZml4ZWQg ZWdyZWdpb3VzIGVycm9ycyB0aGVyZSBhcw0NCiAgICAgIHdlbGwuDQ0KDQ0KICAgbyAgQWRkZWQg dGV4dCByZW1pbmRpbmcgZGV2ZWxvcGVycyB0aGF0IEF1dGhvcml6YXRpb24gc2NoZW1lIG5hbWVz DQ0KICAgICAgYXJlIGNhc2UgaW5zZW5zaXRpdmUuDQ0KDQ0KICAgLTAyDQ0KDQ0KICAgbyAgQWRk ZWQgdGhlIHVzZXIgZGF0YSBlbGVtZW50IGJhY2sgaW4uDQ0KDQ0KICAgbyAgTWlub3IgZWRpdG9y aWFsIGNoYW5nZXMuDQ0KDQ0KDQ0KTWlsbHMsIFNob3dhbHRlciAmIFRzY2hvZkV4cGlyZXMgQXBy aWwgMjksIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQ0KDA0NCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICBTQVNMIE9BdXRoICAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAx NA0NCg0NCg0NCiAgIC0wMQ0NCg0NCiAgIG8gIFJpcHBpbmcgb3V0IGRpc2NvdmVyeS4gIENoYW5n ZWQgdG8gcmVmZXIgdG8gSS1ELmpvbmVzLWFwcHNhd2ctDQ0KICAgICAgd2ViZmluZ2VyIGluc3Rl YWQgb2YgV0YgYW5kIFNXRCBvbGRlciBkcmFmdHMuDQ0KDQ0KICAgbyAgUmVwbGFjaW5nIEhUVFAg YXMgdGhlIG1lc3NhZ2UgZm9ybWF0IGFuZCBhZGp1c3RlZCBhbGwgZXhhbXBsZXMuDQ0KDQ0KICAg LTAwDQ0KDQ0KICAgbyAgUmVuYW1lZCBkcmFmdCBpbnRvIHByb3BlciBJRVRGIG5hbWluZyBmb3Jt YXQgbm93IHRoYXQgaXQncw0NCiAgICAgIGFkb3B0ZWQuDQ0KDQ0KICAgbyAgTWlub3IgZml4ZXMu DQ0KDQ0KQXV0aG9ycycgQWRkcmVzc2VzDQ0KDQ0KICAgV2lsbGlhbSBNaWxscw0NCiAgIE1pY3Jv c29mdA0NCiAgIA0NCiAgIEVtYWlsOiB3aW1pbGxzQG1pY3Jvc29mdC5jb20NDQoNDQoNDQogICBU aW0gU2hvd2FsdGVyDQ0KICAgDQ0KICAgRW1haWw6IHRqc0Bwc2F1eC5jb20NDQoNDQoNDQogICBI YW5uZXMgVHNjaG9mZW5pZw0NCiAgIEFSTSBMdGQuDQ0KICAgMTEwIEZ1bGJvdXJuIFJkDQ0KICAg Q2FtYnJpZGdlLCBDQjEgOU5KDQ0KICAgR3JlYXQgQnJpdGFpbg0NCiAgIA0NCiAgIEVtYWlsOiBI YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0DQ0KICAgVVJJOiAgIGh0dHA6Ly93d3cudHNjaG9mZW5p Zy5wcml2LmF0DQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0K DQ0KDQ0KDQ0KTWlsbHMsIFNob3dhbHRlciAmIFRzY2hvZkV4cGlyZXMgQXByaWwgMjksIDIwMTUg ICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQ0K ------=_Part_819475_1041334597.1414534802287-- From nobody Tue Oct 28 15:25:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14A51A00DB for ; Tue, 28 Oct 2014 15:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E7jlUX8g-8x for ; Tue, 28 Oct 2014 15:24:55 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48191A008D for ; Tue, 28 Oct 2014 15:24:49 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-94-545017b04beb Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id D2.64.27750.0B710545; Tue, 28 Oct 2014 18:24:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9SMOlu1002418; Tue, 28 Oct 2014 18:24:48 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9SMOj3o005027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Oct 2014 18:24:47 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9SMOiZB028615; Tue, 28 Oct 2014 18:24:44 -0400 (EDT) Date: Tue, 28 Oct 2014 18:24:44 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <544EFB27.6050905@mit.edu> Message-ID: References: <544EFB27.6050905@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrbtBPCDE4MVaFYujm1exWPzr5nNg 8liy5CeTR+uOv+wBTFFcNimpOZllqUX6dglcGadb5jIVzOKpmHfnMXsD4yfOLkZODgkBE4nO m9PZIGwxiQv31gPZXBxCArOZJE5f+cwC4WxklPiycDE7hHOISWJ3+1JmCKeBUWLW+m9g/SwC 2hK33/ewgthsAioSM99sBIuLCChK/F75lhHEZhaIkHi3sYcFxBYW8JZ4/3QHWJxTQF1izvYZ TCA2r4CjRM/yFqA4B9CCAolJFxNBwqICOhKr909hgSgRlDg58wkLxEgtieXTt7FMYBSchSQ1 C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjOBAleTZwfjmoNIhRgEO RiUeXoOHfiFCrIllxZW5hxglOZiURHlXCAaECPEl5adUZiQWZ8QXleakFh9ilOBgVhLh5fzh HyLEm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBWy8GNFSwKDU9tSIt M6cEIc3EwQkynAdo+HSQGt7igsTc4sx0iPwpRkUpcd4VIAkBkERGaR5cLyyRvGIUB3pFmHc9 SBUPMAnBdb8CGswENNhomg/I4JJEhJRUAyPfyrcbuCUt13dZbgirfMa7zmTC1X1mGUdK/ofW 61Usyn62fEZz/t+P/jNWJaZZ7BA7+GxrZ6Uyw14np9ZNt2vbJ8udnP3j+qL+jdm5t424Npbe KPsq8fz+wSihtnv2V/fMbo7lOTRRMlT7kOChYl9l7yr18l9My5eXxrGu5H33NqzYZ4/Lw3Il luKMREMt5qLiRACnPSAH/wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/p1GvXZuVi2ffKpUBH9s-27U-yXs Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:24:59 -0000 On Mon, 27 Oct 2014, Greg Hudson wrote: > On 10/27/2014 04:56 PM, Michiko Short wrote: > > https://datatracker.ietf.org/doc/draft-short-pkinit-freshness/ > > Thanks for working on this issue. I think the working group should > adopt this draft. I have a few specific comments, which are editorial only: I also think the working group should adopt this draft (with my individual hat, so far) -- it's a simple way to resolve a weakness of the existing standard. I'm happy that we're considering potential implementations for the freshness token, but am still undecided whether this document should say anything concrete about the contents of the kdcToken. From what I've seen so far (both on-list and on IRC), it seems like just a timestamp encrypted in a key derived from the krbtgt key of the local realm should provide the needed properties. Brainstorming out loud, once a given realm gest to a state where the KDCs require freshness tokens in PKINIT AS-REQs, an attacker could cause a denial of service if it could modify the KRB-ERROR responses to remove valid freshness tokens from them. This probably doesn't matter, because such an attacker could deny service in other ways (by corrupting the AS-REP's ciphertext or blocking it entirely, etc.). Figure 1 includes a column for traffic involving the "appliication server", which is not used, so it could probably be removed. There are some grammar nits floating around; let me know if you want me to write them up and send them to you (off-list, presumably). -Ben From nobody Tue Oct 28 15:31:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296361A0081 for ; Tue, 28 Oct 2014 15:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqDBR1RMtXJS for ; Tue, 28 Oct 2014 15:31:30 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE561A0022 for ; Tue, 28 Oct 2014 15:31:30 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-e2-54501941059e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id C8.FA.18723.14910545; Tue, 28 Oct 2014 18:31:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9SMVSC1032678; Tue, 28 Oct 2014 18:31:28 -0400 Received: from [18.101.8.175] (vpn-18-101-8-175.mit.edu [18.101.8.175]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9SMVQRW006967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Oct 2014 18:31:27 -0400 Message-ID: <5450193D.5060007@mit.edu> Date: Tue, 28 Oct 2014 18:31:25 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michiko Short , Nico Williams References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> <67800303b1294cddbd36d3add529844a@BL2PR03MB212.namprd03.prod.outlook.com> In-Reply-To: <67800303b1294cddbd36d3add529844a@BL2PR03MB212.namprd03.prod.outlook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hRV1nWUDAgxmD6Z3eLHpBnMFkc3r2Kx +NfNZ3Hq2hE2BxaPl6fOMXosWfKTyaN1x1/2AOYoLpuU1JzMstQifbsErowj0/YzFdzmqpjQ cJ21gfEBRxcjJ4eEgInE/JvtbBC2mMSFe+uBbC4OIYHZTBId5yYxQzgbGSUetXeyg1QJCRxh klj2xh7E5hVQk9i/4QNjFyMHB4uAqsTWKTYgYTYBZYn1+7eygIRFBcIkpi7lgagWlDg58wkL iC0iECVx7MBsZhCbWSBaYuuM42BxYQFvifdPdzBCrG1nlth2sRVsLSfQnBWrJ7NCNKhL/Jl3 CapZXqJ562zmCYyCs5DsmIWkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfVyM0v0 UlNKNzGCQpvdRWUHY/MhpUOMAhyMSjy8Bg/9QoRYE8uKK3MPMUpyMCmJ8q4QDAgR4kvKT6nM SCzOiC8qzUktPsQowcGsJMLL+cM/RIg3JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFq EUxWhoNDSYJ3qgTQUMGi1PTUirTMnBKENBMHJ8hwHqDhn0BqeIsLEnOLM9Mh8qcYFaXEef+I ASUEQBIZpXlwvbDU84pRHOgVYd6zIO08wLQF1/0KaDAT0GCjaT4gg0sSEVJSDYxz4t8FKaR/ mFvU93eXPn+y7pnFvZeNTy4JCFsltLJuUkEIG2PSfR1dTp+ZW3K/r1ed5RIbMf3UiZ+5X/ey doqLrBcpDGuvnBQdoWo+wXmH3puuNJWcpf5Fk5/156UkbvDbbXfmkUaj0iwHxfUXwtu/+ysW 9PNzelw7d+TNvIhTDvozHse8a1BiKc5INNRiLipOBACIO4R7GAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/_cS3n-KNuHUwLSu8b8ZNz-FnGrM Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:31:33 -0000 On 10/28/2014 05:38 PM, Michiko Short wrote: > Ah, so then having a mix of KDC implementations is supported other than with Windows AD domains? "Supported" may be an overstatement. People have done it, and basic functionality works, and we (MIT krb5 and Heimdal) have coordinated on some KDC-only protocol elements such as AD-SIGNTICKET in the past. However, there is also precedent in the IETF for not standardizing KDC-only elements--most notably, the contents of PA-FX-COOKIE are totally non-standardized. Whichever project implements the freshness token can make a non-IETF document describing the format As for what goes into the freshness token, I don't see any need to put in more than the minimum, which is an encrypted or checksummed timestamp. (And a kvno if we use a checksum, since Checksum doesn't identify which key version was used.) That should be sufficient to prevent the threat described in the draft. I should note that there is an unbounded delay between the preauth-required error and the preauthenticated AS request, since the user can take arbitrarily long to respond to authentication prompts. We can't really avoid this problem without introducing state in the KDC, so clients will just have to deal with the possibility that authentication might fail in this case; it can retry, or it can make the user retry. From nobody Tue Oct 28 15:32:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8491A00D6 for ; Tue, 28 Oct 2014 15:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KedDPajibwI for ; Tue, 28 Oct 2014 15:32:16 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153F01A0022 for ; Tue, 28 Oct 2014 15:32:16 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-22-5450196ec8fe Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 6C.D0.28565.E6910545; Tue, 28 Oct 2014 18:32:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9SMWEp9032763; Tue, 28 Oct 2014 18:32:14 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9SMWCSR007221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Oct 2014 18:32:13 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9SMWCQU029566; Tue, 28 Oct 2014 18:32:12 -0400 (EDT) Date: Tue, 28 Oct 2014 18:32:11 -0400 (EDT) From: Benjamin Kaduk To: "Nordgren, Bryce L -FS" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7443E4@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: References: <82E7C9A01FD0764CACDD35D10F5DFB6E7443E4@001FSN2MPN1-045.001f.mgd2.msft.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrJsnGRBicPi5jcXVNz9ZLY5uXsXi wORx+81ZFo8lS34yBTBFcdmkpOZklqUW6dslcGUs3nORrWALR8XOhlVsDYwf2LoYOTkkBEwk /q9/xwJhi0lcuLceKM7FISQwm0mi9dxBVghnI6PE16t/mCCcQ0wSM9bPZIdwGhglDh29xArS zyKgLdG54g87iM0moCIx881GsB0iAoYS3UuPMYLYzALqEt/OvAGyOTiEBdQkFl0QAQlzCkRI TL59HKyVV8BR4tmsmcwgtpBAuMTLNS/A4qICOhKr909hgagRlDg58wkLxEgtieXTt7FMYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjOBQleTdwfjuoNIh RgEORiUeXoOHfiFCrIllxZW5hxglOZiURHlXCAaECPEl5adUZiQWZ8QXleakFh9ilOBgVhLh 5fzhHyLEm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBKyIBNFSwKDU9 tSItM6cEIc3EwQkynAdouB1IDW9xQWJucWY6RP4Uo6KUOK8OSEIAJJFRmgfXC0slrxjFgV4R 5pUBqeIBpiG47ldAg5mABhtN8wEZXJKIkJJqYMzanlh37VRpyjuelLqvX+RvCga8npaoo7FE s9zn/rMZ98/NDWbbOmFe2JLeZjGPFMXzTEfi5xy1e9tcv+yxYVN45JGnWUaTbrjfbxa+FjTj zaW1BnV/2hM8Ra7r53MsXDLHleHnjcd//Bae7fvOLK59cNn8wPzJSRP2mienC9WJdszX0JAI ElBiKc5INNRiLipOBACcHPdlAAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/bufPfBAkEm2z9aL3xav8tCxJhus Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:32:19 -0000 On Tue, 28 Oct 2014, Nordgren, Bryce L -FS wrote: > B] It seems likely that connecting to an external organization will > either be a one-hop affair via PKCROSS or completely impossible. (e.g., > it seems weird to permit manual keying of cross realm principals from a > realm that can PKCROSS, but not allow PKCROSS yourself.) What would a > trust router do? Some discussion a couple years ago about federation for the Zephyr instant messaging protocol proposed a scheme where the GRAND.CENTRAL.ORG kerberos realm could be a central hub for cross-realm traffic, in that it would freely peer with ~anyone, for the asking. I don't necessarily think that exactly that will happen, but it seems at least vaguely plausible that smaller versions could happen, wherein, say, EXAMPLE.EDU would actively initiate pkcross for a shared key with INTERNET2.EDU but wouldn't accept incoming pkcross from EXAMPLE.COM. But, maybe INTERNET2.EDU would accept that pkcross from EXAMPLE.COM, and act as a hub for cross-realm traffic. Just some idle speculation... -Ben From nobody Tue Oct 28 15:34:34 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDCB1A00F7 for ; Tue, 28 Oct 2014 15:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvF7PZlP6W9c for ; Tue, 28 Oct 2014 15:34:30 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FDD1A0060 for ; Tue, 28 Oct 2014 15:34:30 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-8b-545019f57ff1 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id ED.E4.27750.5F910545; Tue, 28 Oct 2014 18:34:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9SMYSHI000506; Tue, 28 Oct 2014 18:34:28 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9SMYP7v007874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Oct 2014 18:34:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9SMYPpU029859; Tue, 28 Oct 2014 18:34:25 -0400 (EDT) Date: Tue, 28 Oct 2014 18:34:24 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <5450193D.5060007@mit.edu> Message-ID: References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> <67800303b1294cddbd36d3add529844a@BL2PR03MB212.namprd03.prod.outlook.com> <5450193D.5060007@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IR4hRV1v0qGRBi8GArj8WPSTOYLY5uXsVi 8a+bz+LUtSNsDiweL0+dY/RYsuQnk0frjr/sAcxRXDYpqTmZZalF+nYJXBkNn++zFFxlqdg+ +RZbA+N95i5GTg4JAROJzeu6WSBsMYkL99azdTFycQgJzGaS6Dr/nQnC2cgosaL5BAuEc4hJ Ym/HJiingVHidfMbdpB+FgFtidszLjKB2GwCKhIz32xkA7FFBBQlfq98ywhiMwvsYZR4cEMa xBYW8JZ4/3QHWJxTQF1i7YvXYDfxCjhKfL/9Fmr1EmaJVTe3gg0VFdCRWL1/CgtEkaDEyZlP WCCGakksn76NZQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaU bmIEh7Ikzw7GNweVDjEKcDAq8fAaPPQLEWJNLCuuzD3EKMnBpCTKu0IwIESILyk/pTIjsTgj vqg0J7X4EKMEB7OSCC/nD/8QId6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZ Dg4lCV5nYMwKCRalpqdWpGXmlCCkmTg4QYbzAA3PBKnhLS5IzC3OTIfIn2LU5WhpetvLJMSS l5+XKiXOqyMBVCQAUpRRmgc3B5aCXjGKA70lzNsMMooHmL7gJr0CWsIEtMRomg/IkpJEhJRU A2PwscBs3tVOv7dqeUbJnmU7IVRtvoz3/QILzTJG+yf3pHgLVfKTOPdr2q9Zdf/XQyPfB1kb n/w7fn+O/Oz9Rt/sNbt1TB8vy9O3Sdc9+/kN38ZlTieD9toouNpUcD4IeHn5jUqgg8w763vK aybt6CrUjr7o7ruU/4IH164S271c3Tuasn8tilRiKc5INNRiLipOBAAHZH1oHAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cCChW2s3Grl_M-L9ddgZu0lB3us Cc: "kitten@ietf.org" , Michiko Short , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:34:32 -0000 On Tue, 28 Oct 2014, Greg Hudson wrote: > I should note that there is an unbounded delay between the > preauth-required error and the preauthenticated AS request, since the > user can take arbitrarily long to respond to authentication prompts. We > can't really avoid this problem without introducing state in the KDC, so > clients will just have to deal with the possibility that authentication > might fail in this case; it can retry, or it can make the user retry. The draft should probably mention explicitly that clients shouldu be prepared to retry in cases like this. -Ben From nobody Tue Oct 28 15:50:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2701A0161 for ; Tue, 28 Oct 2014 15:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KDaqjqPCnrb for ; Tue, 28 Oct 2014 15:50:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254F41A00D7 for ; Tue, 28 Oct 2014 15:50:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 19FBF2AB2BB; Tue, 28 Oct 2014 22:50:26 +0000 (UTC) Date: Tue, 28 Oct 2014 22:50:26 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141028225025.GC9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4wrG54PrTA9Ey4O2vZSeTd5J9GY Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:50:29 -0000 On Mon, Oct 27, 2014 at 02:13:55PM -0400, Benjamin Kaduk wrote: > In section 4, does "the client MUST dismiss any DNS responses that are not > Insecure, Bogus or Indeterminite" have an extra 'not'? You might want to compare with the SMTP with DANE DNS error handling text: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-2.1.1 The term "indeterminate" sadly has different meanings in RFC 4033 and 4035. So one needs to be specific about which meaning one has in mind. The 4035 variant is essentially a lookup failure condition, while the 4033 variant is essentially "insecure" for lack of a suitable trust-anchor rather than an opt-out. I explain that "bogus" and "indeterminate" (4035) are error conditions are to be treated in the same way as timeouts, and other transient problems. I also explain that "NXDOMAIN" is not an error condition (given signed proof of non-existence if the containing zone is signed). With that out of the way, one processes "secure" responses, treates "insecure" responses and "NXDOMAIN" as absence of data, and treats all other outcomes as transient errors (applying whatever logic is appropriate in that case). -- Viktor. From nobody Tue Oct 28 16:05:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425561A1A27 for ; Tue, 28 Oct 2014 16:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.634 X-Spam-Level: * X-Spam-Status: No, score=1.634 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irlQzdSKznNt for ; Tue, 28 Oct 2014 16:05:12 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5700B1A1A25 for ; Tue, 28 Oct 2014 16:05:12 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 1E63D20058D84; Tue, 28 Oct 2014 16:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0rDUpQTC/dyOAQ fBF3fGveEHTO4=; b=WW9Jij3dVd3RhtmT26Ply1EnU94qAzOP3G2YSNsdZKfgul YeK2f8fKZbYC9VTSA8kVbaAInijZNYyf1YujqqpmQwpmehyoHO3kNgaBdpOWe7ON hBypxfS47+M/To9p24viL8s1pNeIivawCvn0UjCNj74NRc0DoxCGavT5AUjEk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id CF80B20058D83; Tue, 28 Oct 2014 16:05:11 -0700 (PDT) Date: Tue, 28 Oct 2014 18:05:11 -0500 From: Nico Williams To: "Nordgren, Bryce L -FS" Message-ID: <20141028230509.GG17213@localhost> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7443E4@001FSN2MPN1-045.001f.mgd2.msft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7443E4@001FSN2MPN1-045.001f.mgd2.msft.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UjfEik-dNn41Lq4IKuFGsenN8-I Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:05:14 -0000 On Tue, Oct 28, 2014 at 10:21:05PM +0000, Nordgren, Bryce L -FS wrote: > Why would a target realm reject a client but issue an ITGT to a TGS > from the same realm? Isn't it more or less the realm which is being > evaluated for trust? Clients can't vouch for themselves. Perhaps because it wants to minimize PK operations. Let's say we have realms A and B, with clients in A trying to talk to B using PKCROSS. If the number of clients in A wishing to talk to services at B exceeds the number of KDCs in A, then it's a win to force A clients to use TGS-driven PKCROSS. B's KDCs might decide this heuristically even ("huh, 1,000 PKCROSS requests from FOO.EXAMPLE in the last hour; they should use TGS-driven PKCROSS"). I should have explained this, yes. > Section 2.6: for symmetry's sake, should there be a mechanism for a > target KDC to hint to the source KDC that constantly requesting an > ITGT is annoying and permanent long term keys are going to be required > (for them)? Maybe! But long-term symmetric keying of cross-realm principals on demand can also be a DoS, so for now I'm thinking symmetrically keying x-realm principals should still involve some manual process, though the actual keying be automatic. Presumably the ITGT burden wouldn't be too great. Even if you have 100 KDCs, if you issue 24hr ITGTs then that's only about 4 requests per-hour. Even if multiple threads in the KDCs race to do this, since the KDCs can keep track of which ITGTs are actively used, they can refresh them before having to race to get fresh ones. But sure, a hint about this would be nice. (Yet another reason to extend EncKDCRepPart..., since that's where the hint would have to go.) It might even be possible for KDCs in a realm to share ITGTs with each other, thus further reducing load from the marginal to the utterly insignificant. > Section 5.2: Do we pass the transit path policy from KDC to KDC? I'm > not convinced that a common policy language is useful except for such > a case. Why would a target KDC want to know a foreign site's > advertised policy? Why would target KDC trust that the foreign site > applied the policy as written? Transit paths, at least, are > constructed in such a way that you can't edit yourself out. That made more sense before I split out 5.3. In the world of MIT krb5 and Heimdal we have that dreaded [capaths] section of krb5.conf. It is used for *both*, routing and transit path validation. And yes, it needs to be kept in sync -- not that a realm admin has to accept other realms' _policy_, but that: a) multi-realm transit paths result for various reasons and it's often useful to know about a peer realm's paths to others, b) you still need to distribute your realm's [capaths] to its clients and services. Separating policy from routing would be handy. Being able to specify routing differently from the client principal's _realm_'s perspective, rather than the client host's, would be handy. Having something better than [capaths] would be very nice. > If PKCROSS really succeeds, the main function of a KDC will be to act > as an "identity firewall". It handles the coarse-grained, realm wide > decisions about which identity sources are made available to local > services. Firewalls don't try and share their configuration > information with each other. They just drop the connection. The KDC > probably should too. Too much sharing can be bad. Well, it _could_. It could also just let any client in its realm(s) talk to any remote realms. And it couldn't stop clients from using the client-driven PKCROSS protocol anyways. But with TGS-driven PKCROSS there's the ability to use PAC/CAMMAC for selective disclosure of identifying information, as well as anonymous tickets (to prevent disclosure of the client's cname, but not crealm). I'm leaving this out of scope for now. The KDC can apply policy without an I-D telling it. So can the client (e.g., ask for an anon ticket, ask to include specific authz-data). It's only where the client can ask for KDC-issued/signed/vouched authz-data that we'd have a protocol to describe. > Section 5.3: > > A] do routing algorithms for network addresses take into account > "one-way connections"? I can easily see a KDC in an organization's DMZ > accepting PKCROSS, and having manually keyed cross-realm TGT from the > internal realm to the DMZ realm. The effect would be to donate > institutional users to the global Kerberos ecosystem without allowing > external users access to internal services. If they don't then it can be added into the "address" scheme. The point here was that trust paths could be constructed using OSPF and similar (I've got code lying around somewhere that applies SPF to simpified capaths data, but a protocol would be nice). IIRC ABFAB has a trust routing protocol. Active Directory has a trust router (and protocol: the information is exchanged via the AD global catalog). > B] It seems likely that connecting to an external organization will > either be a one-hop affair via PKCROSS or completely impossible. Yes (not counting the DNSSEC "hops"), which tends to lessen the need for this. I pointed that out. But it doesn't eliminate it completely, since there will remain non-fully-PKCROSS environments for a long time. > (e.g., it seems weird to permit manual keying of cross realm > principals from a realm that can PKCROSS, but not allow PKCROSS > yourself.) [...] What's weird? Asymmetry? Or something else? > [...] What would a trust router do? A trust router would be used to exchange information about x-realm principals *not* including PKCROSS *but* including information about which realms can do TGS-driven PKCROSS. The router would then use this and local policy (e.g., don't traverse any realms through realm FOO) to compute a path from a crealm to an srealm. I'm expecting that in the beginning existing sites will generally prefer to continue with whatever capaths mess they might have for policy reasons (even if they later automatically re-key their x-realm principals), with trust paths reflecting internal organization, say. But there's no reason to make this a heavily manual process other than... that's what it is and has been. Glad you liked this iteration of the I-D, and thanks for the comments, Nico -- From nobody Tue Oct 28 16:10:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA93C1A1AAE for ; Tue, 28 Oct 2014 16:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id are6mroR6g8a for ; Tue, 28 Oct 2014 16:10:37 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0971A1AB9 for ; Tue, 28 Oct 2014 16:10:30 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id D823420046B15; Tue, 28 Oct 2014 16:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QT0vfCBe+xdhGM zmSQMyzyJG53E=; b=gILqtcsyspL2iVraZXC+7h8rsDgdinRCw2PpguNhr3wbvq v2xJyShLOR3fhpVvUES5fjwGlJLVumK/qcATzprQ8cCJ1agPwl/jvTOY/J1lSoby L2ZWidLjQps8/tOM7+ftE23N0s72hZe/kSE43Q9Nbo48+3EDvMgGM8Pkoj8RA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 845172005D82E; Tue, 28 Oct 2014 16:10:29 -0700 (PDT) Date: Tue, 28 Oct 2014 18:10:28 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141028231027.GH17213@localhost> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7443E4@001FSN2MPN1-045.001f.mgd2.msft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kMTI0Ru6UV_H1WgXHvNaOBYIbYY Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:10:38 -0000 On Tue, Oct 28, 2014 at 06:32:11PM -0400, Benjamin Kaduk wrote: > On Tue, 28 Oct 2014, Nordgren, Bryce L -FS wrote: > > B] It seems likely that connecting to an external organization will > > either be a one-hop affair via PKCROSS or completely impossible. (e.g., > > it seems weird to permit manual keying of cross realm principals from a > > realm that can PKCROSS, but not allow PKCROSS yourself.) What would a > > trust router do? > > Some discussion a couple years ago about federation for the Zephyr instant > messaging protocol proposed a scheme where the GRAND.CENTRAL.ORG kerberos > realm could be a central hub for cross-realm traffic, in that it would > freely peer with ~anyone, for the asking. I don't necessarily think that > exactly that will happen, but it seems at least vaguely plausible that > smaller versions could happen, wherein, say, EXAMPLE.EDU would actively > initiate pkcross for a shared key with INTERNET2.EDU but wouldn't accept > incoming pkcross from EXAMPLE.COM. But, maybe INTERNET2.EDU would accept > that pkcross from EXAMPLE.COM, and act as a hub for cross-realm traffic. > > Just some idle speculation... I don't think it's all that idle :) For one, a realm's KDCs might not support PKCROSS for a long time, not even kx509 or similar. One could setup a realm just to handle PKCROSS to [the world] as a method of coping with the main realm's lack of support. But also, a local realm to funnel PKCROSS through could function as a "identity firewall" as Bryce mentions, and this too might be a workaround other realms' KDCs lack of "identity firewall" functionality. Nico -- From nobody Wed Oct 29 01:25:45 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2BD1A6FBC for ; Wed, 29 Oct 2014 01:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcoF5IScwF2Y for ; Wed, 29 Oct 2014 01:25:43 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C5C1A6F83 for ; Wed, 29 Oct 2014 01:25:42 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9T8PZaD060465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 09:25:36 +0100 (CET) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <20141028225025.GC9411@mournblade.imrryr.org> Date: Wed, 29 Oct 2014 09:25:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> To: Viktor Dukhovni X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ARMHdkHURoDJLQRwKJoOH8qiDXg Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 08:25:44 -0000 Viktor, Thanks! > The term "indeterminate" sadly has different meanings in RFC 4033 > and 4035. So one needs to be specific about which meaning one has > in mind. The 4035 variant is essentially a lookup failure condition, > while the 4033 variant is essentially "insecure" for lack of a = suitable > trust-anchor rather than an opt-out. I wasn=92t aware of this difference. Will dive in. > I explain that "bogus" and "indeterminate" (4035) are error conditions > are to be treated in the same way as timeouts, and other transient > problems. Yes, we do need secure denial before we can safely conclude =93it=92s = not there, let=92s try somewhere else=94. > I also explain that "NXDOMAIN" is not an error condition (given > signed proof of non-existence if the containing zone is signed). Indeed, the habit of TXT records that is currently described (but at the same time discouraged to rely on) is to try in multiple locations, = moving up from a DNS name to the DNS root. (I don=92t think passing through the zone apex is a good idea though, so I=92m changing that here.) > With that out of the way, one processes "secure" responses, treates > "insecure" responses and "NXDOMAIN" as absence of data, and treats > all other outcomes as transient errors (applying whatever logic is > appropriate in that case). Almost. =93insecure=94 leads to a complete breakdown of the process, because it is not possible to establish that a name is absent. If we=92d do as you describe, a DoS could be mounted on one label, and the next one up could be forced instead. Absense of data is important information in this search sequence and must therefore be secure. -Rick= From nobody Wed Oct 29 07:49:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29351A0177 for ; Wed, 29 Oct 2014 07:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbHTk65FrgCy for ; Wed, 29 Oct 2014 07:49:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705451A0172 for ; Wed, 29 Oct 2014 07:49:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0BF932AB24B; Wed, 29 Oct 2014 14:49:15 +0000 (UTC) Date: Wed, 29 Oct 2014 14:49:14 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029144914.GG9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Md2GV7DlTvGAeADcYz21LbkdIm0 Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:49:21 -0000 On Wed, Oct 29, 2014 at 09:25:35AM +0100, Rick van Rein wrote: > > With that out of the way, one processes "secure" responses, treates > > "insecure" responses and "NXDOMAIN" as absence of data, and treats > > all other outcomes as transient errors (applying whatever logic is > > appropriate in that case). > > Almost. ?insecure? leads to a complete breakdown of the process, > because it is not possible to establish that a name is absent. Sure, but this is expected, the domain has opted-out of DNSSEC. > If we'd do as you describe, a DoS could be mounted on one label, DoS does not cause responses to appear "insecure". It can only cause (4035) "indeterminate". > and the > next one up could be forced instead. Absense of data is important > information in this search sequence and must therefore be secure. Speaking of searches, if we're "searching" for a realm. My proposal is to avoid "searches" entirely. By introducing a new RRTYPE (not overloading TXT), we avoid all ambiguity and no longer need an "_kerberos" prefix, but more critically, it now becomes possible to usefully employ wildcard RRs: athena.mit.edu. IN KRBREALM "ATHENA.MIT.EDU" *.athena.mit.edu. IN KRBREALM "ATHENA.MIT.EDU" With this any host under athena.mit.edu gets the right realm with a *signle* DNS lookup, but sub-domains (including individual hosts) can override the data with their own wildcard: dev.athena.mit.edu. IN KRBREALM "DEV.ATHENA.MIT.EDU" The past practice of walking up the tree is both latency incurring and dubious from a security perspective. And expecting DNS clients to act differently across zone cuts is a bad idea, zone cuts are not meant to imply explicit administrative boundaries, they are just about data management. -- Viktor. From nobody Wed Oct 29 07:53:15 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33A41A0117 for ; Wed, 29 Oct 2014 07:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLp4prJMrszl for ; Wed, 29 Oct 2014 07:53:11 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 325D31A0110 for ; Wed, 29 Oct 2014 07:53:11 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id C8D72768061 for ; Wed, 29 Oct 2014 07:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=EIe2v31+FNcrisCzQUQj0mJ 8IWQ=; b=i83wSB/9SxpMptxjAj4fZCxV7NNN8IGD5g4BiuZLrLBHbzq85Cwas7o t92MCG25wJ4WlCzvV9JutvFDs0p1tGOxrW6x1Apa2fj+9pC/XnOTUmFtqHOcgPmi pJgYu5raDNvdYQeAbdY8R19PhLbJ/hHc+tsnHFx8JsMbt/mhKJ2E= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 73EA576805C for ; Wed, 29 Oct 2014 07:53:10 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id h11so1926472wiw.9 for ; Wed, 29 Oct 2014 07:53:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.73.19 with SMTP id h19mr36022898wiv.3.1414594389048; Wed, 29 Oct 2014 07:53:09 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Wed, 29 Oct 2014 07:53:08 -0700 (PDT) In-Reply-To: <20141029144914.GG9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> Date: Wed, 29 Oct 2014 09:53:08 -0500 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EB2d_xnUG3DfwetqTF4L_YLHHYE Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:53:12 -0000 FWIW, searches need not add latency. You can asynchronously fire off all the lookups needed. (Yes, I know, would that actual implementations did that.) From nobody Wed Oct 29 07:57:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C71A01A9 for ; Wed, 29 Oct 2014 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7diHOMJgjIQ for ; Wed, 29 Oct 2014 07:57:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222351A01A8 for ; Wed, 29 Oct 2014 07:57:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 72A942AB24B; Wed, 29 Oct 2014 14:57:09 +0000 (UTC) Date: Wed, 29 Oct 2014 14:57:09 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029145709.GH9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1DnVE0xfOIMemxVcOWnyjhkWb5Q Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:57:28 -0000 On Wed, Oct 29, 2014 at 09:53:08AM -0500, Nico Williams wrote: > FWIW, searches need not add latency. You can asynchronously fire off > all the lookups needed. (Yes, I know, would that actual > implementations did that.) That's fine for data you know you'll need, but abusive when it is data you almost certainly won't (_kerber.com, and the like, for example). Far cleaner to make exactly one lookup, and place the burden of reducing data duplication on the zone publisher (who can publish a wildcard). -- Viktor. From nobody Wed Oct 29 08:03:26 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46C61A0171 for ; Wed, 29 Oct 2014 08:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt7LEsyxZv7q for ; Wed, 29 Oct 2014 08:03:18 -0700 (PDT) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7D51A0242 for ; Wed, 29 Oct 2014 08:03:04 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9TF2vLi092004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 16:02:58 +0100 (CET) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <20141029144914.GG9411@mournblade.imrryr.org> Date: Wed, 29 Oct 2014 16:02:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> To: Viktor Dukhovni X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5NN_Z2m4RzHUqGeQRAoPbn-a3fE Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:03:20 -0000 Ah! >> Almost. ?insecure? leads to a complete breakdown of the process, >> because it is not possible to establish that a name is absent. >=20 > Sure, but this is expected, the domain has opted-out of DNSSEC. This is a vital point. DNS records are not reliable for this purpose if they are not signed. DNSSEC is a MUST for this entire process. >> If we'd do as you describe, a DoS could be mounted on one label, >=20 > DoS does not cause responses to appear "insecure". It can only > cause (4035) "indeterminate=94. Sorry, I meant Kaminsky =97 which is an overdose of responses, but indeed not quite the same as a DoS. > Speaking of searches, if we're "searching" for a realm. My proposal > is to avoid "searches" entirely. By introducing a new RRTYPE (not > overloading TXT), we avoid all ambiguity and no longer need an > "_kerberos" prefix, but more critically, it now becomes possible > to usefully employ wildcard RRs: >=20 > athena.mit.edu. IN KRBREALM "ATHENA.MIT.EDU" > *.athena.mit.edu. IN KRBREALM =93ATHENA.MIT.EDU" I dropped the _kerberos prefix too, which was possible by starting the TXT record with =93v=3Dkrb1=94 =97 and the draft actually wildcards, = just as you say. The one difference: *.a.m.e is only required for overrides of the a.m.e =97 and there is an option to say =93no realm for this one=94= of course. That=92s a different default, but it=92s just as expressive = as what you=92re saing here. You are not the first to suggest a separate record type, and I prefer it too, was just a bit scared for claiming such a valuable resource. Then again, SPF does it too, and is similar in nature. And it started as TXT, so we=92ll see that forever... > With this any host under athena.mit.edu gets the right realm with > a *signle* DNS lookup, but sub-domains (including individual hosts) > can override the data with their own wildcard: >=20 > dev.athena.mit.edu. IN KRBREALM =93DEV.ATHENA.MIT.EDU" Yes, a single DNS lookup instead of two as I propose in the draft. > The past practice of walking up the tree is both latency incurring > and dubious from a security perspective. I=92m glad you agree with that idea of the draft. > And expecting DNS clients > to act differently across zone cuts is a bad idea, zone cuts are > not meant to imply explicit administrative boundaries, they are > just about data management. Really? The wording =93SOA=94 is =93Start Of Authority=94, which is = just what triggers the thought of looking in the zone apex. Thanks for thinking along, -Rick= From nobody Wed Oct 29 08:06:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847D41A038D for ; Wed, 29 Oct 2014 08:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.093 X-Spam-Level: ** X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HkGLhFDBgTA for ; Wed, 29 Oct 2014 08:06:27 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B4B1A0367 for ; Wed, 29 Oct 2014 08:06:26 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9TF6K72059622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 16:06:21 +0100 (CET) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <20141029145709.GH9411@mournblade.imrryr.org> Date: Wed, 29 Oct 2014 16:06:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <32C9E297-D61C-4175-A665-A02CA9337C7D@openfortress.nl> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <20141029145709.GH9411@mournblade.imrryr.org> To: Viktor Dukhovni X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4pWwFzG3Dr1dP43naTks7JBoVJ4 Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:06:29 -0000 Viktor, On 29 Oct 2014, at 15:57, Viktor Dukhovni = wrote: > On Wed, Oct 29, 2014 at 09:53:08AM -0500, Nico Williams wrote: >=20 >> FWIW, searches need not add latency. You can asynchronously fire off >> all the lookups needed. (Yes, I know, would that actual >> implementations did that.) >=20 > That's fine for data you know you'll need, but abusive when it is > data you almost certainly won't (_kerber.com, and the like, for > example). That doesn=92t apply in my draft; there=92s going to be two lookups max. I=92m learning that that isn=92t immediately obvious from my text. > Far cleaner to make exactly one lookup, and place the > burden of reducing data duplication on the zone publisher (who > can publish a wildcard). Am thinking that option through. Wildcards are nasty beasts that I = would prefer not to rely on very heavily, as in, for the standard case. = Especially their combination with DNSSEC is solved, but very, very hairy. -Rick From nobody Wed Oct 29 08:12:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B181A03AA for ; Wed, 29 Oct 2014 08:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.594 X-Spam-Level: * X-Spam-Status: No, score=1.594 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDY7YF7GhM9W for ; Wed, 29 Oct 2014 08:12:37 -0700 (PDT) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4E51A03A6 for ; Wed, 29 Oct 2014 08:12:36 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9TFCUI5001744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 16:12:31 +0100 (CET) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: Date: Wed, 29 Oct 2014 16:12:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0827BD06-E1F8-49F6-8952-B14CF628642E@openfortress.nl> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UkYiFj_17vaBr4V7wdu6d6QoJZI Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:12:38 -0000 Nico, > FWIW, searches need not add latency. You can asynchronously fire off > all the lookups needed. (Yes, I know, would that actual > implementations did that.) It=92s not hard to implement with adns. But it won=92t work in the = specific case on dnstxt-krb1, which pulls the zone apex name from the failure and then issues the second query at that point in the DNS. -Rick= From nobody Wed Oct 29 08:27:55 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA741A0410 for ; Wed, 29 Oct 2014 08:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_oqqiZvgjBm for ; Wed, 29 Oct 2014 08:27:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1031A0378 for ; Wed, 29 Oct 2014 08:27:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 79E4B2AB24B; Wed, 29 Oct 2014 15:27:45 +0000 (UTC) Date: Wed, 29 Oct 2014 15:27:45 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029152745.GJ9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <20141029145709.GH9411@mournblade.imrryr.org> <32C9E297-D61C-4175-A665-A02CA9337C7D@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32C9E297-D61C-4175-A665-A02CA9337C7D@openfortress.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pbtjrrhI8PAnHgj2jQwPbm6L4Vo Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:27:51 -0000 On Wed, Oct 29, 2014 at 04:06:19PM +0100, Rick van Rein wrote: > > Far cleaner to make exactly one lookup, and place the > > burden of reducing data duplication on the zone publisher (who > > can publish a wildcard). > > Am thinking that option through. Wildcards are nasty beasts that I would > prefer not to rely on very heavily, as in, for the standard case. Especially > their combination with DNSSEC is solved, but very, very hairy. At this point, wildcards are well behaved with DNSSEC. There exist unofficial DNSSEC patch-sets for djbdns servers that get wildcards wrong. Operators of such servers need to avoid wildcards or switch to an RFC-compliant server. Otherwise, for the vast majority of domains wildcards work just fine. -- Viktor. From nobody Wed Oct 29 08:30:44 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D951A035F for ; Wed, 29 Oct 2014 08:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.7 X-Spam-Level: X-Spam-Status: No, score=-100.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSkVcdiYKZuX for ; Wed, 29 Oct 2014 08:30:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B351A023E for ; Wed, 29 Oct 2014 08:30:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BB66A2AB24B; Wed, 29 Oct 2014 15:30:32 +0000 (UTC) Date: Wed, 29 Oct 2014 15:30:32 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029153032.GK9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <0827BD06-E1F8-49F6-8952-B14CF628642E@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0827BD06-E1F8-49F6-8952-B14CF628642E@openfortress.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/FRYSYyBXHvX1phaRmZhZeeAIzCM Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:30:40 -0000 On Wed, Oct 29, 2014 at 04:12:29PM +0100, Rick van Rein wrote: > It?s not hard to implement with adns. But it won?t work in the specific case > on dnstxt-krb1, which pulls the zone apex name from the failure and then > issues the second query at that point in the DNS. This is not a good idea. The zone apex can be too far removed from the leaf node. There is no mandate for a zone cut at every non-leaf label. You're reading too much structure into the incidental division of DNS data into zones. Don't do that! -- Viktor. From nobody Wed Oct 29 08:35:25 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141AD1A0258 for ; Wed, 29 Oct 2014 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.093 X-Spam-Level: ** X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5_RTT1yoSIN for ; Wed, 29 Oct 2014 08:35:16 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B4C1A0217 for ; Wed, 29 Oct 2014 08:35:15 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9TFZ9Fc083002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 16:35:10 +0100 (CET) (envelope-from rick@openfortress.nl) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rick van Rein In-Reply-To: <20141029153032.GK9411@mournblade.imrryr.org> Date: Wed, 29 Oct 2014 16:35:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6279CA8B-0A52-4F20-8F68-406C0CEF7DCA@openfortress.nl> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <0827BD06-E1F8-49F6-8952-B14CF628642E@openfortress.nl> <20141029153032.GK9411@mournblade.imrryr.org> To: kitten@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/jJOpz2F36eTvTcOQD3NcLlo3QEs Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:35:22 -0000 Hi, > The zone apex can be too far removed from > the leaf node. There is no mandate for a zone cut at every non-leaf > label. Understood, but that is not a problem. As far as wildcards go, I=92m concerned about schemes that overlap: *.a.b.c.com IN TXT =93v=3Dkrb1=94 = ; no realm for anything under a.b.c.com *.b.c.com IN TXT =93v=3Dkrb1;r=3DEXAMPLE.COM=94 = ; realm EXAMPLE.COM for anything under b.c.com b.c.com IN TXT =93v=3Dkrb1;r=3DEXAMPLE.ORG=94 ; realm = EXAMPLE.ORG for exact match of b.c.com > You're reading too much structure into the incidental > division of DNS data into zones. Don't do that! I don=92t understand the underlying argument that must be underlying = this. -Rick= From nobody Wed Oct 29 08:44:14 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5019D1A1A42 for ; Wed, 29 Oct 2014 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9apxmozfBOdg for ; Wed, 29 Oct 2014 08:44:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25091A1A45 for ; Wed, 29 Oct 2014 08:43:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3EEA92AB24B; Wed, 29 Oct 2014 15:43:59 +0000 (UTC) Date: Wed, 29 Oct 2014 15:43:59 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029154358.GM9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <0827BD06-E1F8-49F6-8952-B14CF628642E@openfortress.nl> <20141029153032.GK9411@mournblade.imrryr.org> <6279CA8B-0A52-4F20-8F68-406C0CEF7DCA@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6279CA8B-0A52-4F20-8F68-406C0CEF7DCA@openfortress.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qO6lATnj_GpuseZkuBLgApsD-y4 Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:44:09 -0000 On Wed, Oct 29, 2014 at 04:35:08PM +0100, Rick van Rein wrote: > Hi, > > > The zone apex can be too far removed from > > the leaf node. There is no mandate for a zone cut at every non-leaf > > label. > > Understood, but that is not a problem. > > As far as wildcards go, I?m concerned about schemes that overlap: > > *.a.b.c.com IN TXT ?v=krb1? ; no realm for anything under a.b.c.com I was assuming you're not going to continue to abuse TXT records. Sorry, have not yet read the proposal in detail. The DNS folks at IETF are IIRC discouraging TXT overloading. If we're implementing a new DNSSEC-based realm-of-host mapping, that is in any case different from the ad-hoc MIT and Heimdal feature, then I think this needs its own RRTYPE, which removes the ambiguity. Otherwise, you need to employ "_kerberos." prefixes, which IIRC still work with DNSSEC wildcards: _kerberos.*.example.com. IN KRBREALM ... but we should not need to go there. -- Viktor. From nobody Wed Oct 29 09:01:35 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B4F1A1ADA for ; Wed, 29 Oct 2014 09:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.601 X-Spam-Level: X-Spam-Status: No, score=-97.601 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us75H3KUf81A for ; Wed, 29 Oct 2014 09:01:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442C91A1AE7 for ; Wed, 29 Oct 2014 09:01:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3B82B2AB24B; Wed, 29 Oct 2014 16:01:28 +0000 (UTC) Date: Wed, 29 Oct 2014 16:01:28 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029160128.GO9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mzwubGld8fwgYDheTsIIQiUwFjc Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:01:33 -0000 On Wed, Oct 29, 2014 at 04:02:56PM +0100, Rick van Rein wrote: > >> If we'd do as you describe, a DoS could be mounted on one label, > > > > DoS does not cause responses to appear "insecure". It can only > > cause (4035) "indeterminate?. > > Sorry, I meant Kaminsky ? which is an overdose of responses, but > indeed not quite the same as a DoS. This still can't cause responses to appear "insecure", rather MiTM attacks can cause "insecure" results to be altered. That's to be expected. Therefore, "insecure" results are treated as absent (are ignored whether modified or not). > I dropped the _kerberos prefix too, which was possible by starting > the TXT record with ?v=krb1? ? and the draft actually wildcards, just > as you say. The one difference: *.a.m.e is only required for overrides > of the a.m.e ? and there is an option to say ?no realm for this one? > of course. That?s a different default, but it?s just as expressive as > what you?re saing here. I would avoid overloading TXT records, define an appropriate RRTYPE carrying a realm and whatever other data you deem appropriate. Ideally a structured RRTYPE rather than just text interpreted by the client. > You are not the first to suggest a separate record type, and I prefer > it too, was just a bit scared for claiming such a valuable resource. On the contrary, this is NOT a valuable resource, there 64K possible RRtypes, we are far from exhausting any significant fraction. > Then again, SPF does it too, and is similar in nature. And it started > as TXT, so we?ll see that forever... The guidance was improved since SPF. And you don't want to fetch and discard all that SPF bloat on every kerberos realm query. > > And expecting DNS clients > > to act differently across zone cuts is a bad idea, zone cuts are > > not meant to imply explicit administrative boundaries, they are > > just about data management. > > Really? The wording ?SOA? is ?Start Of Authority?, which is just > what triggers the thought of looking in the zone apex. SOA is not meant to imply anything other than "this is a zone cut". This carries no application semantics. -- Viktor. From nobody Wed Oct 29 10:03:40 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA931A6F01 for ; Wed, 29 Oct 2014 10:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meGUw3OvzFLs for ; Wed, 29 Oct 2014 10:03:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BD71A1BCF for ; Wed, 29 Oct 2014 10:03:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4DD672AB24B; Wed, 29 Oct 2014 17:03:01 +0000 (UTC) Date: Wed, 29 Oct 2014 17:03:01 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029170301.GP9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029160128.GO9411@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4DRa_ZsQuJuOLYCvD1iLZlSegM4 Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:03:38 -0000 On Wed, Oct 29, 2014 at 04:01:28PM +0000, Viktor Dukhovni wrote: > I would avoid overloading TXT records, define an appropriate RRTYPE > carrying a realm and whatever other data you deem appropriate. > Ideally a structured RRTYPE rather than just text interpreted by > the client. http://tools.ietf.org/html/rfc7208#section-3.1 The circumstances surrounding SPF's initial deployment a decade ago are unique. If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers. Further discussion of design considerations when using new DNS RR types can be found in [RFC5507]. Note, the still-born "SPF" RRtype carries textual data, so that remains an option, but if we are confident what information we want to convey in a kerberos realm record, it would be better if that were more strictly structured. Should realm names carried in DNSSEC be (for example) restricted to be well-formed DNS domains? Otherwise how does one find the KDCs for said realms? What are the IDNA issues for realm names? Should the realm be in A-label or unicode form? These issues need a bit more thought. -- Viktor. From nobody Wed Oct 29 10:20:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC51A6FCB for ; Wed, 29 Oct 2014 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NssGzYAmXvi0 for ; Wed, 29 Oct 2014 10:20:11 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437041A6FC9 for ; Wed, 29 Oct 2014 10:20:11 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9THK7GZ096675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Oct 2014 18:20:08 +0100 (CET) (envelope-from rick@openfortress.nl) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rick van Rein In-Reply-To: <20141029160128.GO9411@mournblade.imrryr.org> Date: Wed, 29 Oct 2014 18:20:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> To: kitten@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TuZ1ti8kcTaUid8N8SwbAfbgzCw Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:20:14 -0000 Hi, As it turns out, wildcards in DNS won=92t work at all, not even as the simple variation that I defined. RFC 4592, "The Role of Wildcards in the Domain Name System=94 explains that the exitence of a name will stop the wildcard at that name, and any subname, from functioning. This is true even if the existing name has a different RRtype than the one queried and carried by the wildcard. I also tried this out on my ods-signerd -> nsd chain: *.wildcarddemo 3600 IN TXT "voorbeeldje" a.wildcarddemo 3600 IN TXT "subvoorbeeldje" b.wildcarddemo 3600 IN A 123.45.67.89 dig a.wildcarddemo txt -> NOERROR, TXT =93subvoorbeeldje=94 dig b.wildcarddemo txt -> NOERROR, (no data) dig c.wildcarddemo txt -> NOERROR, TXT =93voorbeeldje=94 dig d.wildcarddemo txt -> NOERROR, TXT =93voorbeeldje=94 The same when querying x.y.z.a=85, x.y.z.b=85 and so on. And, in our situation we start from a server. Usually, that=92ll mean we have an AAAA record, and perhaps also one of those old A records ;-) But we cannot use the same name, or with _kerberos prefixed, to find a wildcard for the realm. Going up one level is not safe either, you might land in another realm of control of security. The primary option is to define the realm name record exactly for the servername, without wildcard. A lot of work, but linear in the number of services, so doable in itself. To optimise admin chores, the only solution that I see is to look at the verified denial to find a =93central=94 place of authority. 1) Look at the RRSIG, it holds the zone apex, usually, as a pointer to the DNSKEY records. 2) Look at the SOA that is usually sent along with NXDOMAIN, and which is also validated; it holds the zone apex. SOA is an optional, but common additional bit of information. It might be said that an admin should either use a =93neat=94 DNS server or otherwise specify the Kerberos realm for each of his hosts, but that is not very friendly. Of the two, RRSIG is more certain, less likely to be cut off and it mirrors trust relationships. The one in charge of your DNSKEY is the one who can decide where to point clients at, so it is not such a wild thought to be using that reference to find the realm name in a =93central=94 place. (Note that whatever notion of =93central=94= you pick, there are going to be paranoid schemes. They can all be circumvented by a =93normal=94 DNS setup and/or adding explicit realm name records for a servername.) Now, it is a matter of taste whether we should want this to save the work of the DNS admin, who already sets up one or more AAAA records, one or more A record, and should now add a realm descriptor as well. Cheers, -Rick= From nobody Wed Oct 29 10:33:53 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F421A8715 for ; Wed, 29 Oct 2014 10:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rpaT7Kc8QOa for ; Wed, 29 Oct 2014 10:33:43 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 495861A86FD for ; Wed, 29 Oct 2014 10:33:16 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 0BFCD20046915 for ; Wed, 29 Oct 2014 10:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=3SJazLOT7TKu8Pgp+F2bB8VaAVU =; b=Cz64cHdCarGrK+omIEljB8vvR1MAsRN+NJjY/JTYfVC1Z4TdKJXwcUFzXUl H5byDRklyYIv0GzBKU6qwickFwdoXZO+jjRq84cScQaZhNin5wQF2E/k0I1XmjOu ZdriV5ys6fJuAsxOjXH4bcDM/52kVLNO3aTxCPOE/OSZs7BU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id CFAF220047D12 for ; Wed, 29 Oct 2014 10:33:15 -0700 (PDT) Date: Wed, 29 Oct 2014 12:33:15 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141029173313.GI17213@localhost> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029170301.GP9411@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sy1DqOn45MsAUdvw3dqlSNJJ2wM Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:33:50 -0000 On Wed, Oct 29, 2014 at 05:03:01PM +0000, Viktor Dukhovni wrote: > Should realm names carried in DNSSEC be (for example) restricted > to be well-formed DNS domains? Otherwise how does one find the > KDCs for said realms? > > What are the IDNA issues for realm names? Should the realm be in > A-label or unicode form? Oh no, you went there :) The Kerberos community tried to tackle the I18N issues in 2002 and it was too soon and ETOOHARD; I18N got dropped. I was talking to Tom about this the other day. PKCROSS and Rick's I-Ds will force us to reckon with I18N, finally. My strawman: - Declare uses of Kerberos protocol elements to carry domainnames or DOMAIN-style realm names to be IDNA-unaware domainname slots: they may NOT carry U-labels; ToASCII() must be used. For example: - in RFC4120 Realm slots: use A-labels only for DOMAIN-style[0] realm-names, with all labels up-cased (to follow existing convention, why not?); - in RFC4120 PrincipalName name-string slots of host-based names (NT-SRV-HST[1]), use A-labels only for hostnames. The alternative would be to say that hey, existing implementations are putting UTF-8 (let's not speak much of just-send-8 non-UTF-8 uses) in these IA5String elements and we have no choice but to standardize that, ugly and ASN.1 tool breaking though that might be. - Do something about interop with existing just-send-UTF-8 (and maybe some non-UTF-8, non-ASCII?) realms and principals. My preference would be to give some advice as to how to "alias" realms (e.g., make full use of ETYPE-INFO2), and let the implementors figure out the rest (it's doable). How much normative and informative text to write about this is to be seen. - The GSS-API needs an update to say that the buffers used for import/export name are in the caller's locale (not "Latin-1"), OR add new variants of those functions that use the caller's locale AND/OR add new variants that only use UTF-8. In first case the hostname slots (in host-based type name-types' generic syntax) must be IDNA-aware, while in the latter case then the hostname slots in the originals surely must be IDNA-unaware (right?). - Make klist, and related UIs apply ToUnicode for display purposes. The details here are not relevant on this list. But there are a lot of API details, e.g., does krb5_sname_to_principal() apply ToASCII(), or its callers? do krb5_unparse_name*() apply ToUnicode? Surely they must! But what about changing the name-type of a krb5_principle to/from NT-SRV-HST? And so on. There's probably more to it than this, but this is just idle musing without too careful analysis (though informed by many past discussions of the matter). Nico [0] Whereas when using a Realm element to carry an X.500-style realm name then presumably RFC5280 rules would apply, except that in RFC5280 RDNs can be UTF8String, but Realm is a KerberosString, which is an IA5String, so presumably *all* domainname label slots -by convention or otherwise- in a Realm, must be treated as IDNA-unaware. Thankfully we don't have a lot of X.500-style realm use...) [1] Ditto NT-SRV-XHST, except that thankfully that is not used. From nobody Wed Oct 29 10:36:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5631A701A for ; Wed, 29 Oct 2014 10:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTOvJP7bjR21 for ; Wed, 29 Oct 2014 10:36:11 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A7A6E1A8732 for ; Wed, 29 Oct 2014 10:35:38 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id E1A0620047B83 for ; Wed, 29 Oct 2014 10:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=+3e+3UY0fUMdpdquH7NqbEdjEYg =; b=REVDvGIJig1+utPYp1V1B+K8dxL9G6za92ZyAYKUq21VNd3IvaoQqleZq5U uDXFtyeaLgcIiLYNHpDQYzDUK9ec+6hIHUxkQNUf7MvpsSCVwKkT/Nqve5qvozwp 5rxkJO8xjHnFrxy2f6KAT9i2LcGfjetK7qtBsTpXdqd0jH2Q= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id AFA4620047B80 for ; Wed, 29 Oct 2014 10:35:37 -0700 (PDT) Date: Wed, 29 Oct 2014 12:35:37 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141029173535.GJ17213@localhost> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029173313.GI17213@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/eEfBzH_S33I0D48FUOGHxd_453Q Subject: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:36:14 -0000 Oy! I meant to change the Subject. Please respond to this message for proper threading, or else change the Subject. On Wed, Oct 29, 2014 at 05:03:01PM +0000, Viktor Dukhovni wrote: > Should realm names carried in DNSSEC be (for example) restricted > to be well-formed DNS domains? Otherwise how does one find the > KDCs for said realms? > > What are the IDNA issues for realm names? Should the realm be in > A-label or unicode form? Oh no, you went there :) The Kerberos community tried to tackle the I18N issues in 2002 and it was too soon and ETOOHARD; I18N got dropped. I was talking to Tom about this the other day. PKCROSS and Rick's I-Ds will force us to reckon with I18N, finally. My strawman: - Declare uses of Kerberos protocol elements to carry domainnames or DOMAIN-style realm names to be IDNA-unaware domainname slots: they may NOT carry U-labels; ToASCII() must be used. For example: - in RFC4120 Realm slots: use A-labels only for DOMAIN-style[0] realm-names, with all labels up-cased (to follow existing convention, why not?); - in RFC4120 PrincipalName name-string slots of host-based names (NT-SRV-HST[1]), use A-labels only for hostnames. The alternative would be to say that hey, existing implementations are putting UTF-8 (let's not speak much of just-send-8 non-UTF-8 uses) in these IA5String elements and we have no choice but to standardize that, ugly and ASN.1 tool breaking though that might be. - Do something about interop with existing just-send-UTF-8 (and maybe some non-UTF-8, non-ASCII?) realms and principals. My preference would be to give some advice as to how to "alias" realms (e.g., make full use of ETYPE-INFO2), and let the implementors figure out the rest (it's doable). How much normative and informative text to write about this is to be seen. - The GSS-API needs an update to say that the buffers used for import/export name are in the caller's locale (not "Latin-1"), OR add new variants of those functions that use the caller's locale AND/OR add new variants that only use UTF-8. In first case the hostname slots (in host-based type name-types' generic syntax) must be IDNA-aware, while in the latter case then the hostname slots in the originals surely must be IDNA-unaware (right?). - Make klist, and related UIs apply ToUnicode for display purposes. The details here are not relevant on this list. But there are a lot of API details, e.g., does krb5_sname_to_principal() apply ToASCII(), or its callers? do krb5_unparse_name*() apply ToUnicode? Surely they must! But what about changing the name-type of a krb5_principle to/from NT-SRV-HST? And so on. There's probably more to it than this, but this is just idle musing without too careful analysis (though informed by many past discussions of the matter). Nico [0] Whereas when using a Realm element to carry an X.500-style realm name then presumably RFC5280 rules would apply, except that in RFC5280 RDNs can be UTF8String, but Realm is a KerberosString, which is an IA5String, so presumably *all* domainname label slots -by convention or otherwise- in a Realm, must be treated as IDNA-unaware. Thankfully we don't have a lot of X.500-style realm use...) [1] Ditto NT-SRV-XHST, except that thankfully that is not used. From nobody Wed Oct 29 10:43:49 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BC21A870E for ; Wed, 29 Oct 2014 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.9 X-Spam-Level: X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTaLqQAYo-Wf for ; Wed, 29 Oct 2014 10:43:48 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116771A854D for ; Wed, 29 Oct 2014 10:43:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 28FC62AB24B; Wed, 29 Oct 2014 17:43:47 +0000 (UTC) Date: Wed, 29 Oct 2014 17:43:47 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141029174346.GQ9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7NvyllGfFR-PnFYtxei48gWTi4Q Subject: Re: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:43:49 -0000 On Wed, Oct 29, 2014 at 06:20:06PM +0100, Rick van Rein wrote: > As it turns out, wildcards in DNS won?t work at all, not even as the > simple variation that I defined. Yes, of course you're right about that. I lost track of that important detail. I still don't like imputing the zone apex from the SOA, and skipping intermediate sub-domains. -- Viktor. From nobody Wed Oct 29 13:00:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757E21A88E4 for ; Wed, 29 Oct 2014 13:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrUWLoY9VUSG for ; Wed, 29 Oct 2014 13:00:25 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F19BB1A88CE for ; Wed, 29 Oct 2014 13:00:24 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 9A7B621DE59 for ; Wed, 29 Oct 2014 13:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=TOJ612UuUIDIvtpTJ39FiWz vN2I=; b=Q9Y5IeCLhp1m6PfRumXpo7f2oqf8CWvPUmG5rslkeH+xNAgyIFqfB5Y P0aYouaMCiiOHoOXqVHSXu+jJzq0C3Sw8C6JWq2QHldFWMQXMDrgOPEUC6IrRNIF 2XHEfWgRZVuQZ5LOTLoLtdIrh7Asi9mDaZ0QaTgF8Rrimgvt3+/A= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 4A87021DE58 for ; Wed, 29 Oct 2014 13:00:24 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id q5so5584329wiv.17 for ; Wed, 29 Oct 2014 13:00:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.8.98 with SMTP id dj2mr14998560wid.70.1414612823073; Wed, 29 Oct 2014 13:00:23 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Wed, 29 Oct 2014 13:00:23 -0700 (PDT) In-Reply-To: <20141029173535.GJ17213@localhost> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> Date: Wed, 29 Oct 2014 15:00:23 -0500 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RZc-a-iVvuySfr8SF34uuWgcEm4 Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:00:27 -0000 BTW, I'm not opposed to just using UTF-8 in the RFC4120 IA5String slots. It'd be hacky, but all of the existing implementations... fail to limit themselves to printable ASCII in those slots, and it's difficult to ignore reality. But declaring those slots to be IDNA-unaware is the orthodox approach, and we should first convince ourselves that the orthodox approach is unworkable before we take the unorthodox path. From nobody Wed Oct 29 13:42:10 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB231A8AC0 for ; Wed, 29 Oct 2014 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9NE89Yy-2f8 for ; Wed, 29 Oct 2014 13:42:07 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAFE1A8ABF for ; Wed, 29 Oct 2014 13:42:07 -0700 (PDT) Received: from [192.168.0.8] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (smtp internal) via TCP with ESMTPA id ; Wed, 29 Oct 2014 20:42:05 +0000 X-RBL-Found: 25.84.234.92.zen.spamhaus.org. (127.0.0.10) References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> <53D18F6F.1060204@att.com> <53E47603.3080302@oracle.com> <53E58D77.1020100@att.com> <20140809110713.0955eff3@latte.josefsson.org> <544E9D89.5060704@att.com> In-Reply-To: <544E9D89.5060704@att.com> Message-Id: <3EB51C67-2FC3-4538-9F97-B3B11669FCDD@isode.com> X-Mailer: iPhone Mail (11B651) From: Alexey Melnikov Date: Wed, 29 Oct 2014 20:43:37 +0000 To: Tony Hansen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tIWnDXoNGLRBfqYDZhnMMt_Ro6E Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256-02 posted X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:42:08 -0000 Hi Tony, > On 27 Oct 2014, at 19:31, Tony Hansen wrote: >=20 > I've updated draft-hansen-scram-sha256. I left the minimum iteration count= at 4096. I left it as IESG review. >=20 > I would like to send this to the Security ADs, who have previously indicat= ed that one of them would be willing to support it. >=20 > This process would go smoother if there were a document shepherd. Is anyon= e on this mailing list willing to act as document shepherd? I can do. > Tony >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Wed Oct 29 14:26:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96601A9079 for ; Wed, 29 Oct 2014 14:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00O_qMksBjmI for ; Wed, 29 Oct 2014 14:26:33 -0700 (PDT) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E586F1A9076 for ; Wed, 29 Oct 2014 14:26:32 -0700 (PDT) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5 TLS/8.14.5) with ESMTP id s9TLQWDq010459 for ; Wed, 29 Oct 2014 14:26:32 -0700 Received: from njcdtl04th1395.itservices.sbc.com ([135.91.110.221]) by maillennium.att.com (mailgw1) with ESMTP id <20141029212631gw100r93d9e>; Wed, 29 Oct 2014 21:26:32 +0000 X-Originating-IP: [135.91.110.221] Message-ID: <54515B87.9040108@att.com> Date: Wed, 29 Oct 2014 17:26:31 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexey Melnikov References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> <53D18F6F.1060204@att.com> <53E47603.3080302@oracle.com> <53E58D77.1020100@att.com> <20140809110713.0955eff3@latte.josefsson.org> <544E9D89.5060704@att.com> <3EB51C67-2FC3-4538-9F97-B3B11669FCDD@isode.com> In-Reply-To: <3EB51C67-2FC3-4538-9F97-B3B11669FCDD@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OwgXO0CXaebtgisxvzYbXgb6cno Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256-02 posted X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:26:35 -0000 On 10/29/14, 4:43 PM, Alexey Melnikov wrote: > Hi Tony, > >> On 27 Oct 2014, at 19:31, Tony Hansen wrote: >> >> I've updated draft-hansen-scram-sha256. I left the minimum iteration count at 4096. I left it as IESG review. >> >> I would like to send this to the Security ADs, who have previously indicated that one of them would be willing to support it. >> >> This process would go smoother if there were a document shepherd. Is anyone on this mailing list willing to act as document shepherd? > I can do. Thank you Alexey. More offline. Tony From nobody Wed Oct 29 14:41:51 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750E81A90B3 for ; Wed, 29 Oct 2014 14:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFPRw7j8NKzU for ; Wed, 29 Oct 2014 14:41:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:753]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BE21A90EB for ; Wed, 29 Oct 2014 14:41:42 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 29 Oct 2014 21:41:19 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.232]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.232]) with mapi id 15.01.0011.000; Wed, 29 Oct 2014 21:41:19 +0000 From: Michiko Short To: Nico Williams Thread-Topic: [kitten] Comments requested on draft-short-pkinit-freshness-00 Thread-Index: Ac/yJtbghGzsElT3RuOdLMFKYwVjJgALYwuAAB3TBdAAAIupAAAAezyAAAAm5AAACaaAUAAAVvyAADIPPeA= Date: Wed, 29 Oct 2014 21:41:19 +0000 Message-ID: <7e844f1b4e9445c6a5784f28ce983e5e@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> <67800303b1294cddbd36d3add529844a@BL2PR03MB212.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [131.107.159.24] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(13464003)(24454002)(189002)(101416001)(110136001)(76576001)(106356001)(93886004)(107046002)(120916001)(99286002)(76482002)(95666004)(77096002)(108616004)(54356999)(105586002)(86612001)(230783001)(31966008)(64706001)(122556002)(4396001)(2656002)(97736003)(21056001)(46102003)(74316001)(50986999)(87936001)(19580405001)(66066001)(85306004)(80022003)(86362001)(76176999)(33646002)(20776003)(99396003)(92566001)(19580395003)(40100003)(85852003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/L6fNMCs6LvCnF9-Nn3v9BtdtqQI Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:41:48 -0000 Rm9yIFdpbmRvd3Mgd2UgcHVibGlzaCBtb3JlIGRldGFpbGVkIHNwZWNpZmljYXRpb25zIHZpYSB0 aGUgcHJvdG9jb2wgdGVjaG5pY2FsIGRvY3VtZW50cyB3aGljaCBpcyB3aGVyZSBJIHBsYW5uZWQg dG8gcHVibGlzaCBvdXIgdmVyc2lvbiBvZiB0aGUgc3RydWN0dXJlLiBJIGp1c3QgZG9uJ3QgdGhp bmsgaXQgaXMgcmVxdWlyZWQgZm9yIHRoZSBzdGFuZGFyZC4gDQoNCldlIGNhbiBoYXZlIGEgc2Vw YXJhdGUgc3RhbmRhcmQocykgZm9yIHRoZSBkYXRhIHN0cnVjdHVyZS4gSXQgd2FzIG5vdCBjbGVh ciBpZiB5b3UgdGhvdWdodCB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlIGFub3RoZXIgdmVyc2lvbiBm b3IgUEtDcm9zcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pY28gV2ls bGlhbXMgW21haWx0bzpuaWNvQGNyeXB0b25lY3Rvci5jb21dIA0KU2VudDogVHVlc2RheSwgT2N0 b2JlciAyOCwgMjAxNCAyOjQ1IFBNDQpUbzogTWljaGlrbyBTaG9ydA0KQ2M6IEdyZWcgSHVkc29u OyBraXR0ZW5AaWV0Zi5vcmc7IEFuZHJlaSBQb3Bvdg0KU3ViamVjdDogUmU6IFtraXR0ZW5dIENv bW1lbnRzIHJlcXVlc3RlZCBvbiBkcmFmdC1zaG9ydC1wa2luaXQtZnJlc2huZXNzLTAwDQoNCk9u IFR1ZSwgT2N0IDI4LCAyMDE0IGF0IDQ6MzggUE0sIE1pY2hpa28gU2hvcnQgPG1pY2hpa29zQG1p Y3Jvc29mdC5jb20+IHdyb3RlOg0KPiBBaCwgc28gdGhlbiBoYXZpbmcgYSBtaXggb2YgS0RDIGlt cGxlbWVudGF0aW9ucyBpcyBzdXBwb3J0ZWQgb3RoZXIgdGhhbiB3aXRoIFdpbmRvd3MgQUQgZG9t YWlucz8NCg0KRldJVywgdGhlcmUgaGF2ZSBiZWVuIGFsdGVybmF0aXZlIGltcGxlbWVudGF0aW9u cyBvZiBXaW5kb3dzIERDcyB0b28sIHRob3VnaCBJIGRvbid0IGtub3cgaWYgYW55IG9mIHRoZW0g aGF2ZSBzdXBwb3J0ZWQgbWl4ZWQgaW1wbGVtZW50YXRpb25zIGZvciB0aGUgc2FtZSBkb21haW4u DQoNCkkgd291bGQgZmF2b3IgYW4gb3B0aW9uYWwgc3RhbmRhcmQgZm9yIHRoZSBmcmVzaG5lc3Mg dG9rZW4ncyBzdHJ1Y3R1cmUuDQoNCk5pY28NCi0tDQo= From nobody Wed Oct 29 14:44:35 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABA01A8766 for ; Wed, 29 Oct 2014 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.997 X-Spam-Level: * X-Spam-Status: No, score=1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqNbhV5Pwp3U for ; Wed, 29 Oct 2014 14:44:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::796]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C41A1A90AD for ; Wed, 29 Oct 2014 14:44:31 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 29 Oct 2014 21:44:08 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.232]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.232]) with mapi id 15.01.0011.000; Wed, 29 Oct 2014 21:44:08 +0000 From: Michiko Short To: Nico Williams Thread-Topic: [kitten] Comments requested on draft-short-pkinit-freshness-00 Thread-Index: Ac/yJtbghGzsElT3RuOdLMFKYwVjJgALYwuAAB3TBdAAAIupAAAAezyAAAAm5AAABQShgAABnCuAAAMsrJAAAIH5gAAx6a9w Date: Wed, 29 Oct 2014 21:44:08 +0000 Message-ID: <857f1bc9d74548b28aa127bc7e1c3f4d@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> <70f776594ee74b5fb2cf8e3114450b9b@BL2PR03MB212.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [131.107.159.24] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(377454003)(189002)(13464003)(122556002)(66066001)(230783001)(108616004)(40100003)(80022003)(106356001)(46102003)(95666004)(86362001)(99286002)(54356999)(101416001)(105586002)(92566001)(85306004)(93886004)(97736003)(64706001)(20776003)(86612001)(77096002)(50986999)(76176999)(99396003)(21056001)(33646002)(87936001)(85852003)(76482002)(107046002)(4396001)(120916001)(76576001)(2656002)(74316001)(19580405001)(31966008)(19580395003)(110136001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3b8_fX-Bg_eT8YICtnfhyZIVrYM Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:44:33 -0000 SSBhbSBvcGVuIHRvIHN1Z2dlc3Rpb25zLiBQcmV2aW91c2x5LCBLZXJiZXJvcyB1c2VkIDUgbWlu dXRlcyBmb3IgY2xvY2sgc2tldy4gQXJlIHdlIHRoaW5raW5nIHRoYXQgaXMgdG9vIG11Y2ggdGlt ZT8gVGhlIGNsb2NrIHNrZXcgZGFuZ2VyIGhlcmUgd291bGQgYmUgYmV0d2VlbiB0d28gRENzIGlu IHRoZSBzYW1lIHJlYWxtLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmlj byBXaWxsaWFtcyBbbWFpbHRvOm5pY29AY3J5cHRvbmVjdG9yLmNvbV0gDQpTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDI4LCAyMDE0IDI6NTQgUE0NClRvOiBNaWNoaWtvIFNob3J0DQpDYzogR3JlZyBI dWRzb247IGtpdHRlbkBpZXRmLm9yZzsgQW5kcmVpIFBvcG92DQpTdWJqZWN0OiBSZTogW2tpdHRl bl0gQ29tbWVudHMgcmVxdWVzdGVkIG9uIGRyYWZ0LXNob3J0LXBraW5pdC1mcmVzaG5lc3MtMDAN Cg0KT24gVHVlLCBPY3QgMjgsIDIwMTQgYXQgNDo0MSBQTSwgTWljaGlrbyBTaG9ydCA8bWljaGlr b3NAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IFdpbmRvd3MgdXNlcyB0aGUgQUQgZm9yIGl0cyBh Y2NvdW50IGRhdGFiYXNlLCBzbyB3ZSBjYW5ub3QgdXNlIGFuIGluZGV4L3NoYXJlZCBkYXRhYmFz ZSBtZXRob2QuIFdlIHdlcmUgdGhpbmtpbmcgc29tZXRoaW5nIHRpbWUgYm91bmQgd2l0aCBzb21l dGhpbmcgdW5pcXVlLg0KDQpUaGUgaW5kZXggd291bGQgYmUgaW50byBhIGxvY2FsIGNhY2hlLCBz byB0aGF0IGlmIHRoZSBzYW1lIGNsaWVudCBnb2VzIGJhY2sgdG8gdGhlIHNhbWUgQVMsIHRoZW4g dGhlIEFTIGNhbiBzYXZlIGl0c2VsZiB0aGUgd29yayBvZiBjcnlwdG9ncmFwaGljYWxseSB2ZXJp ZnlpbmcgdGhlIGZyZXNobmVzcyB0b2tlbiwgaW5zdGVhZCBkb2luZyBhbiBvY3RldC13aXNlIGNv bXBhcmlzb24gb2YgdGhlIHRva2VuIHRvIHRoYXQgaW4gdGhlIGNhY2hlIGFuZCBjaGVja2luZyB0 aGF0IHRoZSB0aW1lc3RhbXAgaW4gdGhlIHRva2VuIGlzICJmcmVzaCIuDQoNCkNsZWFybHkgdGhl IHRva2VuIG11c3Qgbm90aW9uYWxseSBpbmNsdWRlIGEgdGltZXN0YW1wLCB3aGV0aGVyIGl0J3Mg ZW5jcnlwdGVkIG9yIE1BQ2VkLiAgSXQgbWF5IG9yIG1heSBub3QgbmVlZCBhIGxpbmsgdG8gdGhl IGNsaWVudCByZXF1ZXN0aW5nIGEgdGlja2V0IGFzIHdlbGwgKGNuYW1lLCBjcmVhbG0sIHN1Ympl Y3RQdWJsaWNLZXkgKGlmIG5vdCBhbm9uKSwgc3ViamVjdFB1YmxpY0tleUluZm8gKGlmIHVzaW5n IERIKSkuDQoNCldlIHNob3VsZCBzYXkgc29tZXRoaW5nIGFib3V0IHdoYXQgImZyZXNobmVzcyIg bWVhbnMuICBXaXRoaW4gdGhlIGxhc3QNCjMwIHNlY29uZHM/ICBXaXRoaW4gdGhlIGxhc3QgbWlu dXRlPyAgQ2xlYXJseSBpdCBzaG91bGQgYmUgYSBtYXR0ZXIgb2YgbG9jYWwgY29uZmlndXJhdGlv biwgZm9yIHNvbWUgYWR2aWNlIHdvdWxkIGhlbHAuDQoNCk5pY28NCi0tDQo= From nobody Wed Oct 29 15:04:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609831A910E for ; Wed, 29 Oct 2014 15:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-1XLBC3qOs9 for ; Wed, 29 Oct 2014 15:04:45 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0541A910B for ; Wed, 29 Oct 2014 15:04:45 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id BEE4C1E080 for ; Wed, 29 Oct 2014 15:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fkzJbWT/TkmK7D2Ab36Q NAVJd+A=; b=C7wvOrJec4bttb9GgIbqjbRyCNPt5k5ITAjeK8/CQKLIIfzau7Ep CUtkBLwLhBlCqnzGSBBPFO3lUmrPB60gpaL3paBkmWieT+zXftxhQXhy4chxbs+S h3T4v5jLmOW/nqWXoGwo7XDNUSq5nl/ajuk2rx+w3Cy+VDKTrLe8YyY= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 6A1FA1E07C for ; Wed, 29 Oct 2014 15:04:44 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id n3so2956807wiv.0 for ; Wed, 29 Oct 2014 15:04:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.104.170 with SMTP id gf10mr16179690wjb.88.1414620283084; Wed, 29 Oct 2014 15:04:43 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Wed, 29 Oct 2014 15:04:43 -0700 (PDT) In-Reply-To: <857f1bc9d74548b28aa127bc7e1c3f4d@BL2PR03MB212.namprd03.prod.outlook.com> References: <544EFB27.6050905@mit.edu> <52a5d77b0bb94bf0b3f7285d9c6f0b77@BL2PR03MB212.namprd03.prod.outlook.com> <544FC6F6.6040809@mit.edu> <20141028165408.GE17213@localhost> <70f776594ee74b5fb2cf8e3114450b9b@BL2PR03MB212.namprd03.prod.outlook.com> <857f1bc9d74548b28aa127bc7e1c3f4d@BL2PR03MB212.namprd03.prod.outlook.com> Date: Wed, 29 Oct 2014 17:04:43 -0500 Message-ID: From: Nico Williams To: Michiko Short Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/v4j_eYAieU3lj1qmuUt0fB15DQY Cc: "kitten@ietf.org" , Andrei Popov Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 22:04:46 -0000 On Wed, Oct 29, 2014 at 4:44 PM, Michiko Short wrote: > I am open to suggestions. Previously, Kerberos used 5 minutes for clock skew. Are we thinking that is too much time? The clock skew danger here would be between two DCs in the same realm. I think something like "a small fraction of the would-be lifetime of the ticket to be issued" will do, since that matches the intent (no pre-minting of AS-REQs ahead of time). I'd make it 30 seconds, since by this point in the protocol there's no skew issues for any remotely sane clocks, and 30 seconds seems like plenty of time to complete an AS exchange. Nico -- From nobody Wed Oct 29 22:45:44 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A22F1AD00F for ; Wed, 29 Oct 2014 22:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr73bG3B3RbC for ; Wed, 29 Oct 2014 22:45:41 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DC91AD014 for ; Wed, 29 Oct 2014 22:45:40 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9U5jdX5009440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Oct 2014 05:45:39 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s9U4vSYo025495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2014 04:57:28 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9U4vRl6025486 for ; Thu, 30 Oct 2014 04:57:28 GMT Received: from [10.159.101.6] (/10.159.101.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Oct 2014 22:45:38 -0700 Message-ID: <5451D0A2.1040907@oracle.com> Date: Wed, 29 Oct 2014 23:46:10 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20141007 Thunderbird/17.0.11 MIME-Version: 1.0 To: kitten@ietf.org References: <53D138AC.60702@isode.com> <5440B05B.9040408@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mHAImTPBlGi92xBTMbfTkpi_W9c Subject: Re: [kitten] Some test registrations according to draft-ietf-kitten-gssapi-extensions-iana-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 05:45:42 -0000 On 10/26/14 06:57 PM, Benjamin Kaduk wrote: > On Fri, 17 Oct 2014, Shawn M Emery wrote: > >> Could folks please review the example registry that we would like to include >> in the draft-ietf-kitten-gssapi-extensions-iana draft? >> >> Thanks, >> >> Shawn. >> -- >> On 07/24/14 10:47 AM, Alexey Melnikov wrote: >>> Bindings: C >>> Registration type: Instance >>> Object Type: Context-Flag >>> Symbol Name: GSS_C_DELEG_FLAG >>> Binding of: deleg_state or deleg_req_flag >>> Constant Value/Range: 1 >>> Description: On output (if set): Delegated credentials are available >>> via the delegated_cred_handle >>> parameter of GSS_Accept_sec_context/GSS_Init_sec_context. > Er, GSS_Init_sec_context does not have a delegated_cred_handle argument. Yes, this is confusing, but there are trade-offs with using abbreviated text and being thorough in description. Would something like the following make this more clear?: Description: On output (if set): Delegated credentials are available via the delegated_cred_handle parameter of GSS_Accept_sec_context On input (if set): With the call to GSS_Init_sec_context, delegate credentials to the acceptor Note that I'm not aware of what field length constraints there are for registry entries. > > Otherwise, these look fine to me. Thanks for your review. Shawn. -- >>> On input (if set): requests delegation of access rights. >>> Registration Rules: N/A >>> Reference: RFC 2744 >>> Expert Reviewer: Kitten WG >>> Expert Review Notes: >>> Status: Registered >>> Obsoleting Reference: N/A > From nobody Thu Oct 30 08:43:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1FD1AD525 for ; Thu, 30 Oct 2014 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbsuJS3bJzX5 for ; Thu, 30 Oct 2014 08:43:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB021AD536 for ; Thu, 30 Oct 2014 08:41:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D36D52AB2BE; Thu, 30 Oct 2014 15:41:46 +0000 (UTC) Date: Thu, 30 Oct 2014 15:41:46 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141030154146.GR9411@mournblade.imrryr.org> References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029173535.GJ17213@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cHRxaEDmhk9he0QNHu3lhkJTqA8 Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:43:33 -0000 On Wed, Oct 29, 2014 at 12:35:37PM -0500, Nico Williams wrote: > > What are the IDNA issues for realm names? Should the realm be in > > A-label or unicode form? > > Oh no, you went there :) The Kerberos community tried to tackle the > I18N issues in 2002 and it was too soon and ETOOHARD; I18N got dropped. The dust has settled since then, and it is now more clear what to do. Even email addresses are going UTF-8 with EAI (which Postfix will support as of 2.12 or 3.0, whatever it ends up being called). Yes, the DNS A-label form appears on the wire in DNS queries, and is to be used to match DNS subjectAltName values in certificates. However, the "canonical" name of an internationalized realm really should be UTF-8. Thus unicode realm names need to be converted to A-labels for DNS queries (host->realm or SRV record lookup). The realm of a principal on the wire in Kerberos should then always be unicode. > - Declare uses of Kerberos protocol elements to carry domainnames or > DOMAIN-style realm names to be IDNA-unaware domainname slots: they > may NOT carry U-labels; ToASCII() must be used. I think this is not the right future direction. The wire format Kerberos protocol elemets should be unicode, as should principal names in keytabs, the Kerberos database, ... If some data-store is not UTF-8 capable, then that access to that datastore needs to perform conversions between the wire form and the storage form. -- Viktor. From nobody Thu Oct 30 10:02:35 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E61E1A1A13 for ; Thu, 30 Oct 2014 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbzJukPAgYv5 for ; Thu, 30 Oct 2014 10:02:31 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 241931A6FB5 for ; Thu, 30 Oct 2014 09:56:10 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id D683943807F for ; Thu, 30 Oct 2014 09:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=xcZ3L2GffNWNhLDB9WSHRuFBwR8 =; b=ac8aTNPmVogvA8XJ1n4eAIf+SpFKO0i9m4GnmzF5F6vcCF9xJIWoPP8orUU qxkau1Ta8fhKjjK/A3u3yLrnzzSMLsk/KK1m56xV8ze9YyzlOlXRq+i/ayXOlUw/ Z9DEijmeZpAj1+1jRPmAADl6Xy/O5i90PClDaRhi0G9XGRqU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id 9AE7A43807C for ; Thu, 30 Oct 2014 09:56:09 -0700 (PDT) Date: Thu, 30 Oct 2014 11:56:09 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141030165607.GL17213@localhost> References: <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141030154146.GR9411@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/z3xTYQaOv99UQnGKZQPIqY5OOgI Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:02:33 -0000 On Thu, Oct 30, 2014 at 03:41:46PM +0000, Viktor Dukhovni wrote: > On Wed, Oct 29, 2014 at 12:35:37PM -0500, Nico Williams wrote: > > > What are the IDNA issues for realm names? Should the realm be in > > > A-label or unicode form? > > > > Oh no, you went there :) The Kerberos community tried to tackle the > > I18N issues in 2002 and it was too soon and ETOOHARD; I18N got dropped. > > The dust has settled since then, and it is now more clear what to > do. Even email addresses are going UTF-8 with EAI (which Postfix > will support as of 2.12 or 3.0, whatever it ends up being called). Well, even then some things were clear. > Yes, the DNS A-label form appears on the wire in DNS queries, and > is to be used to match DNS subjectAltName values in certificates. That's because updating the DNS on the wire protocol was deemed either too difficult or not worth the trouble. > However, the "canonical" name of an internationalized realm really > should be UTF-8. Thus unicode realm names need to be converted to > A-labels for DNS queries (host->realm or SRV record lookup). > > The realm of a principal on the wire in Kerberos should then always > be unicode. That neither follows nor is what IDNA says. Though most everyone will agree that minimizing the need for ToASCII() and ToUnicode() calls would be nice, and *that* does mean sending UTF-8 on the wire would be nice. > > - Declare uses of Kerberos protocol elements to carry domainnames or > > DOMAIN-style realm names to be IDNA-unaware domainname slots: they > > may NOT carry U-labels; ToASCII() must be used. > > I think this is not the right future direction. The wire format > Kerberos protocol elemets should be unicode, as should principal > names in keytabs, the Kerberos database, ... If some data-store > is not UTF-8 capable, then that access to that datastore needs to > perform conversions between the wire form and the storage form. What appears in keytabs and so on is a local/implementation matter. (Some implementations would have a legacy upgrade problem regardless of how we address the protocol I18N problem.) What happens on the wire is the key. And here we run into a problem: the protocol uses IA5String for all the relevant strings (principal components, realm names), and we can't send UTF-8 in IA5String. In *practice* every implementation just-sends-whatever or just-sends-UTF-8 in IA5String, and in either case no stringprep is applied. The first questions is: can we get a way with saying "oh well, send UTF-8 in these IA5String fiels"? In theory it would break anyone using ASN.1 tooling that won't permit that. The second question is what to do about normalization in particular and stringprep in general, particularly w.r.t. existing non-ASCII realms and principals. The problem in 2002 was that negotiation of use of UTF8String complicated the protocol and no implementor committed to implementing that. The complexity of such a negotiation now would be similar to what it was then, though perhaps we can use DNS for realm capability discovery, thus simplifying some of the piece of the problem. The negotiation is as follows: - for any non-ASCII crealm, do an AS exchange (or DNS lookup) to detect whether that realm's KDCs support the new protocol (with UTF8String) or the old one with just-send-UTF-8-in-IA5String - for any non-ASCII srealm, do a TGS exchange (or DNS lookup) to detect the srealm's support for the new protocol or the old one - for any sname, do a TGS exchange to detect the sname's support... (The realm and the sname might need I18N in an AS exchange as well.) Whereas treating those IDNA-unaware slots as such means making no substantial changes to the protocol, just the implementations. This sucks because A-labels can leak into UIs, and the need to apply ToASCII()/ToUnicode() can leak into applications -- preventing such leaks will require a lot of work and it may not be feasible to get 100% coverage. If we can get to 100% or very close though, it's just a trade-off in complexity: complexity in the protocol [and implementations], or complexity in the implementations. But if we can just say that our "IA5String fields are really UTF8String, never mind the DER tag on them", then we get a big win. (Sending UTF8String instead, as if those IA5String fields had been extensible CHOICEs, does not work, because none of the existing implementations interpret the UTF8String correctly.) Nico -- From nobody Thu Oct 30 10:24:19 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1601A0354 for ; Thu, 30 Oct 2014 10:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcGduWnJB-25 for ; Thu, 30 Oct 2014 10:24:16 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8811A0101 for ; Thu, 30 Oct 2014 10:24:16 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 0263454078 for ; Thu, 30 Oct 2014 10:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=r6iHR/Aa92UyQUHBW6Q549zukG8 =; b=EfgcON3KQHXwoZ5kdCGc2tQUCfeCcr8XDrEKQ8+ZocYBgSNw0p/TQRVWZRr AYc5BTzhBEa53zzon6OLk9mDTxUmyC2eBa2iRwYIOmqWNlNuY5JOos+hD1d5A71E mo7qIFRj6PN3k+G7ysFrkp/04OjP8MwMVy1uv4PQOgJ/eGIM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id B838754058 for ; Thu, 30 Oct 2014 10:24:15 -0700 (PDT) Date: Thu, 30 Oct 2014 12:24:15 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141030172413.GM17213@localhost> References: <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> <20141030165607.GL17213@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141030165607.GL17213@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LmoNVvfgB61LxkRDrrBS4IEgoPk Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:24:17 -0000 Using A-lables doesn't do anything about non-domainname slots (e.g., user names). Which argues for either a new protocol with UTF8String (ETOOHARD) or just declaring our IA5Stings to carry UTF-8 (if anyone objects, too bad: it's what happens in reality anyways; ignoring reality has non-trivial costs). Nico -- From nobody Thu Oct 30 12:25:55 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEB81A1B92 for ; Thu, 30 Oct 2014 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HIry6Ze32M2 for ; Thu, 30 Oct 2014 12:25:50 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA99D1A1B91 for ; Thu, 30 Oct 2014 12:25:50 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 120A49405C for ; Thu, 30 Oct 2014 12:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=/63UptzQ8Z+Ot6k8RTEUQT6e01M =; b=ZF+BJiRS+7mrj3ME1uaH0/hdND8zVvoOQMOcs8O4j5NeUYO9dqf22IChKHo uv7p4semcqHIDXI8KSgfI7Kd1DAxozPHBrAnhI2bFVYFqscAQpP42kHd8cErCNYC 5zcsBlYd+jn2cuHp7td8MUFxffYfZR6NNOK3BIB77M2A+PIo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id BE7F79405E for ; Thu, 30 Oct 2014 12:25:49 -0700 (PDT) Date: Thu, 30 Oct 2014 14:25:48 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20141030192547.GO17213@localhost> References: <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> <20141030165607.GL17213@localhost> <20141030172413.GM17213@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141030172413.GM17213@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sCKQQvMo55dky6aiOW8EmWb_iNQ Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 19:25:52 -0000 An evil thought occurs... Update RFC4120 to redefine KerberosString from this: KerberosString ::= GeneralString (IA5String) to this: KerberosString ::= [UNIVERSAL 27] IMPLICIT UTF8String I.e., send UTF8String, but tag it as GeneralString. (This is legal ASN.1. For example, GeneralizedTime is defined as [UNIVERSAL 24] IMPLICIT VisibleString.) On the wire this means: no change to encodings, and admit reality. No need to negotiate. Just-send-8 implementations will have to do codeset conversions. All implementations will have to do something about stringprep. We have several options on that front, the best of which may be to do no normalization or stringprep of any kind, leaving end-points to do normalization-insensitive string comparison where it matters (but for ease of implementation continue requiring that cname/crealm in Authenticators match cname/crealm in Tickets exactly). Nico -- From nobody Thu Oct 30 13:02:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5731A1BEC for ; Thu, 30 Oct 2014 13:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pThoAOx2jgJf for ; Thu, 30 Oct 2014 13:02:38 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D41C1A1C02 for ; Thu, 30 Oct 2014 13:02:38 -0700 (PDT) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id 9Y2Z1p00910HQrX01Y2azt; Thu, 30 Oct 2014 21:02:36 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <20141030192547.GO17213@localhost> Date: Thu, 30 Oct 2014 21:02:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B4EE0BA-3C41-4B61-84E6-1F4CD1504EE0@openfortress.nl> References: <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> <20141030165607.GL17213@localhost> <20141030172413.GM17213@localhost> <20141030192547.GO17213@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IzwgtcVcjZfdwLpFbUAgSBLuHM8 Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:02:41 -0000 Wow, > An evil thought occurs=85 Yes, this really _is_ evil ;-) > Update RFC4120 to redefine KerberosString from this: >=20 > KerberosString ::=3D GeneralString (IA5String) >=20 > to this: >=20 > KerberosString ::=3D [UNIVERSAL 27] IMPLICIT UTF8String >=20 > I.e., send UTF8String, but tag it as GeneralString. Yep, that ought to work under BER/DER encoding :) But I wonder what does the most damage: * introducing a new, negotiated, string format for i18n and let it sip = in slowly * introducing UTF-8 and letting it loose on unsuspecting programs > On the wire this means: no change to encodings, and admit reality. Yeah=85 and shifting the basis of security assumptions that programmers may have made based on the IA5String format assumptions. Things like =93there are no long-winded notations for \0=94 for instance. Now = these won=92t show up until you decode UTF-8, but it=92s just an example of = the sort of misleading that reality may now impose on those programs, but for which you are now blaiming those programs that have hitherto been well-coded programs. It=92s not really fair on them? -Rick= From nobody Thu Oct 30 13:16:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8EA1A6F47 for ; Thu, 30 Oct 2014 13:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWNPpuagFxmD for ; Thu, 30 Oct 2014 13:16:24 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475F01A6F3A for ; Thu, 30 Oct 2014 13:16:08 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-02-54529c87f100 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7C.BB.13180.78C92545; Thu, 30 Oct 2014 16:16:07 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9UKG6k3026520; Thu, 30 Oct 2014 16:16:07 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9UKG4rc002827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 16:16:06 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9UKG48M017748; Thu, 30 Oct 2014 16:16:04 -0400 (EDT) Date: Thu, 30 Oct 2014 16:16:04 -0400 (EDT) From: Benjamin Kaduk To: Shawn M Emery In-Reply-To: <5451D0A2.1040907@oracle.com> Message-ID: References: <53D138AC.60702@isode.com> <5440B05B.9040408@oracle.com> <5451D0A2.1040907@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrts+JyjE4PVTA4ujm1exWPS9PsTu wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGU0/ZrCWHCPr2L6H70Gxo3cXYycHBICJhJN j9azQdhiEhfugdhcHEICs5kkHn/vYAdJCAlsZJRYsy4Nwj7EJLFuiyREUQOjxLzln1hBEiwC 2hKN694wgthsAioSM99sBJsqIqAlcaOhgwnEZhYQllh/bgYziC0skCMx/dZkoDgHBydQzcdP fiBhXgFHiXW7djNDzJ/BKLHw+SOwI0QFdCRW75/CAlEkKHFy5hMWiJlaEsunb2OZwCg4C0lq FpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWbGMFh6qK8g/HPQaVDjAIc jEo8vBeOBoYIsSaWFVfmHmKU5GBSEuWNmh0UIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE16sb KMebklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMFbDTJUsCg1PbUiLTOn BCHNxMEJMpwHaHgkSA1vcUFibnFmOkT+FKOilDhvwyyghABIIqM0D64XlkZeMYoDvSLMmwbS zgNMQXDdr4AGMwEN/jw1AGRwSSJCSqqBMePSiS79UD8xrj7jeb/ybBceMevY0x1yq8jt/DaB Dcmc+ROmVPe8b5JOEePM+B0/YwEjS1ewz87z7zPtd3zWNrNt1veeV/vZzOGaxa9nuQuuXj4j 4Zsgsanm/Q2+4JboHwlODM/eCBQZ7p3X8HFBFfOn70enJm91M5xdrer2rnC5aY7l5LCDSizF GYmGWsxFxYkAVXF4Y/4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RXiqq98W5CtlN7aewStAwLx_sAQ Cc: kitten@ietf.org Subject: Re: [kitten] Some test registrations according to draft-ietf-kitten-gssapi-extensions-iana-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:16:27 -0000 On Thu, 30 Oct 2014, Shawn M Emery wrote: > On 10/26/14 06:57 PM, Benjamin Kaduk wrote: > > On Fri, 17 Oct 2014, Shawn M Emery wrote: > > > > > Could folks please review the example registry that we would like to > > > include > > > in the draft-ietf-kitten-gssapi-extensions-iana draft? > > > > > > Thanks, > > > > > > Shawn. > > > -- > > > On 07/24/14 10:47 AM, Alexey Melnikov wrote: > > > > Bindings: C > > > > Registration type: Instance > > > > Object Type: Context-Flag > > > > Symbol Name: GSS_C_DELEG_FLAG > > > > Binding of: deleg_state or deleg_req_flag > > > > Constant Value/Range: 1 > > > > Description: On output (if set): Delegated credentials are available > > > > via the delegated_cred_handle > > > > parameter of GSS_Accept_sec_context/GSS_Init_sec_context. > > Er, GSS_Init_sec_context does not have a delegated_cred_handle argument. > > Yes, this is confusing, but there are trade-offs with using abbreviated text > and being thorough in description. Would something like the following make > this more clear?: > > Description: On output (if set): Delegated credentials are available > via the delegated_cred_handle parameter of GSS_Accept_sec_context > > On input (if set): With the call to GSS_Init_sec_context, > delegate credentials to the acceptor That is more clear, yes. There are still more subtleties that are not covered by that text (the flag can be set on a GSS_S_CONTINUE_NEEDED return of GSS_Accept_sec_context, can be set on the initiator's returned flags, etc.), but those are probably overkill for a registry like this. > Note that I'm not aware of what field length constraints there are for > registry entries. IIRC the download links on the web are just XML files, but there is probably some other internal representation. -Ben From nobody Thu Oct 30 13:26:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AC61A6FB7 for ; Thu, 30 Oct 2014 13:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.7 X-Spam-Level: X-Spam-Status: No, score=-100.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So0ZNAlhFz6e for ; Thu, 30 Oct 2014 13:25:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AEA1A6FAA for ; Thu, 30 Oct 2014 13:25:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9B23F2AAD9C; Thu, 30 Oct 2014 20:25:57 +0000 (UTC) Date: Thu, 30 Oct 2014 20:25:57 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20141030202557.GA19103@mournblade.imrryr.org> References: <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> <20141030165607.GL17213@localhost> <20141030172413.GM17213@localhost> <20141030192547.GO17213@localhost> <3B4EE0BA-3C41-4B61-84E6-1F4CD1504EE0@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B4EE0BA-3C41-4B61-84E6-1F4CD1504EE0@openfortress.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RId6q5MyDEXO3tHJhR3wgX9rRNg Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:26:01 -0000 On Thu, Oct 30, 2014 at 09:02:32PM +0100, Rick van Rein wrote: > > On the wire this means: no change to encodings, and admit reality. > > Yeah? and shifting the basis of security assumptions that programmers > may have made based on the IA5String format assumptions. Things > like ?there are no long-winded notations for \0? for instance. Now these > won?t show up until you decode UTF-8, but it?s just an example of the > sort of misleading that reality may now impose on those programs, but > for which you are now blaiming those programs that have hitherto been > well-coded programs. It?s not really fair on them? The programs in question should be Kerberos libraries, by the time the principal is presented to applications it should already have been validated by the library, including rejection of non-minimal UTF-8 encodings and internal NUL octets (which can occur in ASN.1 strings even without UTF-8). So strlen(data) == ASN1.length(data) needs to be enforced regardless. -- Viktor. From nobody Thu Oct 30 13:36:38 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6101A6FD4 for ; Thu, 30 Oct 2014 13:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7eS7Xj7X0Jn for ; Thu, 30 Oct 2014 13:36:32 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 556E41A6FAA for ; Thu, 30 Oct 2014 13:36:11 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 1911C20202C; Thu, 30 Oct 2014 13:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=eWJyirLiqHwOVhmM9tZpQJBRWuE=; b=ba/jmMRMjeu RIvCImRc464a8lbXDQTjU7Mwd3qP8b9tEEKcOO5C3RaOUrIQyNiMXE3tz/II3JT5 nELTshxJhe/FYoK2f+wgZKy++GoMZ4on4FGnpfXKkB7N8gIL+Zmun/OlKyp9nHut Zfzpy6i/x4WZR8OmEsFXps+flfqT1LOw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id BF00F202022; Thu, 30 Oct 2014 13:36:10 -0700 (PDT) Date: Thu, 30 Oct 2014 15:36:09 -0500 From: Nico Williams To: Rick van Rein Message-ID: <20141030203606.GP17213@localhost> References: <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> <20141030165607.GL17213@localhost> <20141030172413.GM17213@localhost> <20141030192547.GO17213@localhost> <3B4EE0BA-3C41-4B61-84E6-1F4CD1504EE0@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3B4EE0BA-3C41-4B61-84E6-1F4CD1504EE0@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/0stS5LrCU9-2nfhwQxvkHTP845M Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:36:33 -0000 On Thu, Oct 30, 2014 at 09:02:32PM +0100, Rick van Rein wrote: > Wow, >=20 > > An evil thought occurs=E2=80=A6 >=20 > Yes, this really _is_ evil ;-) Tom says that x.680 permits this only for itself. However, I think of the two possible abuses of ASN.1/DER that we could make here, this is the most palatable, as it's much more likely that a) existing ASN.1 compilers will accept this (because it makes sense to for internal purposes), or b) can be modified to accept it with minimal effort. > But I wonder what does the most damage: > * introducing a new, negotiated, string format for i18n and let it sip= in slowly > * introducing UTF-8 and letting it loose on unsuspecting programs The latter already happened, because all existing implementations fail to constrain GeneralString to IA5String as specified in RFC4120, both on the encode and decode sides. > > On the wire this means: no change to encodings, and admit reality. >=20 > Yeah... and shifting the basis of security assumptions that > programmers may have made based on the IA5String format assumptions. > Things like In the Kerberos space no such assumptions have been made. MIt and Heimdal gladly send whatever you feed them, without even so much as a codeset convertion to/from UTF-8. Windows and Active Directory gladly send non-ASCII UTF-8 without any normalization (or any singificant stringprep). > "there are no long-winded notations for \0" for instance. Now these > won't show up until you decode UTF-8, but it's just an example of the > sort of misleading that reality may now impose on those programs, but > for which you are now blaiming those programs that have hitherto been > well-coded programs. It's not really fair on them? Existing implementations do check for embedded NULs (sadness otherwise). Nico --=20 From nobody Thu Oct 30 14:34:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE4F1A8830 for ; Thu, 30 Oct 2014 14:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftbf_PNXRUoJ for ; Thu, 30 Oct 2014 14:34:32 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2FC1A882F for ; Thu, 30 Oct 2014 14:34:32 -0700 (PDT) X-AuditID: 1209190e-f79d46d000003643-ad-5452aee7f670 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B0.27.13891.7EEA2545; Thu, 30 Oct 2014 17:34:31 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9ULYULj014667; Thu, 30 Oct 2014 17:34:31 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9ULYSRk031299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 17:34:30 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9ULYSQf027489; Thu, 30 Oct 2014 17:34:28 -0400 (EDT) Date: Thu, 30 Oct 2014 17:34:28 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141029173535.GJ17213@localhost> Message-ID: References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixG6novt8XVCIwfM7EhZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJXx8HwjW8Fjpoq3k1YxNTBOYOpi5OSQEDCR WLN+MhuELSZx4d56IJuLQ0hgNpNEX0svI4SzkVFixry3TBDOISaJnqtroJwGRollm1YygvSz CGhLLFl+hgXEZhNQkZj5ZiPYXBEBTYnr85aC2cwCwhLrz81gBrGFBeIkNhyZDtbLKaAvcXTB H7CbeAUcJebOa4Ra8IxZYlf/IlaQhKiAjsTq/VNYIIoEJU7OfMICMVRLYvn0bSwTGAVnIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81pXQTIyhcOSX5djB+Pah0iFGA g1GJh1fjRGCIEGtiWXFl7iFGSQ4mJVFeJWCwC/El5adUZiQWZ8QXleakFh9ilOBgVhLh9eoG yvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfCyggwVLEpNT61Iy8wp QUgzcXCCDOcBGi4LUsNbXJCYW5yZDpE/xajL0dL0tpdJiCUvPy9VSpz3zVqgIgGQoozSPLg5 sDTzilEc6C1h3i8gVTzAFAU36RXQEiagJZ+nBoAsKUlESEk1MEqZaKRs4GFYkMxrp5ewoeth 9N5rAn92vct6/p85dfOtgq7plRes0/QY6lvF+61vybIWv9vU65/Ods710Qq3m+/ucbx1vVec sDvyYPKGKE692RXKPO9VWRsq93ZdPL56v0jvwp6Vu14p1smGFYdJ/37apPpS/22xufTXaZeW 6c72Obn31d/rNkosxRmJhlrMRcWJAG5J6JEOAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/k23P_pTuasLLCqdMg-KdAUkp2aw Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:34:34 -0000 Sniping, On Wed, 29 Oct 2014, Nico Williams wrote: > - in RFC4120 Realm slots: use A-labels only for DOMAIN-style[0] > realm-names, with all labels up-cased (to follow existing > convention, why not?); Obligatory note that there are real-world realms with lowercase realm names; we should not gratuitously break them. -Ben From nobody Thu Oct 30 14:51:48 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF511A8839 for ; Thu, 30 Oct 2014 14:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpP4mU2ICcxa for ; Thu, 30 Oct 2014 14:51:44 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F76D1A883E for ; Thu, 30 Oct 2014 14:51:44 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 3C98D200B998D for ; Thu, 30 Oct 2014 14:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=HkPgmmEOTWabTXfua/pG VVVncjI=; b=qzgzjJYNT29TeZOOwTK0iNPdDkBhPZdwJzbSaVKaX+QyMxsPE1UE BcRC8l/SpkO0EK1NkhuyaBBNpAS/I8Rp7HNwXz3EYQfwK8eYcDYr288YE+k9I8px aoRkKSnBZfp7d1ue3O56hT1tUE2WUC2VknibCmhYul+fw4ozF3TnIGs= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id E05EF20024943 for ; Thu, 30 Oct 2014 14:51:43 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so8617182wiv.15 for ; Thu, 30 Oct 2014 14:51:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.189.104 with SMTP id gh8mr3429421wic.3.1414705902510; Thu, 30 Oct 2014 14:51:42 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Thu, 30 Oct 2014 14:51:42 -0700 (PDT) In-Reply-To: References: <4CFD0017-B1F0-48C5-8ED8-21EFD770C5EC@openfortress.nl> <20141028225025.GC9411@mournblade.imrryr.org> <20141029144914.GG9411@mournblade.imrryr.org> <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> Date: Thu, 30 Oct 2014 16:51:42 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/onGtTLkikUCCrMtV1ZP6vRmAf8I Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:51:46 -0000 On Thu, Oct 30, 2014 at 4:34 PM, Benjamin Kaduk wrote: > Sniping, > > On Wed, 29 Oct 2014, Nico Williams wrote: > >> - in RFC4120 Realm slots: use A-labels only for DOMAIN-style[0] >> realm-names, with all labels up-cased (to follow existing >> convention, why not?); > > Obligatory note that there are real-world realms with lowercase realm > names; we should not gratuitously break them. They wouldn't, unless they were non-ASCII UTF-8, and even case in the Unicode form would be preserved, with the addition of A-label aliases of the original. Still, I'd rather do the KerberosString ::= [UNIVERSAL 27] IMPLICIT UTF8String hack -- it will be much less work, and it will interop much better with existing non-ASCII names in use in existing deployments. Nico -- From nobody Fri Oct 31 01:43:26 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC9B1A1BFA for ; Fri, 31 Oct 2014 01:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en26GiSkp0mV for ; Fri, 31 Oct 2014 01:43:21 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9D11A1BDB for ; Fri, 31 Oct 2014 01:43:20 -0700 (PDT) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id 9kjH1p00L10HQrX01kjJhm; Fri, 31 Oct 2014 09:43:18 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <20141030203606.GP17213@localhost> Date: Fri, 31 Oct 2014 09:43:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <026C6EA4-45E7-4D2F-931E-990484C65DDC@openfortress.nl> References: <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> <20141030165607.GL17213@localhost> <20141030172413.GM17213@localhost> <20141030192547.GO17213@localhost> <3B4EE0BA-3C41-4B61-84E6-1F4CD1504EE0@openfortress.nl> <20141030203606.GP17213@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/vMpmbKKrhAqGfo2RuKy78XB_g40 Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 08:43:24 -0000 Hey, >>=20 >> Yeah... and shifting the basis of security assumptions that >> programmers may have made based on the IA5String format assumptions. >> Things like >=20 > In the Kerberos space no such assumptions have been made. MIt and > Heimdal gladly send whatever you feed them, without even so much as a > codeset convertion to/from UTF-8. Windows and Active Directory gladly > send non-ASCII UTF-8 without any normalization (or any singificant > stringprep). Are you saying that the implementation practice is OCTETSTRING? That could be another option, and then having end user apps interpret UTF-8 or other. Not sure that=92s better, just bringing in an alternative. -Rick= From nobody Fri Oct 31 07:50:32 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C34A1A0171 for ; Fri, 31 Oct 2014 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKZAZtdjSMIV for ; Fri, 31 Oct 2014 07:50:28 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C38641A013B for ; Fri, 31 Oct 2014 07:50:28 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 78FBD31805C for ; Fri, 31 Oct 2014 07:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=J25l/8PIK+xaDF1ZiFZL37qZpbQ=; b=CSikQSry8FS 3iDggR/KbQyjz5KIbnWAJs87KcEEj9PaVVRq1hWO51S/VEgL5pGlxMDwbU0MjcsG npiCu90f/W/LJcFqD+kW5yv7eWwVAtihPDruRmJbHkP0zjQQyGpt/4YckhZTYA/m pPs9tUbIofsRlqNTHtaJTWcSpK9IGGmU= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 28D4F318059 for ; Fri, 31 Oct 2014 07:50:28 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id h11so1509383wiw.6 for ; Fri, 31 Oct 2014 07:50:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.239.196 with SMTP id vu4mr2661802wjc.4.1414767026799; Fri, 31 Oct 2014 07:50:26 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Fri, 31 Oct 2014 07:50:26 -0700 (PDT) In-Reply-To: <026C6EA4-45E7-4D2F-931E-990484C65DDC@openfortress.nl> References: <6C6E732E-84B3-4BDA-BE3A-F007ECA7D806@openfortress.nl> <20141029160128.GO9411@mournblade.imrryr.org> <20141029170301.GP9411@mournblade.imrryr.org> <20141029173313.GI17213@localhost> <20141029173535.GJ17213@localhost> <20141030154146.GR9411@mournblade.imrryr.org> <20141030165607.GL17213@localhost> <20141030172413.GM17213@localhost> <20141030192547.GO17213@localhost> <3B4EE0BA-3C41-4B61-84E6-1F4CD1504EE0@openfortress.nl> <20141030203606.GP17213@localhost> <026C6EA4-45E7-4D2F-931E-990484C65DDC@openfortress.nl> Date: Fri, 31 Oct 2014 09:50:26 -0500 Message-ID: From: Nico Williams To: Rick van Rein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/JM_OqcvJTD1OqHY3LRJnIUzyBc4 Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos I18N, finally? (Re: I-D Action: draft-vanrein-dnstxt-krb1-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:50:30 -0000 On Fri, Oct 31, 2014 at 3:43 AM, Rick van Rein wrote= : > Are you saying that the implementation practice is OCTETSTRING? Yes. > That could be another option, and then having end user apps interpret > UTF-8 or other. > > Not sure that=E2=80=99s better, just bringing in an alternative. It's not. It's not always possible to detect codeset and encoding from the octet string itself. The best fix is to treat it as UTF-8. Nico -- From nobody Fri Oct 31 11:39:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2931A01A8 for ; Fri, 31 Oct 2014 11:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GnnoiGEpjGx for ; Fri, 31 Oct 2014 11:39:23 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB7D1A19F3 for ; Fri, 31 Oct 2014 11:39:23 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-0a-5453d75a3ffb Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 38.1B.13180.A57D3545; Fri, 31 Oct 2014 14:39:22 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9VIdLBd028824; Fri, 31 Oct 2014 14:39:21 -0400 Received: from [18.101.8.149] (vpn-18-101-8-149.mit.edu [18.101.8.149]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9VIdIpa012713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 14:39:20 -0400 Message-ID: <5453D756.2060303@mit.edu> Date: Fri, 31 Oct 2014 14:39:18 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> In-Reply-To: <20141027203931.GA16952@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT0Y26HhxiMHsOr8WhC8cZLY5uXsVi ceraETYHZo+Xp84xeixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGVsXPWYq2MdW8WvJE+YG xnbWLkZODgkBE4mbXesYIWwxiQv31rN1MXJxCAnMZpI4/GUPlLORUeLVySNMIFVCAkeYJI5P YAaxeQXUJK7N38wGYrMIqEqcmnCQBcRmE1CWWL9/K5DNwSEqECYxdSkPRLmgxMmZT8BKRAQ0 Ja7PWwrWyizgK3Hg/QSwI4QFrCUentjADLHKW2Lv3PfMIGM4BfQlJkzigCjXk9hx/RcrhC0v sf3tHOYJjIKzkGyYhaRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3 MYID2kV5B+Ofg0qHGAU4GJV4eBccDwoRYk0sK67MPcQoycGkJMqbejE4RIgvKT+lMiOxOCO+ qDQntfgQowQHs5IIr+YxoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeH kgSvzzWgRsGi1PTUirTMnBKENBMHJ8hwHqDhcSA1vMUFibnFmekQ+VOMuhwtTW97mYRY8vLz UqXEeTdeBSoSACnKKM2DmwNLRK8YxYHeEua1ABnFA0xicJNeAS1hAlryeWoAyJKSRISUVAPj gUXVota87berM7jOXL/p/uWUzpyPp63jb58VqymsNHjBsuuiQvoMY72p/45tbbBMuOBZylPx c8nx7uC2HpuN9/h8eJRfKNZ8nmDZXLIlRD3Y54e13KyZjQc0Ngmm53V8Mzxw4Ivdh3ktF8z2 1D8uf/syZLHuYRel+PPBp29KuyrfW/6a1+SiEktxRqKhFnNRcSIAa3cWoh8DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/NKVmwGFSIsoY598yc0y8o-skPLg Cc: Kitten WG , Kitten Chairs Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:39:26 -0000 On 10/27/2014 04:39 PM, Nico Williams wrote: > Might as well also point out that the only asynchronously exchanged > security context tokens are: > > - error tokens sent by one side to another than had just returned > GSS_S_COMPLETE (and an output token, the one that elicits the > error) Does this really happen in practice? On the mech implementation side, the krb5 mech in MIT krb5 only generates an error token in the acceptor if the initiator requested mutual auth, and never generates an error token in the initiator. On the application side, I have never heard of an application containing a call to gss_process_context_token. If this is a facility that we don't seem to require or use in the real world, then my preference is that we not talk about it in the gss-loop document. From nobody Fri Oct 31 12:13:57 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA591A03E3 for ; Fri, 31 Oct 2014 12:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2EHmAEgAMlu for ; Fri, 31 Oct 2014 12:13:49 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4121A1A57 for ; Fri, 31 Oct 2014 12:13:49 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 1A39259807B for ; Fri, 31 Oct 2014 12:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fqyXpfRoblix+SZL41EO U9itRdI=; b=v5wkp8g9axSz6F9n5XMYx3l7xz2ZtVpReWSxQbgcj9z6kcz4lz1F QJPseqZ/F3uNONb/noPrVLrqGWzVEfaZENVDVZWTjseCsUOYaeXq3dG9vhFWn9ZF mSy2YJCie2cC2NfxJEfdbvuTzfp2fBnsTvRM6pEzVbjlrPWZrYBiNoM= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id B5D2D59807A for ; Fri, 31 Oct 2014 12:13:48 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id q5so2127042wiv.5 for ; Fri, 31 Oct 2014 12:13:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.70 with SMTP id na6mr5854418wic.3.1414782827155; Fri, 31 Oct 2014 12:13:47 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Fri, 31 Oct 2014 12:13:47 -0700 (PDT) In-Reply-To: <5453D756.2060303@mit.edu> References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <5453D756.2060303@mit.edu> Date: Fri, 31 Oct 2014 14:13:47 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pLhjotkBVlcn4M6a_rL5UEFW-AE Cc: Kitten WG , Kitten Chairs Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:13:51 -0000 On Fri, Oct 31, 2014 at 1:39 PM, Greg Hudson wrote: > On 10/27/2014 04:39 PM, Nico Williams wrote: >> Might as well also point out that the only asynchronously exchanged >> security context tokens are: >> >> - error tokens sent by one side to another than had just returned >> GSS_S_COMPLETE (and an output token, the one that elicits the >> error) > > Does this really happen in practice? On the mech implementation side, It can. It will generally only happen in the case of exchanges with an odd number of tokens in the successful case (e.g., Kerberos w/o mutual auth). > the krb5 mech in MIT krb5 only generates an error token in the acceptor > if the initiator requested mutual auth, and never generates an error > token in the initiator. On the application side, I have never heard of > an application containing a call to gss_process_context_token. I believe that's a mistake. Not requesting mutual auth != "don't ever send me an extra token". Errors are errors. > If this is a facility that we don't seem to require or use in the real > world, then my preference is that we not talk about it in the gss-loop > document. If we progress our extra tokens/round trips I-D then it may well matter. It doesn't really cost much, and correctness for this makes a big difference. Some SSHv2 w/ GSS implementations, for example, don't send error tokens, which makes diagnosing failures rather difficult. Error tokens may be optional, but they are quite handy. Nico -- From nobody Fri Oct 31 12:42:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8281A01A5 for ; Fri, 31 Oct 2014 12:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGjf-82-VMsu for ; Fri, 31 Oct 2014 12:42:14 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1131A00DB for ; Fri, 31 Oct 2014 12:42:14 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 78FC776805C for ; Fri, 31 Oct 2014 12:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=biLZO6NGBjngoS0bojNk z1t9D7U=; b=bRUX9ENTtmgEiyGzpOwmjLNNIZn6kAxyeUZNCOZlq2Znkjjf3ZZa y9NwCpj99dfLtjNcBktqx3Oq8AbdVloCX9Jgt+V+hksqxFHHpvbhRV8wLv9GzDge wfnFUM9yeAwCEZZtlP0KKMRlJ8lHlP2tMilNxHLTrr6weMiTxdiFBI8= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 2DC13768059 for ; Fri, 31 Oct 2014 12:42:14 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id x13so8628883wgg.5 for ; Fri, 31 Oct 2014 12:42:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.19.234 with SMTP id i10mr6276850wie.28.1414784533152; Fri, 31 Oct 2014 12:42:13 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Fri, 31 Oct 2014 12:42:13 -0700 (PDT) In-Reply-To: References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <5453D756.2060303@mit.edu> Date: Fri, 31 Oct 2014 14:42:13 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lpYDxImzihgHRO0DL08vEqX9RHs Cc: Kitten WG , Kitten Chairs Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:42:18 -0000 On Fri, Oct 31, 2014 at 2:13 PM, Nico Williams wrote: > If we progress our extra tokens/round trips I-D then it may well matter. Speaking of which: I'd like to request adoption of that as a WG work item. Nico -- From nobody Fri Oct 31 12:54:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496B11A0410 for ; Fri, 31 Oct 2014 12:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bi3lpkR8owp for ; Fri, 31 Oct 2014 12:54:26 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EA91A03FF for ; Fri, 31 Oct 2014 12:54:26 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-58-5453e8f00d1a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 61.9D.28565.0F8E3545; Fri, 31 Oct 2014 15:54:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9VJsOoE030568; Fri, 31 Oct 2014 15:54:24 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9VJsM4I008291; Fri, 31 Oct 2014 15:54:23 -0400 From: Tom Yu To: Greg Hudson References: Date: Fri, 31 Oct 2014 15:54:22 -0400 In-Reply-To: (Greg Hudson's message of "Sat, 25 Oct 2014 12:49:25 -0400") Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nrvvhRXCIwZk5VhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxquHrewFk9krXu16wtLAeJ21i5GTQ0LAROLn/49QtpjEhXvr 2boYuTiEBGYzSaz9v4gZwtnIKHG/7zwjSJWQwBtGiWvvZUBsNgFpieOXdzGB2CICihLPVs1l AbGZBUQlzq07AjZVWMBA4vnGTvYuRg6gXkOJ3p/pIGEWAVWJY7Peg5VwChRK/J90jxnE5hXQ lXjwfBnYSB4BTolFv+exQcQFJU7OfAI1Xkvixr+XTBMYBWYhSc1CklrAyLSKUTYlt0o3NzEz pzg1Wbc4OTEvL7VI10gvN7NELzWldBMjKPQ4JXl3ML47qHSIUYCDUYmHd8HxoBAh1sSy4src Q4ySHExKorwHngeHCPEl5adUZiQWZ8QXleakFh9ilOBgVhLhZQEGvBBvSmJlVWpRPkxKmoNF SZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgSvEkijYFFqempFWmZOCUKaiYMTZDgP0HBGsOHF BYm5xZnpEPlTjLocLU1ve5mEWPLy81KlxHmNQYoEQIoySvPg5sBSxitGcaC3hHkFQKp4gOkG btIroCVMQEs+Tw0AWVKSiJCSamC0MfZ8Yb3X8fe5D6KvXu0T8UmYE194eIb4StWV4qx7LrBN DxGs3OVx9p+RwcuKiwcj+bZ9Ezk/WWztg6KTHsv2tF5xPRl6p7Kv12XeuWoZ23rW09vKuV4k 8Mm6l6aF82QuCJ5sPT+K8WfQao7ad6Uvb13oLumavunwnMducezz697bLX91XVFCiaU4I9FQ i7moOBEAvi4ToPQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/FAFgAYY3Up2WCsMSbTNn0YeH2qE Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:54:29 -0000 Greg Hudson writes: > While working on creating test vectors for CAMMAC using asn1c, I noticed > into three issues with the ASN.1 module. Two are just matters of form, > but the third will affect the encoding if we decide to change it. I > believe we're at a slightly awkward stage of the workflow for this > draft, but at least we are still before IETF last call. > > 1. The ASN.1 module needs IMPORTS declarations for the RFC 4120 types it > uses. I have submitted a pull request to Tom's github repository with > the necessary import statements. > > 2. There is no OID in the module declaration. I don't know how > important this is in practice, but all of the other Kerberos-related > ASN.1 modules I looked at have OIDs. http://oid-info.com/get/1.3.6.1.5.2.4 shows several conflicts and squats. It seems that maybe 7 is the next unused one? What do people think? From nobody Fri Oct 31 14:58:20 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5438B1A0154 for ; Fri, 31 Oct 2014 14:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJbL6YdPv7Pj for ; Fri, 31 Oct 2014 14:58:14 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9E11A6F20 for ; Fri, 31 Oct 2014 14:58:09 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-d7-545405f019f5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 37.C8.13180.0F504545; Fri, 31 Oct 2014 17:58:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9VLw7JH019203; Fri, 31 Oct 2014 17:58:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9VLw5AY019635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 17:58:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9VLw5KF000425; Fri, 31 Oct 2014 17:58:05 -0400 (EDT) Date: Fri, 31 Oct 2014 17:58:05 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141027203931.GA16952@localhost> Message-ID: References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6novuBNSTEoHe5gcXRzatYLD4/vM1q ceraETYHZo8pvzeyerw8dY7RY8mSn0wBzFFcNimpOZllqUX6dglcGRc2HmEqOD+bsaKx8yVj A+PG8i5GTg4JAROJ1xdfMkHYYhIX7q1n62Lk4hASmM0k8XDdW3YIZyOjxLeDx1ggnENMEktm zWAFaRESaGCUmPVRCMRmEdCWuLjjJyOIzSagIjHzzUY2EFtEQFPi+rylYDazgKPE2g9XwNYJ C1hLPDyxgbmLkYODU0BfYsIkDpAwL1DJl6NvWSDGe0vsnfueGcQWFdCRWL1/CgtEjaDEyZlP WCBGakksn76NZQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmunlZpbopaaU bmIEh6+L8g7GPweVDjEKcDAq8fAuOB4UIsSaWFZcmXuIUZKDSUmU1+xPcIgQX1J+SmVGYnFG fFFpTmrxIUYJDmYlEV4n5pAQId6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZ Dg4lCV4hYJwKCRalpqdWpGXmlCCkmTg4QYbzAA2XA6nhLS5IzC3OTIfIn2JUlBLnVWcBSgiA JDJK8+B6YenlFaM40CvCvLtBqniAqQmu+xXQYCagwZ+nBoAMLklESEk1MCrYhAatW9nEFmhy dk1LxyLNvh7NMywrT/7yfMm1+S1vn0+2TNeMqnzZ/zoMN5UK+k1bYqrVzxgFbJBbZb7tTV6R Z3Tr54ancYp6ht/DdNiPVpkL7Hk6aYH7nwqO7FLp2kDDpb0txrlZqvYnBAJaePUrzm3csfNZ R1e3wT1uty857Yt7fWcrsRRnJBpqMRcVJwIAAeXZfwoDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tqYyHc3VAdLkXp20E4k5U5M9agU Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 21:58:19 -0000 Hi Nico, Thanks for the review. I'll trim the minor items that I took without change, so this email doesn't get too long. On Mon, 27 Oct 2014, Nico Williams wrote: > > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-00 > > Comments: > > - In some places you add non-RFC2119 language to what RFC2743 says > (e.g., which arguments to GSS_Init/Accept_sec_context() must stay the > same during an exchange). Should we be updating RFC2743 here, and > just aim for the Standards track (and use RFC2119 language)? > > (There is the risk that this I-D will have mistakes that we don't > want to make normative, but those would be errata.) I think we had discussed the question of whether to make this document standards-track earlier in its lifecycle, and decided that there were not significant changes from 2743 that we would want to make, so it wasn't worth adding the extra overhead of going standards-track. (This may have been the only such change, though I can't seem to findi where we listed them out...) > - "Such a security context allows for mutual authentication of the > two..." > > Strictly speaking it allows for authentication of either party to the > other. Speaking of "mutual authentication" here is probably not a > good idea: there are two very different meanings of "mutual > authentication"; readers are bound to be confused. Okay, I went with "allows for each party to authenticate the other" in my working copy. > - s/confidential or integrity-protected/confidentiality and\/or integrity-protected/ You can't get confidentiality without integrity protection in the GSS-API, but I'll take that change. > - Add "Security context tokens are exchanged synchronously, one at a > time; the initiator sends the initial context token." just before > that sentence. Given the following, I went with "During context establishment, security context tokens are exchanged synchronously, one at a time; the initiator sends the first context token." ... > Might as well also point out that the only asynchronously exchanged > security context tokens are: > > - error tokens sent by one side to another than had just returned > GSS_S_COMPLETE (and an output token, the one that elicits the > error) > > - security context deletion tokens (which are obsoleted and, > therefore, best not mentioned) > > Mentioning these very basic aspects of GSS context token exchanges > early on should be very useful to the reader. It's quite handy for > me to always keep this in mind when coding a GSS security context > token exchange loop; it should be for others too, I think. ... but I'll hold off on this until we resolve Greg's comment. > - We should say, in the intro, something about the expectation that the > application will add such things as: > > - authentication + authorization success/failure messages I'm not entirely convinced about this. We don't even necessarily know that there is a user to see such messages. > - token framing I would have thought this was implicit, but let's see what we can do. [...] an error condition. The GSS-API specifies the format and encoding of the context tokens themselves, but the application protocol must specify the necessary framing for the application to determine what octet strings constitute GSS security context tokens and pass them into the GSS-API implementation as appropriate. > - ...described in a single specification... > > Er, do we want application protocols using GSS to reference this > document normatively? If so this should aim to be on the Standards > track. Or perhaps we want them to reference RFC2743 _and_ this one? We want them to reference 2743 and this one; see the last paragraph of the introduction. > - s/scattered in many different places/scattered about/. "scattered about" feels too informal to me, so I didn't take this. > - Section 2, last sentence/para: I'm not sure that this is needed at > all. Where you discuss GSS_Init/Accept_sec_context() you generally > talk about the first call anyways (e.g., section 2.4, first > sentence). Greg thought so, too (it's already gone in my git repo). > - Section 2.1. Perhaps initiators wanting anonymity should also > GSS_Acquire_cred() for a desired_name of GSS_C_NT_ANONYMOUS name > type. This was never clear in RFC2743. I don't think there's sufficient precedent for this document to mention that possibility. (My reading of 2743 is that you acquire credentials as yourself, but can sometimes use them anonymously.) > Alternatively, having a credential handle for an anonymous name, must > anon_req_flag be set? > > Consider an API that takes a credential handle from a caller and then > uses it to initiate security context tokens. If the implementation > of the API needs to inquire the credential to see if it's for a > GSS_C_NT_ANONYMOUS desired_name... that could get annoying. > > My theory is that anon_req_flag is for use when a non-anonymous > [e.g., perhaps a default] credential handle is used by the caller. > Otherwise, if the credential handle is for an anon name then > anon_req_flag is not / should not need to be set! That seems to be the only sensible reading, to me. I still don't think that this document needs to cover it. > Conversely, an API that wants anonymity but doesn't know if the given > credential handle would obtain it... MUST set anon_req_flag. Right. > - "If the major status code is GSS_S_CONTINUE_NEEDED and the > output_token is empty, ..." > > Are there examples of such implementations? IIRC this happens for Windows GSS-NTLM implementations, or something of that nature. > Are there bindings other than C where this could not be handled as > proposed? "I don't know of any." But this is trying to prove a negative, so there doesn't seem to be a whole lot to say. In an ideal world, there would not be such mechanisms; IIRC RFC 2743 forbids this situation. But, there is deployed code that does it, and the behavior I describe seems more friendly than just aborting the negotiation (which is what a previous version did). > - s/if an appropriate channel/if an appropriate application-protocol > message (or transport operation, e.g., TCP close)/ I want to stick with "channel", here (that word is used a lot in the following section), but will add "application-protocol" for clarity. (This same text occurs in the GSS_Accept_sec_context section; I'll change both places.) > - Section 2.3, what is a "synchronous TCP channel"? A TCP connection that doesn't carry any other application's traffic. (I'm not tied to this text at all, and it evolved in a kind of odd way; please feel free to suggest alternate text.) > - Section 2.3, the key thing to note is that GSS tokens are NOT > self-delimiting. Therefore the application must always provide > framing. This seems to be covered again below. > (Some of us want a req_flag/ret_flag for requesting self-framing by > the mechanism. It'd be quite handy for some mechanisms and > protocols. E.g., the old Globus SSL mechanism, which *is* SSL/TLS on > the wire when the tokens are sent with no additional framing.) Maybe, but such a flag doesn't exist yet, to I can't talk about it :) > - Section 2.3, "the application protocol must provide some means by > which the GSS context tokens can be identified" -- in particular: > their _length_ (and start location in a stream/message) must be > identified. I can add "(e.g., length and start location)"; it's unclear if you want more than that. > - Section 2.3, perhaps there should be a list of things the application > protocol must provide: > > - per-message token framing > - security context token framing > - optional authentication/authorization status message > > (optional because for some protocols GSS security context > establishment is always sufficient to proceed, or because when it > isn't the acceptor can simply withold the last security context > token [though I'd not recommend that]) > > - Error handling is completely optional. Applications can send or > not send error tokens. Applications can "close the connection" > when the transport is connection-oriented. Applications can even > stop responding to peers. > > There's probably no need to discuss security context deletion tokens > (since they are obsolete). > > Framing is needed even when there is no multiplexing. > > A list like this seems likely to be easier to read than prose. > > Most of this is applicable to both, the initiator and the acceptor, > therefore a new section slotted before the current 2.2 or 2.3, with > the above content (wordsmithed) would be convenient. I'm not specifically opposed to a section covering the requirements for an application protocol which will be passing GSS structures as part of its protocol, but it's not clear to me that it brings a noticable advantage in this document. We don't cover message tokens at all, just context establishment, and everything else in your list is optional. Such a list would be a useful resource to offer to application protocol designers, I'm just not sure that this is the best place for it. > - Section 2.3, first para, remove the last sentence. It's difficult to > parse and adds little (especially if a list of requirements as above > is provided). I won't dispute that it's difficult to parse, but since I'm reluctant to add the list of requirements, I want to give it some replacement. How about: The application protocol may also include a facility for indicating errors from one party to the other, which can be used to convey errors resulting from GSS-API calls, when appropriate. Note that GSS major and minor status codes are specified by language bindings, not the abstract API, so may not be directly interpretable by the other peer. > - Section 2.4, second para: this applies to the initiator and acceptor > equally. > > Can we refactor this out? After all, the GSS_Step_sec_context() > extension would be all about doing just that. Might as well do it > here in the prose too. We could, but I'm not sure it would help the document as a whole. I like the current flow, which describes the flow from the initiator to the acceptor and back, with a neat loop structure. Yes, there is duplication, but that may be the price for clarity and readability. > - Section 2.6, last para is redundant (repeats instructions given > earlier). Redendancy may be okay in this document (per previous). > - "...should assume that the [peer's] state is invalid..." is an odd > construction. Is there a difference between "time out" and "the > peer's state is invalid"? Not really. Do you think the "time out" language is preferrable in a document of this nature? > - Section 3, don't list the req_flags that must remain fixed. Say that > all of them must. Remember, we can (and probably will) add new > flags. Alternatively say "and any future new req_flags". The flags are separate arguments in the abstract API, so I feel like they should be listed explicitly. "Any additional request flags that may be added" is a good point, though; thanks. > - Section 3, last para, both, the initiator and acceptor receive these > (and future) ret_flags. Might as well merge this paragraph with the > text from two paragraphs earlier. (See above comment about > refactoring common parts.) (See above comment about redundancy.) I will add the note about potential future extensions. > - Section 3.1, first para, last sentence: this is a bit of an > exageration. Applications should do whatever is appropriate as to > prot_ready per-message tokens' lack of replay protection. > > While we're at it, the intention in RFC2743 was that protection > services can't be counted as applied to prot_ready per-message tokens > until after the security context is fully established. Which means > that prot_ready per-message tokens: > > - don't get effective confidentiality and/or integrity protection > until full security context establishment; > > - never get replay detection services, not at the time that they are > consumed (since this would potentially require a replay cache on > acceptors and possibly even initiators for some mechs, and to my > knowledge no implementations use a replay cache for prot_ready > per-message tokens), and not at some point later when the security > context is fully establised (since it'd be too late then to report > errors about specific already-consumed per-message tokens). > > - Section 3.1, last para. See above. It's not really clear what (if any) changes you want to the document text. I replaced the last sentence of the first paragraph: Applications using per-message operations on a partially complete security context should take into consideration the fact that replay protection is not avaiable from the GSS-API for those messages, and take the appropriate protective measures. > - Section 3.2, page 9, second para (I think that's the third para), > error context tokens can arise in more common cases: > > - initiator sent the last token and was GSS_S_COMPLETE but the > acceptor rejects that token (e.g., Kerberos w/o mutual auth, with > any of many common Kerberos errors, and even application > authorization errors) > > A three-message Kerberos exchange (e.g., see > draft-williams-kitten-krb5-extra-rt) would also run into this. > > - acceptor sent the last token and was GSS_S_COMPETE but the > initiator rejects that token. > > Calling these cases "rare" is asking for trouble. > > The thing that is rare is the "optional to implement" thing, and a) > that never happens now, b) it's no different than any other error > that could happen as mentioned above. (Once > upon a time we had export restrictions on crypto, and as a result > some implementations shipped an RFC1964 implementation without > confidentiality protection, and this could cause an error token to be > sent back when the initiator hadn't requested mutual auth, this is > true. Well, maybe it didn't even produce an error token -- this was > fifteen years ago, with code long since obsolete, and I doubt anyone > will check the specifics now.) Our IRC discussions have mostly convinced me that the "optional to implement" case was a misreading of 2743 by me; that text has already been stricken. Regarding the non-rarity of error context tokens, I'll leave that to the other fork of the thread for now (that's coming in as I write this message). > - Section 3.2, last para: the best advice to give as to asynchronous > (i.e., unexpected) security context tokens, is that the application > must always act as though they terminate the security context, even > when they don't. We should deprecate the optional-to-implement > thing that led you to write this. Well, we need to document what exists, not what we want to exist. Why do you think that applications should treat all "extra" context toksn as terminating the context in the absense of a signal from the GSS-API that that is the case? > - Section 4: > > - There is no need to use GSS_ERROR() to handle major status codes > from gss_init/accept_sec_context() because the is never a success > or continue needed case with other supplemental codes or any error > codes. Always use equality comparison for gss_init/ Are you sure? Where does the spec say that must be the case? > accept_sec_context() major status codes to check for > complete/continue_needed status. > > Moreover, it's best to discourage use of GSS_ERROR(). Its use > with gss_unwrap() major status codes has led to a number of > security vulnerabilities in protocoles that were trying to make an > octet stream. This document does not cover GSS_Wrap() or friends. We should give better guidance for their use, but this is not the place. > GSS_ERROR() is only ever of use to applications using an > unreliable datagram transport, or to applications that have no > need for replay and/or out-of-sequence detection services from the > GSS-API (e.g., ONC RPC doesn't, even when running over TCP). > > - The sample code doesn't do what the prose says as to empty output > tokens when one is expected... The check I see is if ((major & GSS_S_CONTINUE_NEEDED) || output_token.length > 0) { which I thought matched up. As alluded to previously, though, the behavior specified by the prose has changed over the evolution of this document, and it's possible the code missed a spot catching up. Can you be more specific about which behavior is inconsistent? > - The while loop should probably be a do while loop. Maybe. We probably shouldn't get into debates about purely stylistic issues, though... > - There is no need to memset(&name_buf, 0, sizeof(name_buf)); It zeros out the padding, but hmm, okay, I guess no one should need to care about that. (Actually, Greg already told me to use GSS_C_EMPTY_BUFFER as an initializer instead. I guess I'll keep that so things look consistent at the top of the function.) > - The major status of gss_import_name() should be checked. Oops, I do that in my local version (preprocessor conditional) for testing but not the generic one for the spec. > - Why not mention authorization (use a stub function) and > application-level status message in do_acceptor()? I believe there were previous discussions around this, and Greg convinced me that such checks fit more naturally outside of do_acceptor(), which should just be about establishing the context. This may be another case where guidance on the use of the GSS-API is lacking, but this document is not the appropriate place to rectify that. The closest we get is to pass &client_name to gss_accept_sec_context(), which we then proceed to not do anything with. > - This: > > } else { > /* This situation is forbidden by RFC 2743. Bail out. */ > warnx("major not complete or continue but not error\n"); > goto cleanup; > } > > would be an internal error, not behavior forbidden by RFC2743, > because you break out of the loop in this case before ever getting > here. You should either assert() or ignore this. Hmm? I think this case covers at least a major status code with no fatal error codes set but a per-message-token informatory status code set, which is indeed forbidden by 2743. > - What about mentioning the possible need to check -on the acceptor > side- the name of the acceptor as used by the initiator? That's a > gss_inquire_context() call to get the name of the acceptor, then a > gss_compare_name() function call (or any of the other methods of > comparing names given in RFC2743). "What is the possible need for that check?" Changes are visible at https://github.com/kaduk/gssdoc/commits/master . -Ben From nobody Fri Oct 31 16:13:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BDE1A1A7C for ; Fri, 31 Oct 2014 16:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFUP9Q9Ynagj for ; Fri, 31 Oct 2014 16:13:25 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 149961A038F for ; Fri, 31 Oct 2014 16:13:25 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 5C9EF20058D81; Fri, 31 Oct 2014 16:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=TDt5jGO4Cn+lij MP2x9OpJ2nw2o=; b=X8HJpDMG5LN0oUgHszUkWMJxI/r8HLV4yrck2TnOi1u2gj z28po58WJww80z0Gng1+NPjxzWs15E52f3LYl5HNro+VOY3N0AX9pMVmueeC1xg7 NTtP5M9VdzUT+u7IRslJ2Nf/SGLJLMCCAthqnfvX9YHPJPXEQD3R0YmE2vPqQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id E22CD20058D80; Fri, 31 Oct 2014 16:13:23 -0700 (PDT) Date: Fri, 31 Oct 2014 18:13:23 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141031231321.GA7913@localhost> References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/FFagbmHrMSgrCswHndrhScfIWwU Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:13:28 -0000 On Fri, Oct 31, 2014 at 05:58:05PM -0400, Benjamin Kaduk wrote: > On Mon, 27 Oct 2014, Nico Williams wrote: > > > - s/confidential or integrity-protected/confidentiality and\/or integrity-protected/ > > You can't get confidentiality without integrity protection in the GSS-API, > but I'll take that change. Maybe "and/or" doesn't make it clear, but I thought it did, that you always get the latter. (You get both, or just the latter.) > > Mentioning these very basic aspects of GSS context token exchanges > > early on should be very useful to the reader. It's quite handy for > > me to always keep this in mind when coding a GSS security context > > token exchange loop; it should be for others too, I think. > > ... but I'll hold off on this until we resolve Greg's comment. I'm very interested in the extra tokens I-D. One way or another I'll see it to publication. If the WG doesn't take it, then I'll follow the individual submission path. PKU2U is three tokens. The Globus SSL mechanism is three tokens. Basically, there exist, and soon more will, odd-number-of-security-context-token mechanisms. Since your I-D is Informational, leaving out some information is not necessarily bad, but it'd be terrible if implementors used this as a guide and then had their implementations not work well with such mechanisms. > > - We should say, in the intro, something about the expectation that the > > application will add such things as: > > > > - authentication + authorization success/failure messages > > I'm not entirely convinced about this. We don't even necessarily know > that there is a user to see such messages. The message could be a boolean (success/fail), but it's necessary in many (but not all) applications. > > - token framing > > I would have thought this was implicit, but let's see what we can do. It is as soon as you realize that all these functions want a buffer with a length. If we were to add a self-framing option we'd probably have to add a function to extract token lengths from bytes received so far, or perhaps we'd need functions with bytes-left-unused and more-bytes-needed outputs. So, yeah, it's implicit. > > - Section 2.1. Perhaps initiators wanting anonymity should also > > GSS_Acquire_cred() for a desired_name of GSS_C_NT_ANONYMOUS name > > type. This was never clear in RFC2743. > > I don't think there's sufficient precedent for this document to mention > that possibility. (My reading of 2743 is that you acquire credentials as > yourself, but can sometimes use them anonymously.) Since there's an anonymous name-type, it makes sense to be able to acquire a credential handle for anonymous desired_names. There's no stricture against it. It'd be convenient too. Anyways, ignore this for now. > That seems to be the only sensible reading, to me. I still don't think > that this document needs to cover it. Sure. > > - "If the major status code is GSS_S_CONTINUE_NEEDED and the > > output_token is empty, ..." > > > > Are there examples of such implementations? > > IIRC this happens for Windows GSS-NTLM implementations, or something of > that nature. Oh right, NTLM. Thanks for the reminder. > > - Section 2.3, what is a "synchronous TCP channel"? > > A TCP connection that doesn't carry any other application's traffic. > (I'm not tied to this text at all, and it evolved in a kind of odd way; > please feel free to suggest alternate text.) That's very non-obvious. You want an antonym for "multiplexed", I think. > > - Section 2.3, "the application protocol must provide some means by > > which the GSS context tokens can be identified" -- in particular: > > their _length_ (and start location in a stream/message) must be > > identified. > > I can add "(e.g., length and start location)"; it's unclear if you want > more than that. That works. > > - Section 2.3, perhaps there should be a list of things the application > > protocol must provide: > > [...] > > I'm not specifically opposed to a section covering the requirements for an > application protocol which will be passing GSS structures as part of its > protocol, but it's not clear to me that it brings a noticable advantage in > this document. We don't cover message tokens at all, just context > establishment, and everything else in your list is optional. For me it's easier to read something like that given that most of the list's elements can be a single line each. Distilling the same from lengthy prose is harder. It's just a matter of style. > Such a list would be a useful resource to offer to application protocol > designers, I'm just not sure that this is the best place for it. True. But we'll want application protocol specifications to reference this, so it might as well be useful to them too (or their readers: as a source of explanation). > > - Section 2.3, first para, remove the last sentence. It's difficult to > > parse and adds little (especially if a list of requirements as above > > is provided). > > I won't dispute that it's difficult to parse, but since I'm reluctant to > add the list of requirements, I want to give it some replacement. How > about: > The application protocol may also include a facility for > indicating errors from one party to the other, which can be > used to convey errors resulting from GSS-API calls, when > appropriate. Note that GSS major and minor status codes > are specified by language bindings, not the abstract API, > so may not be directly interpretable by the other peer. I have a lot of experience with this from deploying SSHv2 w/ GSS more than a dozen years ago: anything other than sending a GSS error token is TERRIBLE. First, the minor status is utterly useless, especially now that some implementations allocate those dynamically. Second, the major status is to coarse to be of much use. Third, the major and minor status display strings won't be localized to the other peer's locale. Fourth, the major and minor status codes and display strings will not necessarily be as informational to the peer as the GSS error token. (They weren't, back then, for a variety of common errors.) Sending major & minor status codes/messages instead of an error token is only to be done when there's an error but no error token (because the mechanism implementation doesn't produce them, but should have, say). The SSHv2 w/ GSS implementation in question did not even do that at first (or maybe it sent an error message, but not the token, and the client did nothing with the error message). Users merely saw "Connection closed by " when something went wrong with Kerberos. It was _awful_. Please, please, let's not perpetuate these mistakes -- that's what they are, mistakes, ones that punish the users. ASIDE: Years ago Sam Hartman insisted that error tokens should be optional, that local policy should be allowed to say "no error tokens" on account of wanting to limit information leaks through error tokens. That could be OK as an application policy, but if it's a mechanism-specific configuration, then the application would be violating that policy if it then sent its own error message with the major & minor status codes & messages! Anyways, when an error occurs the only choices are: a) send it, b) send a censored version, c) shut the door (close the connection, or whatever is appropriate for the given transport), d) stop talking and let the peer timeout. (b) seems like a task for the mechanism, not the application, unless the application distills it to just a boolean (success/failure). For the general case the clearly best advice is to just send the bloody error token when there is one. > > - Section 2.4, second para: this applies to the initiator and acceptor > > equally. > > > > Can we refactor this out? After all, the GSS_Step_sec_context() > > extension would be all about doing just that. Might as well do it > > here in the prose too. > > We could, but I'm not sure it would help the document as a whole. You might be right. I'd have to see the refactored text first. > > - "...should assume that the [peer's] state is invalid..." is an odd > > construction. Is there a difference between "time out" and "the > > peer's state is invalid"? > > Not really. Do you think the "time out" language is preferrable in a > document of this nature? "...should assume that the [peer's] state is invalid..." just strikes me as really weird. Developers understand "timeout". > > - Section 3, don't list the req_flags that must remain fixed. Say that > > all of them must. Remember, we can (and probably will) add new > > flags. Alternatively say "and any future new req_flags". > > The flags are separate arguments in the abstract API, so I feel like they > should be listed explicitly. "Any additional request flags that may be > added" is a good point, though; thanks. You can list them if you like, but please say that all request flags must be kept the same throughout. > > - Section 3.1, last para. See above. > > It's not really clear what (if any) changes you want to the document text. > I replaced the last sentence of the first paragraph: > Applications using per-message operations > on a partially complete security context should take into > consideration the fact that replay protection is not avaiable > from the GSS-API for those messages, and take the appropriate > protective measures. You also need to say that they shouldn't send data requiring confidentiality protection (since at the time the per-message token is sent the peer may not yet be authenticated). > > - Section 3.2, page 9, second para (I think that's the third para), > > error context tokens can arise in more common cases: > > > > [...] > > Our IRC discussions have mostly convinced me that the "optional to > implement" case was a misreading of 2743 by me; that text has already been > stricken. Thanks. > Regarding the non-rarity of error context tokens, I'll leave that to the > other fork of the thread for now (that's coming in as I write this > message). It's natural that they seem rare to a Kerberos implementor. It'd be rather bad -and ironic- if developers following this I-D produced apps that don't work well with mechanisms that produce an odd number of context tokens, or future Kerberos extensions that do that. > > - Section 3.2, last para: the best advice to give as to asynchronous > > (i.e., unexpected) security context tokens, is that the application > > must always act as though they terminate the security context, even > > when they don't. We should deprecate the optional-to-implement > > thing that led you to write this. > > Well, we need to document what exists, not what we want to exist. The API exists. That's RFC2743. You're focusing on the mechanisms that you use. There are other mechanisms. And I intend to extend Kerberos to get this same behavior. Dismissing the others as not existing is not appropriate. > Why do you think that applications should treat all "extra" context > toksn as terminating the context in the absense of a signal from the > GSS-API that that is the case? The GSS-API as specified today can only produce asynchronous (to one peer) context tokens as a result of an error while processing what should have been the last context token, or as a result of calling the obsoleted GSS_Delete_sec_context(). As there are no recoverable context establishment errors, the first case clearly results in the context not becoming established on one side, and the peer gets no benefit from ignoring this (what's it gonna do, send per-message tokens anyways to the unwilling peer?). The second case clearly results in the security context no longer being usable either. Therefore both cases result in the security context no longer being established. See RFC2743, section 2.2.4. It's true that we could someday add a re-key token, and we'd extend GSS_Process_context_token() to handle it. But unfortunately when GSS_Process_context_token() returns GSS_S_COMPLETE the security context must be deleted -- see RFC2743, section 1, page 5, last paragraph: If a context_token is transferred, the client passes the context_token to GSS_Process_context_token(), which returns GSS_S_COMPLETE status after deleting context-level information at the client system. Section 2.2.4 does not repeat this. In the C bindings gss_process_context_token() does not take a gss_ctx_id_t * argument, so it can't quite delete the context. I think we could simply agree that RFC2743 is ambiguous as to this and so say that the application must inquire the security context after processing an unexpected/async context token -- if GSS_Inquire_context() function fails with GSS_S_NO_CONTEXT, then the token was an error or context deletion token. It's also the case that both RFCs are ambiguous as to how the error information from an error token is to be indicated to the application. I think the only reasonable thing to do is for GSS_Process_context_token() to return the intended error information. The minor status code can be used to disambiguate local errors (arising from processing this token) from error information in the token. Sorry that got long. > > - Section 4: > > > > - There is no need to use GSS_ERROR() to handle major status codes > > from gss_init/accept_sec_context() because the is never a success > > or continue needed case with other supplemental codes or any error > > codes. Always use equality comparison for gss_init/ > > Are you sure? Where does the spec say that must be the case? I'm dead certain. GSS_Init/Accept_sec_context() never return GSS_S_COMPLETE with supplementary status codes other than GSS_S_CONTINUE_NEEDED. > > accept_sec_context() major status codes to check for > > complete/continue_needed status. > > > > Moreover, it's best to discourage use of GSS_ERROR(). Its use > > with gss_unwrap() major status codes has led to a number of > > security vulnerabilities in protocoles that were trying to make an > > octet stream. > > This document does not cover GSS_Wrap() or friends. We should give better > guidance for their use, but this is not the place. Sure. Though I've seen this security bug half a dozen times, committed independently by roughly that many authors. That's a problem. This macro should be deprecated. This I-D could be the PSA that alerts developers as to this (e.g., in the security considerations section). > > - The sample code doesn't do what the prose says as to empty output > > tokens when one is expected... > > The check I see is > if ((major & GSS_S_CONTINUE_NEEDED) || > output_token.length > 0) { > which I thought matched up. As alluded to previously, though, the > behavior specified by the prose has changed over the evolution of this > document, and it's possible the code missed a spot catching up. Can you > be more specific about which behavior is inconsistent? Excuse me, I'd misread that. > > - The while loop should probably be a do while loop. > > Maybe. We probably shouldn't get into debates about purely stylistic > issues, though... It's stylistic, yes, that loops that must run at least once be do-while loops. I'm surprised to see a difference of opinion as to that though! :) > > - There is no need to memset(&name_buf, 0, sizeof(name_buf)); > > It zeros out the padding, but hmm, okay, I guess no one should need to > care about that. (Actually, Greg already told me to use > GSS_C_EMPTY_BUFFER as an initializer instead. I guess I'll keep that so > things look consistent at the top of the function.) Excellent. > > - Why not mention authorization (use a stub function) and > > application-level status message in do_acceptor()? > > I believe there were previous discussions around this, and Greg convinced > me that such checks fit more naturally outside of do_acceptor(), which > should just be about establishing the context. This may be another case > where guidance on the use of the GSS-API is lacking, but this document is > not the appropriate place to rectify that. This is asking for a security vulnerability. We must teach proper use of the API. > The closest we get is to pass &client_name to gss_accept_sec_context(), > which we then proceed to not do anything with. Just add a call to a stub function. > > - This: > > > > } else { > > /* This situation is forbidden by RFC 2743. Bail out. */ > > warnx("major not complete or continue but not error\n"); > > goto cleanup; > > } > > > > would be an internal error, not behavior forbidden by RFC2743, > > because you break out of the loop in this case before ever getting > > here. You should either assert() or ignore this. > > Hmm? I think this case covers at least a major status code with > no fatal error codes set but a per-message-token informatory status code > set, which is indeed forbidden by 2743. Right, which answers your question about as to GSS_ERROR(). Don't use GSS_ERROR(). Instead treat any GSS_S_COMPLETE-with-supplementary- status-codes-other-than-GSS_S_CONTINUE_NEEDED as errors. It's easier, it's less code, easier to explain. > > - What about mentioning the possible need to check -on the acceptor > > side- the name of the acceptor as used by the initiator? That's a > > gss_inquire_context() call to get the name of the acceptor, then a > > gss_compare_name() function call (or any of the other methods of > > comparing names given in RFC2743). > > "What is the possible need for that check?" Consider an application with keys for many principals in its keytab... Such an application might want to accept contexts for any host-based service principal with a given service but any host, or just some hosts. It's unlikely that it'd want to accept contexts for other services, and it could lead to a security vulnerability to do so. But at the same time, if the application wants to be able to accept contexts for more than one acceptor principal then it has to use GSS_C_NO_CREDENTIAL, therefore it could accept for any and all services for which it has keys in its keytab. It's unfortunate that the GSS-API doesn't have a simpler way to express more than one acceptor principal. There's two things that could be said (in the I-D) about this: a) limiting credentials availability is required but out of scope, or b) inquire the context, and check the acceptor's name against local policy. > Changes are visible at https://github.com/kaduk/gssdoc/commits/master . Thanks, I'll look later. Nico -- From nobody Fri Oct 31 18:23:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150961A8774 for ; Fri, 31 Oct 2014 18:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPVSjuzWXvLy for ; Fri, 31 Oct 2014 18:23:21 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8721A8773 for ; Fri, 31 Oct 2014 18:23:20 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-57-545436078491 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 57.D2.09603.70634545; Fri, 31 Oct 2014 21:23:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sA11NDh6026655; Fri, 31 Oct 2014 21:23:14 -0400 Received: from [18.101.8.149] (vpn-18-101-8-149.mit.edu [18.101.8.149]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sA11NBuc003285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 21:23:13 -0400 Message-ID: <545435FF.9030502@mit.edu> Date: Fri, 31 Oct 2014 21:23:11 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams , Benjamin Kaduk References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> In-Reply-To: <20141031231321.GA7913@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrstuFhJiMPWklsXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGW0vZvEUnDMtOL7o72MDYwrtLsYOTkkBEwk uuc1skDYYhIX7q1n62Lk4hASmM0ksf/DWyhnI6PE7Z4mdgjnCJNE96wVQA4HB6+AmsTcllCQ bhYBVYk1Nyewg9hsAsoS6/dvZQEpERUIk5i6lAckzCsgKHFy5hOwZSICnhInm5eBlTMLyEss +LaIFcQWFrCWeHhiAzPEqsWMEn/vTQcr4hTQk1hzdzETRIOexI7rv1hhmpu3zmaewCg4C8mO WUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyM4gF1UdzBOOKR0 iFGAg1GJh/fHyaAQIdbEsuLK3EOMkhxMSqK8t01CQoT4kvJTKjMSizPii0pzUosPMUpwMCuJ 8C6UB8rxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwtoIMFSxKTU+t SMvMKUFIM3FwggznARp+EqSGt7ggMbc4Mx0if4pRUUqcl8cUKCEAksgozYPrhSWYV4ziQK8I 80qBVPEAkxNc9yugwUxAgz9PDQAZXJKIkJJqYDS/YNX21FFj+8XcfJ9vLn/OLnndtcbEPHPf Cj4pxhsJG9fMP2N/hOPDVF+VfwcNE97nTilamKjik6zrfHKqndXxSbM+TYqwWhU3uasyYHv2 2mUvg5bJhM6fVCDe/lPQX4FR7L+fP/fqqeuXHFBTaWK8aqDr2rLp8ztfkyjBOGMp/84pSx/P PafEUpyRaKjFXFScCAADWMr7CwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/FLdDnTaC0u3yRkHwQCENenvjpp4 Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 01:23:24 -0000 On 10/31/2014 07:13 PM, Nico Williams wrote: > I'm very interested in the extra tokens I-D. One way or another I'll > see it to publication. If the WG doesn't take it, then I'll follow the > individual submission path. PKU2U is three tokens. The Globus SSL > mechanism is three tokens. Basically, there exist, and soon more will, > odd-number-of-security-context-token mechanisms. I assume this is relevant because you expect failures to commonly result when the acceptor processes the third message, rather than the first? > Since your I-D is Informational, leaving out some information is not > necessarily bad, but it'd be terrible if implementors used this as a > guide and then had their implementations not work well with such > mechanisms. Terrible or not, I believe that is the situation we're in today for applications, mechanisms, and perhaps even protocols (in that protocols may not have a way to transport context tokens except when the other endpoint expects one as part of context establishment). I am dubious that this document is a good vehicle to change that situation, as we'll be telling people to do something more complex than anyone actually does. But I will drop my objection if we can iron out the other details of calling gss_process_context_token. [From another branch of the thread:] > I believe that's a mistake. Not requesting mutual auth != "don't ever > send me an extra token". Errors are errors. I am kind of morbidly curious what would happen if the krb5 gss_accept_sec_context started generating error tokens without the initiator requesting mutual auth. I feel like a lot of protocols and their implementations just assume that under normal non-malicious operation, the acceptor and initiator will stop generating tokens at the same time as the other endpoint stops expecting them, and will throw a less-than-graceful failure if that doesn't happen. > Third, the major and minor status display strings won't be localized to > the other peer's locale. > > Fourth, the major and minor status codes and display strings will not > necessarily be as informational to the peer as the GSS error token. > (They weren't, back then, for a variety of common errors.) I am not sure when the error token is more informational than the display string. But I would worry about it being too informational--conveying information about server filesystem paths, for instance. And the potential for incorrect localization is definitely an issue. So I agree that an application-level error cannot reasonably convey any more information about a failure than the major code. >>> - Section 3.2, last para: the best advice to give as to asynchronous >>> (i.e., unexpected) security context tokens, is that the application >>> must always act as though they terminate the security context, even >>> when they don't. [...] >> Well, we need to document what exists, not what we want to exist. > > The API exists. That's RFC2743. The API exists, but RFC 2743 section 2.2.4 does not appear to specify that the context is always terminated by the call. > If a context_token is transferred, the client passes the > context_token to GSS_Process_context_token(), which returns > GSS_S_COMPLETE status after deleting context-level information at the > client system. This paragraph appears as part of an example scenario involving a call to gss_delete_sec_context (see the previous paragraph). I do not read it as specifying the result of all successful calls to GSS_Process_context_token. > I think we could simply agree that RFC2743 is ambiguous as to this I don't think there's really any ambiguity; it just doesn't appear to be specified under the assumption that the context is always terminated. > It's also the case that both RFCs are ambiguous as to how the error > information from an error token is to be indicated to the application. > I think the only reasonable thing to do is for > GSS_Process_context_token() to return the intended error information. I think that would be a clear violation of the spec, which lists four possible major results and states that GSS_S_FAILURE indicates a failure to process the context token. We could perhaps reasonably amend the spec if we believe (as I do) that no one is using gss_process_context_token. Such amendments aren't currently in scope for the gss-loop document, however. >>> - There is no need to use GSS_ERROR() to handle major status codes >>> from gss_init/accept_sec_context() because the is never a success >>> or continue needed case with other supplemental codes or any error >>> codes. Always use equality comparison for gss_init/ >> >> Are you sure? Where does the spec say that must be the case? > > I'm dead certain. GSS_Init/Accept_sec_context() never return > GSS_S_COMPLETE with supplementary status codes other than > GSS_S_CONTINUE_NEEDED. I agree that this is true in practice, but I'm not sure that it's clearly true from the spec. Of the currently specified supplementary bits, the four that aren't GSS_S_CONTINUE_NEEDED only apply to per-message tokens, but I don't see any specific guarantees about the return values of gss_accept_sec_context or gss_init_sec_context and supplementary bits. > Right, which answers your question about as to GSS_ERROR(). Don't use > GSS_ERROR(). Instead treat any GSS_S_COMPLETE-with-supplementary- > status-codes-other-than-GSS_S_CONTINUE_NEEDED as errors. It's easier, > it's less code, easier to explain. ... that said, I wouldn't object to doing this in the gss-loop document, as it's probably what I would do. I don't think we would ever try to specify a new supplementary bit applying to context tokens, as it would break everybody's code. > Consider an application with keys for many principals in its keytab... > > Such an application might want to accept contexts for any host-based > service principal with a given service but any host, or just some hosts. > It's unlikely that it'd want to accept contexts for other services, and > it could lead to a security vulnerability to do so. It seems like you would need mechanism-specific knowledge to enforce this using gss_inquire_context. You suggested using gss_compare_name, but what would you compare against? > It's unfortunate that the GSS-API doesn't have a simpler way to express > more than one acceptor principal. Possibly relevant: In MIT krb5 1.10 and later, you can import a hostbased name like "host" (no @hostname part), acquire an acceptor cred for it, and get the desired behavior. Against older versions or Heimdal, such a name will behave like "host@", which might or might not be acceptable fallback behavior. From nobody Fri Oct 31 21:25:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C31A87D4 for ; Fri, 31 Oct 2014 21:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzp6-svds1_R for ; Fri, 31 Oct 2014 21:25:24 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F321A87D1 for ; Fri, 31 Oct 2014 21:25:23 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-89-545460b1e862 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id EA.84.13180.1B064545; Sat, 1 Nov 2014 00:25:22 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sA14PLdk007264; Sat, 1 Nov 2014 00:25:21 -0400 Received: from [18.101.8.149] (vpn-18-101-8-149.mit.edu [18.101.8.149]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sA14PJum009143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Nov 2014 00:25:20 -0400 Message-ID: <545460AF.5010100@mit.edu> Date: Sat, 01 Nov 2014 00:25:19 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Tom Yu References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT192UEBJicOwNs8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfxGF1PBAqaKfbu3sjUwPmfsYuTkkBAwkWhq/8QCYYtJXLi3 nq2LkYtDSGA2k8SvU0tYIJwNjBL7b61khHAOM0lsmtrLDtLCK6Am0di2EmwUi4CqxN0V61lB bDYBZYn1+7cCdXNwiAqESUxdygNRLihxcuYTsG0iApIS3zZNBWtlFhCWuLB9L1irsICBxPON nWDjhQSCJb7MXgNmcwroSbzYP5UVol5PYsf1X1C2vMT2t3OYJzAKzkKyYhaSsllIyhYwMq9i lE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIDlYX5R2Mfw4qHWIU4GBU4uH1tAkJ EWJNLCuuzD3EKMnBpCTKWxgFFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCu1AeKMebklhZlVqU D5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMErAoxKIcGi1PTUirTMnBKENBMHJ8hw HqDhe+NBhhcXJOYWZ6ZD5E8xGnO0NL3tZeL4d/JDL5MQS15+XqqUOG8SSKkASGlGaR7cNFjC ecUoDvScMK8wyFIeYLKCm/cKaBUT0KrPUwNAVpUkIqSkGhgNZgRwtL92+9uhs3VrP+f+Nc8n lLgotN676u6/1rB56Y+C2SdZprbpFEZp5/Wm7zYwEpv5u+Dn6aWcm8vE7rx4vltE6+Ofq4qm q/590WFufTvzTixPflTsecfIO/UzWv/+0d7/qng5w3oLi4ZVK9TcPb61lK/JX+7xaQPPmiSN kHtPTi6scFFQYinOSDTUYi4qTgQA1tVQ2RMDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/vqh8evtBRdCZ1CBnj_dRp0WTZqw Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC ASN.1 module issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 04:25:26 -0000 On 10/31/2014 03:54 PM, Tom Yu wrote: > http://oid-info.com/get/1.3.6.1.5.2.4 > > shows several conflicts and squats. It seems that maybe 7 is the next > unused one? What do people think? I agree that 1.3.6.1.5.2.4.7 looks unused, based on that page and some Google searches. From nobody Fri Oct 31 23:08:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEC51A882D for ; Fri, 31 Oct 2014 23:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPGz1iKWVMre for ; Fri, 31 Oct 2014 23:07:59 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CDFBA1A882C for ; Fri, 31 Oct 2014 23:07:59 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id F06C54012D68E; Fri, 31 Oct 2014 23:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=SsPllp7XsyD8Ke fUkrFBmFH/k9g=; b=tLF+CNsCVMonEV+XqZzm5XRKnRCB6UR5unqBHmH+zIQ6xN WoKfHQ9wpDULEjos4+xRzI3GApbfJF27tcf2/gDq5GUEfUjpevFhIdzUp+c72CgV TOoWem63KvQ/Uks24kIS6UgnvLb+k1A9I3QQ9BWIFR7bkhCM5PERRuw+0KGWE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 859604012D68C; Fri, 31 Oct 2014 23:07:58 -0700 (PDT) Date: Sat, 1 Nov 2014 01:07:58 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20141101060755.GB7913@localhost> References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545435FF.9030502@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Ka2Cxhh0_myYLdy_oBhFo10MgiY Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 06:08:02 -0000 On Fri, Oct 31, 2014 at 09:23:11PM -0400, Greg Hudson wrote: > On 10/31/2014 07:13 PM, Nico Williams wrote: > > I'm very interested in the extra tokens I-D. One way or another I'll > > see it to publication. If the WG doesn't take it, then I'll follow the > > individual submission path. PKU2U is three tokens. The Globus SSL > > mechanism is three tokens. Basically, there exist, and soon more will, > > odd-number-of-security-context-token mechanisms. > > I assume this is relevant because you expect failures to commonly result > when the acceptor processes the third message, rather than the first? No. When errors occur the people suffering them need to be able to diagnose them. It doesn't matter how rare the error is. Indeed, the rarer it is, the more obnoxious the lack of diagnostics information. > > Since your I-D is Informational, leaving out some information is not > > necessarily bad, but it'd be terrible if implementors used this as a > > guide and then had their implementations not work well with such > > mechanisms. > > Terrible or not, I believe that is the situation we're in today for If we're not out to improve the state of the world, then what are we doing. > applications, mechanisms, and perhaps even protocols (in that protocols > may not have a way to transport context tokens except when the other > endpoint expects one as part of context establishment). SSHv2 w/ GSS can do it. Damn it, I've implemented it. > I am dubious that this document is a good vehicle to change that > situation, as we'll be telling people to do something more complex than > anyone actually does. But I will drop my objection if we can iron out > the other details of calling gss_process_context_token. I'm not asking that you update RFC2743. I'm asking that this I-D not create an excuse for getting something wrong that the normative references make plain is wrong. > [From another branch of the thread:] > > I believe that's a mistake. Not requesting mutual auth != "don't ever > > send me an extra token". Errors are errors. > > I am kind of morbidly curious what would happen if the krb5 > gss_accept_sec_context started generating error tokens without the > [...] We're talking about applications here, not the mechanism. Even if we never make Kerberos w/o mutual produce an error token, that does not mean that Kerberos w/ replay cache avoidance shouldn't. > I am not sure when the error token is more informational than the > display string. But I would worry about it being too For one thing: it gets localized properly. I don't recall the details from 2001 with enough clarity, but the KRB-ERROR resulted in clearer error messages on the client side than merely sending the major and minor status strings. You could search the list archives though, I might have posted about it then or some years later when the issue was discussed (I forget what context; maybe Sam remembers). > informational--conveying information about server filesystem paths, for > instance. And the potential for incorrect localization is definitely an > [...] That's certainly not true of KRB-ERROR! Ironically, the strings produced by GSS_Display_status() on one side are intended for consumption on _that_ side, not the other. Sending those strings is much more likely to reveal too much information than is sending the error token. The best censor of error messages is the producer. In this case it's the mechanism. > >>> - Section 3.2, last para: the best advice to give as to asynchronous > >>> (i.e., unexpected) security context tokens, is that the application > >>> must always act as though they terminate the security context, even > >>> when they don't. [...] > > >> Well, we need to document what exists, not what we want to exist. > > > > The API exists. That's RFC2743. > > The API exists, but RFC 2743 section 2.2.4 does not appear to specify > that the context is always terminated by the call. I've quoted and referenced text in the two relevant RFCs that leaves no doubt as to what the result of an asynchronous context token is. It can only be one of two things: a context deletion token, or an error token. If you think there is a third case, please demonstrate it. If you think we could add a third case, please explain how that would mean that applications shouldn't send or consume an error token in the meantime. > > I think we could simply agree that RFC2743 is ambiguous as to this > > I don't think there's really any ambiguity; it just doesn't appear to be > specified under the assumption that the context is always terminated. There are ambiguities. For example, the two RFCs fail to discuss how the error information from an asynchronous error token is conveyed -- they only say that it is to be processed with GSS_Process_context_token(). But it's clearly possible to convey that information, and so there's only one ambiguity as to that: failures in processing the error token itself, and distinguishing these from the error conveyed by the token is easy (see below). > > It's also the case that both RFCs are ambiguous as to how the error > > information from an error token is to be indicated to the application. > > I think the only reasonable thing to do is for > > GSS_Process_context_token() to return the intended error information. > > I think that would be a clear violation of the spec, which lists four > possible major results and states that GSS_S_FAILURE indicates a failure > to process the context token. There is no conceivable way in which returning other error codes here could break backwards-compatibility, but if there was, the obvious thing to do is to encode the token's error information in the minor status. > We could perhaps reasonably amend the spec if we believe (as I do) that > no one is using gss_process_context_token. Such amendments aren't > currently in scope for the gss-loop document, however. But this I-D can still say what RFC2 2743 and 2744 say to do: send the token, and process it. > >>> - There is no need to use GSS_ERROR() to handle major status codes > >>> from gss_init/accept_sec_context() because the is never a success > >>> or continue needed case with other supplemental codes or any error > >>> codes. Always use equality comparison for gss_init/ > >> > >> Are you sure? Where does the spec say that must be the case? > > > > I'm dead certain. GSS_Init/Accept_sec_context() never return > > GSS_S_COMPLETE with supplementary status codes other than > > GSS_S_CONTINUE_NEEDED. > > I agree that this is true in practice, but I'm not sure that it's > clearly true from the spec. Of the currently specified supplementary > bits, the four that aren't GSS_S_CONTINUE_NEEDED only apply to > per-message tokens, but I don't see any specific guarantees about the > return values of gss_accept_sec_context or gss_init_sec_context and > supplementary bits. The "informatory"/"suplementary" errors are that, so that they don't modify the success conveyed by GSS_S_COMPLETE. But if any such other than GSS_S_CONTINUE_NEEDED had been meaningful for these two functions -- or any others for which GSS_S_COMPLETE is listed w/o mention of supplemental status codes -- then surely they would have been mentioned, or else we must conclude that RFCs 2743/2744 do not mean to give exhaustive lists of major statuses that may be returned by the functions they document. Also, none of the other supplementary status codes make any sense here, except as errors: - GSS_S_DUPLICATE_TOKEN -> it's an error, not supplementary, when it comes to context tokens! - GSS_S_OLD_TOKEN -> just like GSS_S_DUPLICATE_TOKEN, and anyways, makes no sense in a context token exchange of just a handful of tokens - GSS_S_GAP_TOKEN -> can't possibly happen in a synchronous token exchange! - GSS_S_UNSEQ_TOKEN -> ditto Above you say that GSS_Proces_context_token() can't return major status codes not listed. Here you say GSS_Init/Accept_sec_context() can. Which is it? > > Right, which answers your question about as to GSS_ERROR(). Don't use > > GSS_ERROR(). Instead treat any GSS_S_COMPLETE-with-supplementary- > > status-codes-other-than-GSS_S_CONTINUE_NEEDED as errors. It's easier, > > it's less code, easier to explain. > > ... that said, I wouldn't object to doing this in the gss-loop document, > as it's probably what I would do. I don't think we would ever try to > specify a new supplementary bit applying to context tokens, as it would > break everybody's code. More than that: we'd *want* existing code to have to request the new feature before new supplementary codes are returned. > > Consider an application with keys for many principals in its keytab... > > > > Such an application might want to accept contexts for any host-based > > service principal with a given service but any host, or just some hosts. > > It's unlikely that it'd want to accept contexts for other services, and > > it could lead to a security vulnerability to do so. > > It seems like you would need mechanism-specific knowledge to enforce > this using gss_inquire_context. You suggested using gss_compare_name, > but what would you compare against? A white-list. Ditto GSS_Export_name() with GSS_C_NT_EXPORTED_NAME + memcmp(). Or GSS_Display_name_ext(), which is there to avoid the need for mechanism-specific knowledge. Or GSS_Get_name_attribute(), to decompose an MN into components like "service name" and "hostname". > > It's unfortunate that the GSS-API doesn't have a simpler way to express > > more than one acceptor principal. > > Possibly relevant: In MIT krb5 1.10 and later, you can import a > hostbased name like "host" (no @hostname part), acquire an acceptor cred > for it, and get the desired behavior. Against older versions or > [...] Great ad-hoc extension. But we're talking about portable and mechanism-generic application code. Standardize this extension and I'll be happy to see this I-D mention it. Nico --