From nobody Fri Oct  2 03:35:30 2015
Return-Path: <rick@openfortress.nl>
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 09D0A1AD36A for <kitten@ietfa.amsl.com>; Fri,  2 Oct 2015 03:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdzU8XlhBTmp for <kitten@ietfa.amsl.com>; Fri,  2 Oct 2015 03:35:27 -0700 (PDT)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A861AD369 for <kitten@ietf.org>; Fri,  2 Oct 2015 03:35:27 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id QAbP1r00G10HQrX01AbQAK; Fri, 02 Oct 2015 12:35:25 +0200
Message-ID: <560E5DEA.1060701@openfortress.nl>
Date: Fri, 02 Oct 2015 12:35:22 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
References: <20151002094932.3493.95660.idtracker@ietfa.amsl.com>
In-Reply-To: <20151002094932.3493.95660.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ACZg6x6rQBPq8QuFbCc4YiwGWiw>
Subject: [kitten] Fwd: New Version Notification for draft-vanrein-dnstxt-krb1-06.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 10:35:30 -0000

Hello,

I have adapted the "Kerberos Realm Names in DNS" draft with the
intention to represent our collective views:
 * Use TXT records instead of KREALM
 * Consider only the first <character-string> in RDATA; more is for
future extension
 * Informal spec name is now _kerberos TXT
If you like, you're welcome to add any further comments on the result.

The document does not break RFC 4120 AFAIK, making it suitable for
submission as an Independent Submission, although I would also support
adoption by the WG to call it an IETF spec.

If I hear nothing more, I will proceed towards submission to the RFC
Editor.  In any case, thanks for the lively discussions and insightful
comments!

Cheers,
 -Rick
> *From:* internet-drafts@ietf.org
> *Date:* 2 October 2015 11:49
> *To:* "Rick van Rein" <rick@openfortress.nl>, "Rick van Rein"
> <rick@openfortress.nl>
> *Subject:* New Version Notification for draft-vanrein-dnstxt-krb1-06.txt
> A new version of I-D, draft-vanrein-dnstxt-krb1-06.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:		draft-vanrein-dnstxt-krb1
> Revision:	06
> Title:		Declaring Kerberos Realm Names in DNS (_kerberos TXT)
> Document date:	2015-10-02
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-vanrein-dnstxt-krb1-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-06
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanrein-dnstxt-krb1-06
>
> Abstract:
>    This specification defines a method to determine Kerberos realm names
>    for services that are known by their DNS name.  Currently, such
>    information can only be found in static mappings or through educated
>    guesswork.  DNS can make this process more flexible, provided that
>    DNSSEC is used to ensure authenticity of resource records.
>
>                                                                                   
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>


From nobody Sun Oct  4 16:31:29 2015
Return-Path: <kaduk@mit.edu>
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 6CE0A1B34F7 for <kitten@ietfa.amsl.com>; Sun,  4 Oct 2015 16:31: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 dWKng5hSUHNk for <kitten@ietfa.amsl.com>; Sun,  4 Oct 2015 16:31:25 -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 1A84E1B34ED for <kitten@ietf.org>; Sun,  4 Oct 2015 16:31:22 -0700 (PDT)
X-AuditID: 12074423-f793f6d000007fc1-af-5611b6c9a1dd
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-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.65.32705.9C6B1165; Sun,  4 Oct 2015 19:31:21 -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 t94NVK3e011035; Sun, 4 Oct 2015 19:31:21 -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 t94NVGOd015473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Oct 2015 19:31:20 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t94NVF0I014936; Sun, 4 Oct 2015 19:31:15 -0400 (EDT)
Date: Sun, 4 Oct 2015 19:31:15 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Michiko Short <michikos@microsoft.com>
In-Reply-To: <alpine.GSO.1.10.1508161121510.22210@multics.mit.edu>
Message-ID: <alpine.GSO.1.10.1510012326350.26829@multics.mit.edu>
References: <alpine.GSO.1.10.1508161121510.22210@multics.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+NgFnrFIsWRmVeSWpSXmKPExsUixG6nontym2CYwfQvkhZHN69isfjXzefA 5LFkyU8mj9Ydf9kDmKK4bFJSczLLUov07RK4Mj4/Eyi4K17xuWkWcwPjM+EuRk4OCQETia0t K1khbDGJC/fWs4HYQgKLmSR+bPPtYuQCsjcwSqw99JkVwjnIJPGoaRYLRFW9xO1H59lBbBYB LYlfp98yg9hsAioSM99sBJskAhT/cOE0WD2zgLDE+nMzwGqEBZwlbs88A9bLKeAk0TzhPVgN r4CjxJVJx1gh5jtKfJl9mgnEFhXQkVi9fwpUjaDEyZlPoGZqSSyfvo1lAqPgLCSpWUhSCxiZ VjHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRuYgQHqYvyDsY/B5UOMQpwMCrx8B6I FwwTYk0sK67MPcQoycGkJMobqgYU4kvKT6nMSCzOiC8qzUktPsQowcGsJMLLuwwox5uSWFmV WpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwbt9K1CjYFFqempFWmZOCUKaiYMT ZDgP0PDJIDW8xQWJucWZ6RD5U4yKUuK8tiAJAZBERmkeXC84iexmUn3FKA70ijBvOkgVDzAB wXW/AhrMBDR4gSEfyOCSRISUVANjw8rAL+zV0Z9aZ9cc9jg0X8luUmO4fN9WI/36mFzT27vP aDVUOdd1l4mLpj/gONrTz65zWM3hqfNZ/fU5YRFRwry1jy4FCpgwCX11ms7a8Pm7f7jj3MUN R1w3/v6c+OofzwWj/UGm4X+/z2ssSmt6cP3/vB9dvof+TcjMW/62V6DvhqI5t6gSS3FGoqEW c1FxIgAdBf3I/QIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/CLpRIBaSyESWe43rPW2mXEvVYws>
Cc: kitten@ietf.org
Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2015 23:31:27 -0000

Hi Michiko,

On Sun, 16 Aug 2015, Benjamin Kaduk wrote:

> This message begins the Working Group Last Call (WGLC) of "Public Key
> Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness
> Extension" <draft-ietf-kitten-pkinit-freshness-01>. The WGLC will last two
> weeks, ending on Sunday, August 30th.  The draft is available at:

Looking over the traffic from the WGLC period, it seems that some
revisions to the document are required.  Going over the list's archive:

Greg noted that there was some ambiguity in section 2.4 regarding the
contents of the KRB-ERROR message in the case when a supplied freshness
token is not valid, in his message at
http://www.ietf.org/mail-archive/web/kitten/current/msg05783.html .

That message also raised the question of using KDC_ERR_PREAUTH_FAILED for
a retriable answer, which does not seem to have been resolved yet.  With
no hat on, I'm inclined to avoid KDC_ERR_PREAUTH_FAILED for retriable
errors.

Greg also made some editorial comments in that same message.

Bryce Nordgren also found an editorial change in
http://www.ietf.org/mail-archive/web/kitten/current/msg05794.html (the
content question in that message seems to have been resolved in subsequent
list traffic).

Bryce also notes in a later message that the document should say that the
implementation-defined validation procedure must actually guarantee
freshness.  Something similar to Greg's explanation in
http://www.ietf.org/mail-archive/web/kitten/current/msg05795.html might be
reasonable, say, in the security considerations.

I also supplied a couple editorial comments in
http://www.ietf.org/mail-archive/web/kitten/current/msg05801.html

jhutz made some (mostly) editorial suggestions in his review,
http://www.ietf.org/mail-archive/web/kitten/current/msg05802.html (some of
the non-editorial comments are mitigated by Greg's follow-up in
http://www.ietf.org/mail-archive/web/kitten/current/msg05803.html )

This question from jhutz's message remains unresolved:
"Do we need to call out that a client MUST use a freshness token it got
during an earlier iteration of the same AS exchange?  So, for example,
it can't change its mind about principal names or KDC options or
requested AD and still expect the freshness token to be valid?"  I don't
think this is a particularly critical issue, so it may suffice to just
note that a KDC implementation MAY bind the freshness token to parameters
in the AS-REQ, so the client implementation should use the freshness token
it got during an earlier iteration of the same AS exchange or be prepared
to handle failures resulting from the KDC validation failure for the
binding to the AS-REQ parameter(s).


Can you please generate a revised I-D addressing these comments (i.e.,
including proposed resolutions to the as-yet-unresolved questions)?
Depending on the scope of the changes, another WGLC may be needed; if the
changes are minor and uncontroversial, we might be able to skip it.

Thanks,

Ben


From nobody Sun Oct  4 17:37:23 2015
Return-Path: <kaduk@mit.edu>
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 1B72A1B3B94 for <kitten@ietfa.amsl.com>; Sun,  4 Oct 2015 17:37: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 Ne1YkGyhzNd0 for <kitten@ietfa.amsl.com>; Sun,  4 Oct 2015 17:37:18 -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 A7EC61B3B91 for <kitten@ietf.org>; Sun,  4 Oct 2015 17:37:18 -0700 (PDT)
X-AuditID: 12074425-f79816d000004571-99-5611c63d9bdc
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 05.F1.17777.D36C1165; Sun,  4 Oct 2015 20:37:17 -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 t950bGjY010254 for <kitten@ietf.org>; Sun, 4 Oct 2015 20:37:17 -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 t950bDWj001280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <kitten@ietf.org>; Sun, 4 Oct 2015 20:37:16 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t950bDeX023251; Sun, 4 Oct 2015 20:37:13 -0400 (EDT)
Date: Sun, 4 Oct 2015 20:37:13 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
Message-ID: <alpine.GSO.1.10.1510041931331.26829@multics.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+NgFtrHIsWRmVeSWpSXmKPExsUixG6nrmt7TDDMYP0mAYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/KuE4wFt3grfr/bzNzAuIu7i5GTQ0LAROL/ykOMELaYxIV7 69m6GLk4hAQWM0k0/pnADuEcY5TYdOQNG0iVkMB1Jom/B2Qg7HqJo8f/gcVZBLQkmtZcA7PZ BFQkZr7ZCGaLCAhL7N76jhnEFhbQkdiwczrYNl4BR4mJe2+xgNiiQPHV+6ewQMQFJU7OfAJm MwPNXD59G8sERr5ZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3E CA4mF9UdjBMOKR1iFOBgVOLhlUgSDBNiTSwrrsw9xCjJwaQkyhuqBhTiS8pPqcxILM6ILyrN SS0+xCjBwawkwqtzGCjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTB W3cUqFGwKDU9tSItM6cEIc3EwQkynAdoeBhIDW9xQWJucWY6RP4Uo6KUOK/XEaCEAEgiozQP rhcc7buZVF8xigO9Isy7B6SKB5go4LpfAQ1mAhq8wJAPZHBJIkJKqoFRI1niw/vPPqtT3n+X y2HdpPJOt6omJ8L3qpLrVq85TGekGc46LAhzdFF0XTf7y3TFOv4eh0+9EglCLz1yuTIOyJXV sS+WqmL0d++JCCoIfJyrW3Or4bgl/+qwm+8/rQ/f+0m0MIy3TzLYRiy+XGvPCs2d2mmTekwU /X4oblup3ZZtsnm3gBJLcUaioRZzUXEiAOxbuYjRAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/Oa0oTT8q_N9c6wG1OVF19s5d4M4>
Subject: [kitten] WGLC on draft-ietf-kitten-cammac-03
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 00:37:21 -0000

This message begins the second Working Group Last Call (WGLC) of "Kerberos
Authorization Data Container Authenticated by Multiple MACs"
<draft-ietf-kitten-cammac-03>.  A previous version of this document was
approved by the IESG for publication, but while the document was in the
RFC Editor queue, an error was discovered regarding processing CAMMACs in
cross-realm TGTs [0] that required changes to the document, so it was
brought back to the working group for further modifications.

Although the changes since the previously approved version are only in the
Security Considerations section, the entire document is open for review
during this WGLC.  The WGLC will last two weeks, ending on Sunday, October
18th.  The draft is available at:

https://tools.ietf.org/html/draft-ietf-kitten-cammac-03

A diff of the changes since the previously approved version is available
at:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-03.txt&url1=draft-ietf-kitten-cammac-01.txt

Please review the document and send comments to the Working Group mailing
list kitten@ietf.org or the co-chairs kitten-chairs@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.  This is particularly important if you found issues with the
previous version.

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

[0] http://www.ietf.org/mail-archive/web/kitten/current/msg05336.html


From nobody Tue Oct  6 05:47:16 2015
Return-Path: <alex@um.es>
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 2F81F1B4050 for <kitten@ietfa.amsl.com>; Tue,  6 Oct 2015 05:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 jkJNr_Hpy5Vp for <kitten@ietfa.amsl.com>; Tue,  6 Oct 2015 05:47:11 -0700 (PDT)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 295A11B4065 for <kitten@ietf.org>; Tue,  6 Oct 2015 05:47:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id CFE606F5B for <kitten@ietf.org>; Tue,  6 Oct 2015 14:47:09 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UaCPGobsuxTe for <kitten@ietf.org>; Tue,  6 Oct 2015 14:47:09 +0200 (CEST)
Received: from [192.168.1.7] (84.121.15.122.dyn.user.ono.com [84.121.15.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 97BAA6FD9 for <kitten@ietf.org>; Tue,  6 Oct 2015 14:47:07 +0200 (CEST)
To: kitten@ietf.org
References: <20150925180747.10698.24465.idtracker@ietfa.amsl.com>
From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= <alex@um.es>
Message-ID: <5613C2CB.7030303@um.es>
Date: Tue, 6 Oct 2015 14:47:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20150925180747.10698.24465.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------090000060601020106070609"
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/6B89pxS8M-kpLFtFgqTw7rgYkao>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-13.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2015 12:47:15 -0000

This is a multi-part message in MIME format.
--------------090000060601020106070609
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Dear Scott and Simon,

I have reviewed the latest version of the draft-ietf-kitten-sasl-saml-ec 
(v13). In my opinion, the document is well written and very clear, and 
it is relatively easy to follow if you are somewhat familiar with SAML, 
SASL and GSS-API. The outline of the SAML ECP profile given in section 3 
is really helpful to avoid sending the reader to check the [SAMLECP20] 
document right-away , and the example given in section 6 is clarifying 
and helps to understand how the proposal works.

There are however a few minor points that are not clear to me, so I'd 
appreciate if you could clarify them:

#1 In the document, the difference between SAML20EC and SAML20EC-PLUS is 
not clearly described. There is only a brief mention in section 4 
indicating that the latter one means that ChannelBindings are supported, 
but there are not further explanation nor mention. If you are not 
familiar with RFC5801 (I wasn't), you need to figure out that the -PLUS 
suffix comes from that document. I think adding a reference to 5801 at 
this point would be useful.

#2 Section 4 is titled "SAML SASL Mechanism Specification", when I think 
it would be more correct titling it as "SAML Enhanced Client SASL 
Mechanism Specification" (as in the document title).

#3 Should

    "If the client is unable to obtain a response from the IdP, or must
    otherwise signal, failure, it responds to the SASL server with a
    SOAP envelope containing a SOAP fault."

actually be

    "If the client is unable to obtain a response from the IdP, or must
    otherwise signal a failure, it responds to the SASL server with a
    SOAP envelope containing a SOAP fault."

?

#4 Section 4.7. A reference to section 5.6.2 might be useful here to 
figure out what a "service name" looks like.

#5 Section 4.7. Does the URI format allow using "service@host" as a 
value? (just asking)

#6 Section 4.7. I found problems parsing the following sentence (I'm not 
a native speaker, so please ignore my comment if the sentence is correct)

"The value MUST be securely associated with the SAML entityID claimed
    by the SASL server by the identity provider, such as ..."

To be more specific, two "by" too close in the same sentence made me 
confused about who was making the association.

#7 Section 5, paragraph 2. I think referring to RFC 5801 would provide 
further explanation on why this is done in this way.

#8 Section 5, paragraph 4. Should "mutual-auth" be "mut" instead?

#9 Section 5.6.2. There is a repetition of great part of the text about 
the responseConsumerURL and AssertionConsumerServiceURL from section 4.7.

Best regards,
Alejandro


El 25/09/15 a las 20:07, internet-drafts@ietf.org escribió:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.
>
>          Title           : SAML Enhanced Client SASL and GSS-API Mechanisms
>          Authors         : Scott Cantor
>                            Simon Josefsson
> 	Filename        : draft-ietf-kitten-sasl-saml-ec-13.txt
> 	Pages           : 39
> 	Date            : 2015-09-25
>
> Abstract:
>     Security Assertion Markup Language (SAML) 2.0 is a generalized
>     framework for the exchange of security-related information between
>     asserting and relying parties.  Simple Authentication and Security
>     Layer (SASL) and the Generic Security Service Application Program
>     Interface (GSS-API) are application frameworks to facilitate an
>     extensible authentication model.  This document specifies a SASL and
>     GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
>     SAML-aware "enhanced client" to address significant barriers to
>     federated authentication in a manner that encourages reuse of
>     existing SAML bindings and profiles designed for non-browser
>     scenarios.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-saml-ec-13
>
>
> 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


--------------090000060601020106070609
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Dear Scott and Simon,<br>
    <br>
    I have reviewed the latest version of the
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    draft-ietf-kitten-sasl-saml-ec (v13). In my opinion, the document is
    well written and very clear, and it is relatively easy to follow if
    you are somewhat familiar with SAML, SASL and GSS-API. The outline
    of the SAML ECP profile given in section 3 is really helpful to
    avoid sending the reader to check the [SAMLECP20] document
    right-away , and the example given in section 6 is clarifying and
    helps to understand how the proposal works.<br>
    <br>
    There are however a few minor points that are not clear to me, so
    I'd appreciate if you could clarify them:<br>
    <br>
    #1 In the document, the difference between SAML20EC and
    SAML20EC-PLUS is not clearly described. There is only a brief
    mention in section 4 indicating that the latter one means that
    ChannelBindings are supported, but there are not further explanation
    nor mention. If you are not familiar with RFC5801 (I wasn't), you
    need to figure out that the -PLUS suffix comes from that document. I
    think adding a reference to 5801 at this point would be useful.<br>
    <br>
    #2 Section 4 is titled "SAML SASL Mechanism Specification", when I
    think it would be more correct titling it as "SAML Enhanced Client
    SASL Mechanism Specification" (as in the document title).<br>
    <br>
    #3 Should <br>
    <blockquote>"If the client is unable to obtain a response from the
      IdP, or must otherwise signal, failure, it responds to the SASL
      server with a SOAP envelope containing a SOAP fault." <br>
    </blockquote>
    actually be <br>
    <blockquote>"If the client is unable to obtain a response from the
      IdP, or must otherwise signal a failure, it responds to the SASL
      server with a SOAP envelope containing a SOAP fault."<br>
    </blockquote>
    ?<br>
    <br>
    #4 Section 4.7. A reference to section 5.6.2 might be useful here to
    figure out what a "service name" looks like.<br>
    <br>
    #5 Section 4.7. Does the URI format allow using "service@host" as a
    value? (just asking)<br>
    <br>
    #6 Section 4.7. I found problems parsing the following sentence (I'm
    not a native speaker, so please ignore my comment if the sentence is
    correct)<br>
    <br>
    "The value MUST be securely associated with the SAML entityID
    claimed<br>
       by the SASL server by the identity provider, such as ..."<br>
    <br>
    To be more specific, two "by" too close in the same sentence made me
    confused about who was making the association.<br>
    <br>
    #7 Section 5, paragraph 2. I think referring to RFC 5801 would
    provide further explanation on why this is done in this way.<br>
    <br>
    #8 Section 5, paragraph 4. Should "mutual-auth" be "mut" instead?<br>
    <br>
    #9 Section 5.6.2. There is a repetition of great part of the text
    about the responseConsumerURL and AssertionConsumerServiceURL from
    section 4.7.<br>
    <br>
    Best regards,<br>
    Alejandro<br>
    <br>
    <br>
    <div class="moz-cite-prefix">El 25/09/15 a las 20:07,
      <a class="moz-txt-link-abbreviated" href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a> escribió:<br>
    </div>
    <blockquote
      cite="mid:20150925180747.10698.24465.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

        Title           : SAML Enhanced Client SASL and GSS-API Mechanisms
        Authors         : Scott Cantor
                          Simon Josefsson
	Filename        : draft-ietf-kitten-sasl-saml-ec-13.txt
	Pages           : 39
	Date            : 2015-09-25

Abstract:
   Security Assertion Markup Language (SAML) 2.0 is a generalized
   framework for the exchange of security-related information between
   asserting and relying parties.  Simple Authentication and Security
   Layer (SASL) and the Generic Security Service Application Program
   Interface (GSS-API) are application frameworks to facilitate an
   extensible authentication model.  This document specifies a SASL and
   GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
   SAML-aware "enhanced client" to address significant barriers to
   federated authentication in a manner that encourages reuse of
   existing SAML bindings and profiles designed for non-browser
   scenarios.


The IETF datatracker status page for this draft is:
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/">https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/</a>

There's also a htmlized version available at:
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-13">https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-13</a>

A diff from the previous version is available at:
<a class="moz-txt-link-freetext" href="https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-saml-ec-13">https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-saml-ec-13</a>


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:
<a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a>

_______________________________________________
Kitten mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kitten@ietf.org">Kitten@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/kitten">https://www.ietf.org/mailman/listinfo/kitten</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090000060601020106070609--


From nobody Thu Oct  8 19:21:13 2015
Return-Path: <cantor.2@osu.edu>
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 2D65C1ACE51 for <kitten@ietfa.amsl.com>; Thu,  8 Oct 2015 19:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_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 iPuHVuyA2QZ5 for <kitten@ietfa.amsl.com>; Thu,  8 Oct 2015 19:21:06 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25C01ACE90 for <kitten@ietf.org>; Thu,  8 Oct 2015 19:21:05 -0700 (PDT)
Received: from BL2FFO11OLC009.protection.gbl (10.173.160.34) by BL2FFO11HUB006.protection.gbl (10.173.160.226) with Microsoft SMTP Server (TLS) id 15.1.293.9; Fri, 9 Oct 2015 02:20:47 +0000
Authentication-Results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu;
Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.222 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.222; helo=cio-tnc-pf08.osuad.osu.edu;
Received: from cio-tnc-pf08.osuad.osu.edu (164.107.81.222) by BL2FFO11OLC009.mail.protection.outlook.com (10.173.160.145) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Fri, 9 Oct 2015 02:20:47 +0000
Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by cio-tnc-pf08.osuad.osu.edu (Postfix) with ESMTPS id EC13C2E0035; Thu,  8 Oct 2015 22:20:46 -0400 (EDT)
Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0248.002; Thu, 8 Oct 2015 22:20:46 -0400
From: "Cantor, Scott" <cantor.2@osu.edu>
To: =?utf-8?B?QWxlamFuZHJvIFDDqXJleiBNw6luZGV6?= <alex@um.es>, "kitten@ietf.org" <kitten@ietf.org>
Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-13.txt
Thread-Index: AQHQ970mZTmrB8o+pkaWgGl5kszPup5evcuAgAPE74A=
Date: Fri, 9 Oct 2015 02:20:46 +0000
Message-ID: <89F841A1-D6CC-4657-8332-ABAB9DE2B6C3@osu.edu>
References: <20150925180747.10698.24465.idtracker@ietfa.amsl.com> <5613C2CB.7030303@um.es>
In-Reply-To: <5613C2CB.7030303@um.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.146.14.12]
x-header-sapphire: true
Content-Type: text/plain; charset="utf-8"
Content-ID: <5B2BDF25A4E4004FBE594E297A728708@osu.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC009; 1:3OeUuP7J1/U7hVqHNRs1Bx00OdVM79KU6aYzTVF5iZAnV3xIxDaVt998S9uWEk10mXlsCr600b+NCoxOmXxiBrb9AsXgs3lGNwvQmeebCb0isVBE44IEKwwwoTFD3Bjpf/uT6E6w0ZeOJaOKqRndceu2Ec+jDt7eB1yhxhZNbkA1Kw6UXBK1dIjNIgzwvfIEo+GLmWH5TDQLxBQyld8WnO8Kj1jX63dQp3tg6RjMldfb3SIMW9fvf3gDYs47Rgxv+7QL336Kx8BKPj6f299gclUae98QEImb+/zXZfwMEtyKraGrqU83/G+hiVNrK4J7CJujvypGoJ2u+EVQPI+DI/PPW3/5HlhuaRGjflEiVh0smFtmz42CQN9wuUOV5ZksBZAO26RhdE7AaqfpB8OtMQ==
X-Forefront-Antispam-Report: CIP:164.107.81.222; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(479174004)(189002)(377454003)(199003)(43784003)(24454002)(6806005)(82746002)(189998001)(93346002)(75432002)(230783001)(109096001)(87936001)(19580395003)(19580405001)(83716003)(90282001)(23676002)(106116001)(50466002)(46102003)(92566002)(2900100001)(5008740100001)(2950100001)(89122001)(36756003)(47776003)(5250100002)(5001770100001)(54356999)(76176999)(50986999)(2501003)(107886002)(106466001)(11100500001)(102836002)(88552001)(5003600100002)(64706001)(66066001)(5004730100002)(86362001)(33656002)(5007970100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB006; H:cio-tnc-pf08.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf08.osuad.osu.edu; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB006; 2:Kv/q3xINeU0o3ssFUan9z8120LS86i+bTnsRT0t2TZqCFytw/dCqvF01ZlEedE3Be3mxKwr9TIj++RcraldYtY9dNTLXS2z0e++tbtphcICtpSRZm+Li7vACEU37kUnfTPEARPqXKf97YpAxtoVvnzJkhP3T+C0e+bLKjs9uPvg=; 3:19AUlAvCd9VTYHd3OHSlDXMAsxittCG4y1pFuC7UT9FDu5qbSv4AFjTHNcN1dro6vgUP0eYBbLFD0xgxFovTNTl6ndAyx4fA9M1hXHObiAf2RQINEs4WHFxzxNngfGJhVAFIqCxGD/f5U9ytTmA2y1KRni2NtkFwMuA0+923uBHcYei328w9uGx0ucfwoIXe7sYOdbOaBSjS3UlX7noc2OZAbuFLSR9Oh975gEhA/txstxq8zXBIeziOoHjoODiVaeaasfcsBXSpEqlWsxcntg==; 25:0Wy7+BGKFNAC42f+M3JmGKQ8pt7K8Zx36pxmLsRbmfS6l4PWDnB4+r8xCS6N8E9xsHGME3osAgkYtzJdc3RPfK5jHhzLoju/eS3/FCRwTIkrvcmVa3gMLdQSC292UmrcIFMzX9OAvnvw45eMtkvWF1ZrhzElibJhWta2Q18co2wqy3Abt/7RSkwqg+/HAVX2cIffj1lm0TxKC7IDHE0uY/O96GtpdFvwjmHIG+oUys2UEPz5atcRnWXq0nKVPM1k
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BL2FFO11HUB006; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB006; 20:OQKMJtHdnlEQ3y0l68H4yZTVtIhPnxQken0P02XvLObdxfINoeSAIO1ZUcymqf45Ti1KK5tH/JAuOr6fB2ED0L+Eb40Qnxjry6T93khIsXe7bldJqYsgXO4Ek3a4dbUnBiWZijhydxSpNYmLAa2Q+wr+GL6/HLeHvJwrKdIcqWU/QkXsIYlVjvpZZREDFiPOva/d8uVOE2wVBI0zAxf8EHLZJpAhbVNC6G48uX/jVWksr/I8osj0tgK+EparomXgwGfnfeV0wiocD+OOtFuCbsf6a9Innck08NtgVNZFo01y50cgT68mmI/GItBHUYZmgLjDXTqHEsp0H0kbTJneJXRn6id6RyhhsKSFtCXE55V9l2KnKvzqeJekGQSd8IWvNwpsfbqONsoDUAne18ZIZNKGkKFDtTMhnj4DdBwQizWNwzBZ2U0MbWUH9c+i7X+JDmApWZgCPr5k3BSSWJebQF16WaYpwse/rGqDnVRY/A2uAr5M9WLhEvBPok4Z8EIU; 4:n520Xgzfd2mjoasPFoY5hMwRPK73JBcEMNZY6YngywoEGNytu6PUi9yKN67zKjlmQP3wthJipAgcNx++m2xnwGqrP3jCksGJX//KFZNMjr/zghfwC7wzTfbb8t2jZpDjITaLkOB6TIQaY6aMVt+pLHUxelEbUT7nH1kr9WxXuyPbvexWUVdFYKKPazEkARjjbrq54oeAgUTprJ2i5A/6ImgW/KUw3mqpHvLoW74j/a99rDnohQFsD/YQCpiqYFSQXSiSjoVHjwzFUBpHPG1S7A2ZhriXCQiuR8Gg7aCAj3flRLd1uIQtd+ue8dekUnj5o9tgXBd3WvccHYRtI4iEtzRkeHEZw8oo3bPAbGNACDoNgr9S6b3Z6VAqr5wIWn/U
X-Microsoft-Antispam-PRVS: <BL2FFO11HUB006183CC00351BA1C2FDDC3D0340@BL2FFO11HUB006.protection.gbl>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10115024); SRVR:BL2FFO11HUB006; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB006; 
X-Forefront-PRVS: 0724FCD4CD
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJGRk8xMUhVQjAwNjsyMzo3QVlFMnpsOGgwT1dFRHdsT2hsZmlGdUp6?= =?utf-8?B?SUljOVRScGNYSjZJQjYrc3VJb0pQUEhES2RDYUVkLzFpZ002S3ZsL2FYMHFE?= =?utf-8?B?VFk5VEZyL2ZQc1Z5Wkt5VFg5N0ZkazZKbE5kRnhaK0xwSE5YK08rV1ZzNjhW?= =?utf-8?B?MEJ4RlRSakdJVFhBREJtTlJnWmZCTEgwZGthQy95c0VIbkpFZUFnZ0g5aHpN?= =?utf-8?B?V3BhUGNFWUN1MjB0cWVxbDlRL2w0ZHVXZlg5U29uRTZaanhEZ1lrb01vZG9V?= =?utf-8?B?UGxMYlcvTEtUZ0RzaW1XOVhOM2wwZFlvQ0ZxTDlycllvVVNteFlJL1pvT2pQ?= =?utf-8?B?Skh2Z1NWb3d6WFlDVHNmTVZFWC9GSHpuYUJrTkRvQXJ2Tm9FS1RRN0xqQ09O?= =?utf-8?B?THVHanU5UGtDSnMvUHVvLzZ3Mjl3a2tLRFRRK2NxK0tZeWlEd1drejRoYkk4?= =?utf-8?B?TjhkL3RXY2NFWWhqM3dINWFVSVpveGx5OWVYYkpGamNnQ3NHTEJuUWJpVGxO?= =?utf-8?B?Q1c3em5YcU9CNkJ3TlQyajVkSWNqUGs4dTJnd0MvYm9OVkN5NngvYWZMZEFP?= =?utf-8?B?MHB3Wld1YklmdkRRaE8xa2dqZWxKUXFRQWJFMDJybVB4eElpNWZ1UkIrZFRG?= =?utf-8?B?SCtRdHBaK3J0eVlJdi9YOGxzRkpvN0lHdml5TGsvVE1Fc3VPTVRxKzJQaXF6?= =?utf-8?B?WW9GVlJJMW9DS1huTmxtN2t5YUx6citiQXk3MlYxUVpQdEgzdGVlZHpLRGhY?= =?utf-8?B?bzRaTng0bzl6UlREQ3hOcUphK095dmxCL1dUSlNFMEZIZnFaRk5Oa29FSzUv?= =?utf-8?B?eDNtZnJ5VHFzTldSc0JycGtuT0xKTk5wMnpaSUJTZ25kSDBGdGpoOW1xWmhS?= =?utf-8?B?c2xyWTQ2SklrQU9acS9lbnZGdVJHQWNGNXVZVURsNmdJOUF1ZGJuZEpXcjVk?= =?utf-8?B?RDZFK29iZlhyV25hb2hta3dqV0FCV3EzbGZuSEIrb1ZoUzZRZHdLakJEY0pT?= =?utf-8?B?dGdMTE56NHFQZ2hlNFMycm11c0ZEeThDamlsVXZZNEsvWjh1RDdSWE1xRVI4?= =?utf-8?B?S1A2c2F0TmZaSzUwMzQ1enNRMEZhVUxHd3RDa1htaXpabkNLaHVOaGNwc1hs?= =?utf-8?B?cTF3V3pTVlVId0hnUXVaU3hjL2RWR1M5TWF4LzR1L1d3VlNHM2paY052Y0Np?= =?utf-8?B?S1FsQzZTWm1hMFhZcklPY29qVTJQc3JRUGtiemNxZVFXRTBNcEhzTGR5ME9R?= =?utf-8?B?bzJpVmJvaWZRTk5LalFnT0JEMmx5bXJuNlErK1BNVGZ3MUlrSUV4R1JJaW9o?= =?utf-8?B?NlptSzQwcG5hL0g4TU9zRkNCUTFnSDJJenVUTmtDbGYySEFUcFZEbGhkSEtE?= =?utf-8?B?NkJ2WmtvUjA5ZWh5Y1VySnJpem1YUnVvMG92TnRQdnkreFVmMTZHSHVyS25Z?= =?utf-8?B?dGQvbkhjcTFZTWNnTERacHJVMlhyWlJLWnBWdHVtT1dWUmJCS3E5QWhJR2Fj?= =?utf-8?B?eWNRVUJadG5tUUYyWWROVE1xZWR6YXEwQzhtZ09IdnRwa1kweXp3bEVoQ3Bk?= =?utf-8?B?RTBXOEVnZG1CSzBLdFdqcWsyeHhnWWtOc3FUekUwdG5JKzBlOGt5R0Vtb3Bi?= =?utf-8?B?OFZvaW9ZQWUzS1JvT0gwRUZIaXNhcWd6KzNYN1lGdm5yRFpPbGxYa3dJcnhS?= =?utf-8?B?dWtGelpFTG53dmZWVmdhbTc5UmFGNmVMdlFkbndpakhLeHRLdXBwM0tBcXo1?= =?utf-8?B?dGVLV28ybDUxUlE1aXBTa3plaEpDUGdONTd5eUVRcnNWNkVJYXo1aVpMOXVm?= =?utf-8?Q?1qZ0ZF79tzaL6g?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB006; 5:fcmK7c6+5Z8cDC4NZAbDa9rMl5bIA5GTCiB/dmZ+N70kMGJw5SUB5Ga5K51WtByM3j46SpJrL1xup6s5FZPAR4P/ZixF5Jka269O+1P5glDriH0BLsDIP4U+OSfeN9QfioMY23FZMHVHdPQMPffHZA==; 24:We7Zq4Zit6PRhXIRgOZoqjELg6i2jM+3fLLheJN/2OO53mWlmsa1n7OXY5Wsu/d6ekwOvgTEU9tlV+tGbAVs2akNAKZnK4a/A+YU9AV/o8o=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: osu.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2015 02:20:47.5950 (UTC)
X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.222];  Helo=[cio-tnc-pf08.osuad.osu.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB006
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/c680nxZqRQQWmsAD-c48EZPbg7A>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-13.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 02:21:12 -0000

VGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3LiBSZXNwb25zZXMgaW5saW5lLi4uDQoN
Ck9uIDEwLzYvMTUsIDg6NDcgQU0sICJLaXR0ZW4gb24gYmVoYWxmIG9mIEFsZWphbmRybyBQw6ly
ZXogTcOpbmRleiIgPGtpdHRlbi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhbGV4QHVt
LmVzPiB3cm90ZToNCg0KPg0KPiMxIEluIHRoZSBkb2N1bWVudCwgdGhlIGRpZmZlcmVuY2UgYmV0
d2VlbiBTQU1MMjBFQyBhbmQgU0FNTDIwRUMtUExVUyBpcyBub3QgY2xlYXJseSBkZXNjcmliZWQu
IFRoZXJlIGlzIG9ubHkgYSBicmllZiBtZW50aW9uIGluIHNlY3Rpb24gNCBpbmRpY2F0aW5nIHRo
YXQgdGhlIGxhdHRlciBvbmUgbWVhbnMgdGhhdCBDaGFubmVsQmluZGluZ3MgYXJlIHN1cHBvcnRl
ZCwgYnV0IHRoZXJlIGFyZSBub3QgZnVydGhlciBleHBsYW5hdGlvbiBub3IgbWVudGlvbi4NCj4g
SWYgeW91IGFyZSBub3QgZmFtaWxpYXIgd2l0aCBSRkM1ODAxIChJIHdhc24ndCksIHlvdSBuZWVk
IHRvIGZpZ3VyZSBvdXQgdGhhdCB0aGUgLVBMVVMgc3VmZml4IGNvbWVzIGZyb20gdGhhdCBkb2N1
bWVudC4gSSB0aGluayBhZGRpbmcgYSByZWZlcmVuY2UgdG8gNTgwMSBhdCB0aGlzIHBvaW50IHdv
dWxkIGJlIHVzZWZ1bC4NCg0KV2lsbCBkby4NCg0KPiMyIFNlY3Rpb24gNCBpcyB0aXRsZWQgIlNB
TUwgU0FTTCBNZWNoYW5pc20gU3BlY2lmaWNhdGlvbiIsIHdoZW4gSSB0aGluayBpdCB3b3VsZCBi
ZSBtb3JlIGNvcnJlY3QgdGl0bGluZyBpdCBhcyAiU0FNTCBFbmhhbmNlZCBDbGllbnQgU0FTTCBN
ZWNoYW5pc20gU3BlY2lmaWNhdGlvbiIgKGFzIGluIHRoZSBkb2N1bWVudCB0aXRsZSkuDQoNCisx
DQoNCj4jMyBTaG91bGQgDQo+DQo+IklmIHRoZSBjbGllbnQgaXMgdW5hYmxlIHRvIG9idGFpbiBh
IHJlc3BvbnNlIGZyb20gdGhlIElkUCwgb3IgbXVzdCBvdGhlcndpc2Ugc2lnbmFsLCBmYWlsdXJl
LCBpdCByZXNwb25kcyB0byB0aGUgU0FTTCBzZXJ2ZXIgd2l0aCBhIFNPQVAgZW52ZWxvcGUgY29u
dGFpbmluZyBhIFNPQVAgZmF1bHQuIg0KPmFjdHVhbGx5IGJlDQo+IklmIHRoZSBjbGllbnQgaXMg
dW5hYmxlIHRvIG9idGFpbiBhIHJlc3BvbnNlIGZyb20gdGhlIElkUCwgb3IgbXVzdCBvdGhlcndp
c2Ugc2lnbmFsIGEgZmFpbHVyZSwgaXQgcmVzcG9uZHMgdG8gdGhlIFNBU0wgc2VydmVyIHdpdGgg
YSBTT0FQIGVudmVsb3BlIGNvbnRhaW5pbmcgYSBTT0FQIGZhdWx0LiINCj4/DQoNClllcywgc3Ry
YXkgY29tbWEuDQoNCj4jNCBTZWN0aW9uIDQuNy4gQSByZWZlcmVuY2UgdG8gc2VjdGlvbiA1LjYu
MiBtaWdodCBiZSB1c2VmdWwgaGVyZSB0byBmaWd1cmUgb3V0IHdoYXQgYSAic2VydmljZSBuYW1l
IiBsb29rcyBsaWtlLg0KDQpXaWxsIHRha2UgYSBsb29rLg0KDQo+IzUgU2VjdGlvbiA0LjcuIERv
ZXMgdGhlIFVSSSBmb3JtYXQgYWxsb3cgdXNpbmcgInNlcnZpY2VAaG9zdCIgYXMgYSB2YWx1ZT8g
KGp1c3QgYXNraW5nKQ0KDQpUaGVyZSdzIGJlZW4gZGlzY3Vzc2lvbiBvbiB0aGlzIGludGVybmFs
bHkgYnkgSW5Db21tb24uIEluIFNBTUwgdGVybXMsIHRoZSB1c2Ugb2YgYW55VVJJIGluIHRoZSBz
Y2hlbWEgaW1wbGllcyBhbiBhYnNvbHV0ZSBVUkwgdW5sZXNzIHNvbWV0aGluZyBvdmVycmlkZXMg
dGhhdCBhc3N1bXB0aW9uLiBTeW50YWN0aWNhbGx5LCBzZXJ2aWNlQGhvc3QgaXMganVzdCBhIHJl
bGF0aXZlIFVSSS4NCg0KSW4gbWV0YWRhdGEsIHRoZSBmb3JtYXQgb2YgdGhlIExvY2F0aW9uIGF0
dHJpYnV0ZSBpbiBhbiBFbmRwb2ludFR5cGUgaXMgZGVwZW5kZW50IG9uIHRoZSBCaW5kaW5nIHZh
bHVlLiBJbiB0aGlzIGNhc2UsIHRoZSBvcmlnaW5hbCBkcmFmdCByZXVzZWQgdGhlIFBBT1MgQmlu
ZGluZyBVUkkgaW4gb3JkZXIgdG8gcmVtYWluIDEwMCUgY29tcGF0aWJsZSB3aXRoIGFuIHVubW9k
aWZpZWQgSWRQIHN1cHBvcnRpbmcgdGhlIHN0YW5kYXJkIEVDUCBwcm9maWxlLg0KDQpTdHJpY3Rs
eSBzcGVha2luZywgUEFPUyBpc24ndCByZWFsbHkgSFRUUCBzcGVjaWZpYywgYnV0IGFsc28gZG9l
c24ndCBzYXkgYW55dGhpbmcgdGhhdCB3b3VsZCBvdmVycmlkZSB0aGUgYXNzdW1wdGlvbiB0aGF0
IHRoZSBsb2NhdGlvbnMgaGF2ZSB0byBiZSBhYnNvbHV0ZSBVUklzLiBJdCBhbHNvIGRvZXNuJ3Qg
cmVhbGx5IGJyZWFrIGFueXRoaW5nLCBiZWNhdXNlIHNvZnR3YXJlIGRvZXNuJ3QgZ2VuZXJhbGx5
IGNhcmUsIGFuZCB0aGVyZSBhcmUgbm8gb3ZlcmxhcHMgYmV0d2VlbiBhIEdTUyBzZXJ2aWNlIG5h
bWUgYW5kIGFuIEhUVFAgZW5kcG9pbnQgdGhhdCB3b3VsZCBiZSB1c2VkIHdpdGggUEFPUyBvdGhl
cndpc2UuDQoNCkhvd2V2ZXIsIHRvIGF2b2lkIGFyZ3VtZW50cyBhYm91dCBpdCwgZHJhZnQtMTMg
YWRkZWQgYSBuZXcgQmluZGluZyB2YWx1ZSB0byB1c2UgZm9yIHRoaXMgbWVjaGFuaXNtIHRoYXQg
aXMgcHJlZmVycmVkIG92ZXIgdGhlIHVzZSBvZiB0aGUgUEFPUyBCaW5kaW5nIHZhbHVlLCB0byBl
eHBsaWNpdGx5IHdvcmsgYXJvdW5kIHRoZSBpc3N1ZSwgYW5kIEkgYWRkZWQgc3VwcG9ydCBmb3Ig
aXQgdG8gdGhlIHVwY29taW5nIFNoaWJib2xldGggcmVsZWFzZS4NCg0KSW5Db21tb24gYWxyZWFk
eSBwdWJsaXNoZWQgYSBQQU9TIGVuZHBvaW50IHdpdGggdGhpcyBzeW50YXggYmVjYXVzZSB0aGVy
ZSBhcmUgYWxyZWFkeSBzb21lIGRlcGxveW1lbnRzIG9mIHRoZSBvbGRlciBkcmFmdHMsIGFuZCB3
aWxsIGV2ZW50dWFsbHkgSSBpbWFnaW5lIHN1cHBvcnQgdGhlIG5ldyBCaW5kaW5nLiBJIHdvdWxk
IGV4cGVjdCBhbnkgd2lkZXIgdXNlIHRvIHN0YW5kYXJkaXplIG9uIHRoZSBuZXcgdmFsdWUuDQoN
CkFsbCBpbiBhbGwsIEknZCByYXRoZXIgZmlnaHQgb3ZlciB0aGUgbWV0YWRhdGEgaXNzdWUgdGhh
biBkZWFsIHdpdGggY2Fub25pY2FsaXppbmcgR1NTIG5hbWVzIGludG8gVVJJcyBhdCB0aGlzIHBv
aW50Lg0KDQo+IzYgU2VjdGlvbiA0LjcuIEkgZm91bmQgcHJvYmxlbXMgcGFyc2luZyB0aGUgZm9s
bG93aW5nIHNlbnRlbmNlIChJJ20gbm90IGEgbmF0aXZlIHNwZWFrZXIsIHNvIHBsZWFzZSBpZ25v
cmUgbXkgY29tbWVudCBpZiB0aGUgc2VudGVuY2UgaXMgY29ycmVjdCkNCj4NCj4iVGhlIHZhbHVl
IE1VU1QgYmUgc2VjdXJlbHkgYXNzb2NpYXRlZCB3aXRoIHRoZSBTQU1MIGVudGl0eUlEIGNsYWlt
ZWQNCj4gICBieSB0aGUgU0FTTCBzZXJ2ZXIgYnkgdGhlIGlkZW50aXR5IHByb3ZpZGVyLCBzdWNo
IGFzIC4uLiINCj4NCj5UbyBiZSBtb3JlIHNwZWNpZmljLCB0d28gImJ5IiB0b28gY2xvc2UgaW4g
dGhlIHNhbWUgc2VudGVuY2UgbWFkZSBtZSBjb25mdXNlZCBhYm91dCB3aG8gd2FzIG1ha2luZyB0
aGUgYXNzb2NpYXRpb24uDQoNCldpbGwgcmV3b3JkLg0KDQo+IzcgU2VjdGlvbiA1LCBwYXJhZ3Jh
cGggMi4gSSB0aGluayByZWZlcnJpbmcgdG8gUkZDIDU4MDEgd291bGQgcHJvdmlkZSBmdXJ0aGVy
IGV4cGxhbmF0aW9uIG9uIHdoeSB0aGlzIGlzIGRvbmUgaW4gdGhpcyB3YXkuDQoNCk9rLg0KDQo+
IzggU2VjdGlvbiA1LCBwYXJhZ3JhcGggNC4gU2hvdWxkICJtdXR1YWwtYXV0aCIgYmUgIm11dCIg
aW5zdGVhZD8NCg0KWWVzLCBJIGJlbGlldmUgc28uDQoNCj4jOSBTZWN0aW9uIDUuNi4yLiBUaGVy
ZSBpcyBhIHJlcGV0aXRpb24gb2YgZ3JlYXQgcGFydCBvZiB0aGUgdGV4dCBhYm91dCB0aGUgcmVz
cG9uc2VDb25zdW1lclVSTCBhbmQgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMIGZyb20gc2Vj
dGlvbiA0LjcuDQoNClRoYXQgZXZvbHZlZCBvdXQgb2YgdGhlIG1lc3Mgd2l0aCB0aGUgQmluZGlu
ZyB0aGF0IHlvdSBpZGVudGlmaWVkLCBidXQgSSdsbCB0YWtlIGFub3RoZXIgbG9vayBhbmQgbWF5
YmUgdHJpbSBvbmUgb2YgdGhlbS4NCg0KSSdsbCBwcm9kdWNlIGEgImZpbmFsIiBkcmFmdCB0aGF0
IHNob3VsZCBob3BlZnVsbHkgYmUgc3VpdGFibGUgZm9yIFdHTEMsIHByb2JhYmx5IHRvbW9ycm93
Lg0KDQpUaGFua3MgYWdhaW4gZm9yIHRoZSBjbG9zZSByZWFkLA0KLS0gU2NvdHQNCg0K


From nobody Fri Oct  9 03:37:01 2015
Return-Path: <simon@josefsson.org>
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 7A6C61A8BB7 for <kitten@ietfa.amsl.com>; Fri,  9 Oct 2015 03:37:00 -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_SE=0.35, 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 vnpxQGxBUs9N for <kitten@ietfa.amsl.com>; Fri,  9 Oct 2015 03:36:58 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 6293C1A8BBD for <kitten@ietf.org>; Fri,  9 Oct 2015 03:36:57 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t99AakPB006888 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 9 Oct 2015 12:36:47 +0200
From: Simon Josefsson <simon@josefsson.org>
To: "Cantor\, Scott" <cantor.2@osu.edu>
References: <20150925180747.10698.24465.idtracker@ietfa.amsl.com> <5613C2CB.7030303@um.es> <89F841A1-D6CC-4657-8332-ABAB9DE2B6C3@osu.edu>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:151009:cantor.2@osu.edu::h8mxcEycKs/Smwpa:too
X-Hashcash: 1:22:151009:kitten@ietf.org::CT5tsbWYIOFNGN7M:2dlD
X-Hashcash: 1:22:151009:alex@um.es::wtNMc9g5oVhYzr0A:2iKV
Date: Fri, 09 Oct 2015 12:36:45 +0200
In-Reply-To: <89F841A1-D6CC-4657-8332-ABAB9DE2B6C3@osu.edu> (Scott Cantor's message of "Fri, 9 Oct 2015 02:20:46 +0000")
Message-ID: <87mvvsmipu.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/x9J6UMYzPM7mnFdbYcSryz_iMhc>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-13.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 10:37:00 -0000

--=-=-=
Content-Type: text/plain

"Cantor, Scott" <cantor.2@osu.edu> writes:

> Thank you for the detailed review. Responses inline...

Again, thank you Alejandro!  Looking at your questions and Scott's
responses, I agree with everything that I have an opinion about.

/Simon


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWF5i9AAoJEIYLf7sy+BGdRLwH/RCNc16VD3GmmKaBXRpE8PKJ
IEEWIenoLAh+MSLpr8YkekJsZcLyZ8Hv6KfBlipkmF1R3hL1pkE9gGWYGNdb/F8R
Z2fU/1rjCzm8bhyo1tr1lDW76+Si3TyEE+A5J2DITJX2DvbYyE/a+Jclb4X2FmHk
YfrykOUCwqxe9oOYK4iObUi27bLOFQ65KkV65HkCG+RFZyXpKf+BaKWy+LNsRfZ5
9++HuWQbFXc0OW8f/GnxwuSgL/IsLoEUOMW80zH+r6XXlQubW0jHio87ImRFKd8p
JTvBLbuDfUpNXeQKtGjTdh4EBPpZPLTO54/rp87Y1WyLjVoYn0vhDVT3OD1Ojl4=
=etsd
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sat Oct 10 00:47:37 2015
Return-Path: <rick@openfortress.nl>
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 C9F6C1B3457 for <kitten@ietfa.amsl.com>; Sat, 10 Oct 2015 00:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gs7XxqBxDlY for <kitten@ietfa.amsl.com>; Sat, 10 Oct 2015 00:47:34 -0700 (PDT)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035501B3456 for <kitten@ietf.org>; Sat, 10 Oct 2015 00:47:33 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id TKnW1r00110HQrX01KnXfQ; Sat, 10 Oct 2015 09:47:31 +0200
Message-ID: <5618C290.7030306@openfortress.nl>
Date: Sat, 10 Oct 2015 09:47:28 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/yN_P-r-dd9Q0SDO57XXPitfqHbg>
Subject: [kitten] I-D: Pseudonymity Support for Kerberos
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Oct 2015 07:47:37 -0000

Hello Kitten,

I've posted an I-D to support pseudonymity in Kerberos; I would like to
have this more refined privacy model for realm crossover to diminish
trust assumptions that need to be made on foreign realms.

Briefly put, pseudonyms can be applied during TGS, based on a KDC option
+ ticket flag.  When the ticket flag is set, the KDC is assumed to
support pseudonymity, and the cname field in TGS-REQ can be filled with
a requested client name; when left out, the KDC is given the permission
to apply pseudonymity if it feels like it.

Any comments on this are highly appreciated.

-Rick

> *From:* internet-drafts@ietf.org
> *Date:* 10 October 2015 09:37
> *To:* "Rick van Rein" <rick@openfortress.nl>
> *Subject:* New Version Notification for
> draft-vanrein-kitten-krb-pseudonymity-00.txt
> A new version of I-D, draft-vanrein-kitten-krb-pseudonymity-00.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:		draft-vanrein-kitten-krb-pseudonymity
> Revision:	00
> Title:		Pseudonymity Support for Kerberos
> Document date:	2015-10-10
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-vanrein-kitten-krb-pseudonymity-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-kitten-krb-pseudonymity/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-kitten-krb-pseudonymity-00
>
>
> Abstract:
>    Kerberos either retains client identity in all its ticket
>    transformations, or it applies rigorous anonymity.  When crossing
>    over to another realm, an intermediate privacy measure is often
>    desired, namely pseudonymity, as described in this specification.
>
> The IETF Secretariat
>


From nobody Sat Oct 10 12:26:16 2015
Return-Path: <internet-drafts@ietf.org>
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 944E51B2BE8; Sat, 10 Oct 2015 12:26:14 -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 QFK01k_XYQNt; Sat, 10 Oct 2015 12:26:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5C21A90D3; Sat, 10 Oct 2015 12:26:13 -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: 6.4.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151010192613.25986.52445.idtracker@ietfa.amsl.com>
Date: Sat, 10 Oct 2015 12:26:13 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/8hIWg8YOyPqfe5d3lVWIY8S_t8I>
Cc: kitten@ietf.org
Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-14.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Oct 2015 19:26:14 -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           : SAML Enhanced Client SASL and GSS-API Mechanisms
        Authors         : Scott Cantor
                          Simon Josefsson
	Filename        : draft-ietf-kitten-sasl-saml-ec-14.txt
	Pages           : 39
	Date            : 2015-10-10

Abstract:
   Security Assertion Markup Language (SAML) 2.0 is a generalized
   framework for the exchange of security-related information between
   asserting and relying parties.  Simple Authentication and Security
   Layer (SASL) and the Generic Security Service Application Program
   Interface (GSS-API) are application frameworks to facilitate an
   extensible authentication model.  This document specifies a SASL and
   GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
   SAML-aware "enhanced client" to address significant barriers to
   federated authentication in a manner that encourages reuse of
   existing SAML bindings and profiles designed for non-browser
   scenarios.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-saml-ec-14


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 Sun Oct 11 01:00:20 2015
Return-Path: <rick@openfortress.nl>
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 0CA571B2A63 for <kitten@ietfa.amsl.com>; Sun, 11 Oct 2015 01:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpqfxUpWbfsh for <kitten@ietfa.amsl.com>; Sun, 11 Oct 2015 01:00:16 -0700 (PDT)
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4491B2A62 for <kitten@ietf.org>; Sun, 11 Oct 2015 01:00:15 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id Tk0D1r00210HQrX01k0Ewr; Sun, 11 Oct 2015 10:00:14 +0200
Message-ID: <561A170B.2030408@openfortress.nl>
Date: Sun, 11 Oct 2015 10:00:11 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/64vTIr2tMnNBhWPFRtzJhWFaDgc>
Subject: [kitten] FYI: I-D: TLS CipherSuites for Kerberos + DH
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Oct 2015 08:00:20 -0000

Hello Kitten,

FYI, an I-D that I just proposed to the TLS WG.

-Rick

      ----- >8 ------ >8 ------ >8 ------ >8 -----

Hello TLS WG,

I would like to propose new CipherSuites for TLS.  The cryptography is
founded on Kerberos authentication and DH encryption, cryptographically
bound together.  The mechanism uses mutual authentication, although
clients may use anonymous tickets.

Any feedback that you may have (technical, or WG-procedural) is kindly
welcomed.  I will also send this to the Kitten WG.

Thanks,
Rick van Rein
> *From:* internet-drafts@ietf.org
> *Date:* 1 October 2015 18:54
> *To:* "Rick van Rein" <rick@openfortress.nl>, "Rick van Rein"
> <rick@openfortress.nl>
> *Subject:* New Version Notification for draft-vanrein-tls-kdh-00.txt
> A new version of I-D, draft-vanrein-tls-kdh-00.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:         draft-vanrein-tls-kdh
> Revision:     00
> Title:                TLS-KDH: Kerberos + Diffie-Hellman in TLS
> Document date:        2015-10-01
> Group:                Individual Submission
> Pages:                26
> URL:           
https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-tls-kdh-00
>
>
> Abstract:
>    This specification extends TLS with a Kerberos-based method of mutual
>    authentication, and binds in Diffie-Hellman to achieve Perfect
>    Forward Secrecy for the session.

> The IETF Secretariat
>


From nobody Mon Oct 12 10:21:04 2015
Return-Path: <ghudson@mit.edu>
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 428231A21BD for <kitten@ietfa.amsl.com>; Mon, 12 Oct 2015 10:21:04 -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 uH0ONsRw4E2I for <kitten@ietfa.amsl.com>; Mon, 12 Oct 2015 10:21: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 CD6FD1A8A45 for <kitten@ietf.org>; Mon, 12 Oct 2015 10:21:02 -0700 (PDT)
X-AuditID: 12074425-f79816d000004571-c6-561bebfdaf70
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C3.98.17777.DFBEB165; Mon, 12 Oct 2015 13:21:01 -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 t9CHL0jB002713; Mon, 12 Oct 2015 13:21:01 -0400
Received: from [18.101.8.74] (vpn-18-101-8-74.mit.edu [18.101.8.74]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9CHKw8Q025672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Oct 2015 13:21:00 -0400
To: Benjamin Kaduk <kaduk@mit.edu>, kitten@ietf.org
References: <alpine.GSO.1.10.1510041931331.26829@multics.mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <561BEBFA.9090000@mit.edu>
Date: Mon, 12 Oct 2015 13:20:58 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <alpine.GSO.1.10.1510041931331.26829@multics.mit.edu>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrfv3tXSYQcttNYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9rtTSwFT1grrjyazN7AeJeli5GTQ0LAROLV0R9sELaYxIV7 64FsLg4hgcVMEov37INyNjJKTD2wkxXCOcgksfpeIzNIi7CApcSVE61MILaIgLHE3Z83wMYK CThKbHg2C6yGTUBZYv3+rWBxXgE1iZXT+9hBbBYBVYlbJyezgtiiAhESp86+ZYOoEZQ4OfMJ WD2ngJPEu/51YPXMAnoSO67/YoWw5SW2v53DPIFRYBaSlllIymYhKVvAyLyKUTYlt0o3NzEz pzg1Wbc4OTEvL7VI10IvN7NELzWldBMjKCzZXVR3ME44pHSIUYCDUYmHl2OLVJgQa2JZcWXu IUZJDiYlUd7gl9JhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4lSYC5XhTEiurUovyYVLSHCxK 4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHgzXwE1ChalpqdWpGXmlCCkmTg4QYbzAA1vB6nh LS5IzC3OTIfIn2LU5Vjw4/ZaJiGWvPy8VClx3qkgRQIgRRmleXBzwOkklcPrFaM40FvCvPtB qniAqQhu0iugJUxAS4zYpUCWlCQipKQaGJfoRtyOPL+a4WHFA1GnbQynJBlC9wbMYWn2jG8M 1Qv6/clEUM69y+AcW5fd0f4rsi3Vn9SErp/WLOsomVgb+WeWTvD3IxauF9k3y/smz38fsv/V gkseu/P98l7suFmhPT9JIPW7lOXpmxKlouttWup/itXoT71uUMgVZeA+51TafNkYuyxlJZbi jERDLeai4kQA43cNkQIDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/pUBepFl6P2yrNHfjGrbeybSWsrk>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-cammac-03
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2015 17:21:04 -0000

On 10/04/2015 08:37 PM, Benjamin Kaduk wrote:
> This message begins the second Working Group Last Call (WGLC) of "Kerberos
> Authorization Data Container Authenticated by Multiple MACs"
> <draft-ietf-kitten-cammac-03>.  A previous version of this document was
> approved by the IESG for publication, but while the document was in the
> RFC Editor queue, an error was discovered regarding processing CAMMACs in
> cross-realm TGTs [0] that required changes to the document, so it was
> brought back to the working group for further modifications.

The new security considerations next looks good to me.  (No great
surprise since I had reviewed it prior to the draft update, but I
re-read it for the WGLC and it still looks fine.)


From nobody Tue Oct 13 11:54:47 2015
Return-Path: <michikos@microsoft.com>
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 B20F51A874F for <kitten@ietfa.amsl.com>; Tue, 13 Oct 2015 11:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 WL6BDqXagGmw for <kitten@ietfa.amsl.com>; Tue, 13 Oct 2015 11:54:43 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DEB1A7004 for <kitten@ietf.org>; Tue, 13 Oct 2015 11:49:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Izd1XWf9E09264v/V4aA340sii/BM5S8IINc26mIncA=; b=JJZC8jCCY+/nff2QAAxepu9jqq/ni1SxcPWSbgKawFSXmwgO7LsLhpTcjmZh+hKtHIQJMlaw0VzRXikC9Njr1KrpE8EGq/YlEowJ/35x7BgKUL2lIouCZH31vwGhEAN56rDMBRfqIWRxuDJyRhjJTRRgjJoVUECvDpa2AJFXwi4=
Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by BY1PR03MB1420.namprd03.prod.outlook.com (10.162.127.150) with Microsoft SMTP Server (TLS) id 15.1.293.16; Tue, 13 Oct 2015 18:49:33 +0000
Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0300.010; Tue, 13 Oct 2015 18:49:33 +0000
From: Michiko Short <michikos@microsoft.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Thread-Topic: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01
Thread-Index: AQHQ/vzI1P8SL+FtUku+IlzouHe/aJ5p0Vqg
Date: Tue, 13 Oct 2015 18:49:32 +0000
Message-ID: <BY1PR03MB1417F6EC192399445C5A2A83D0300@BY1PR03MB1417.namprd03.prod.outlook.com>
References: <alpine.GSO.1.10.1508161121510.22210@multics.mit.edu> <alpine.GSO.1.10.1510012326350.26829@multics.mit.edu>
In-Reply-To: <alpine.GSO.1.10.1510012326350.26829@multics.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michikos@microsoft.com; 
x-originating-ip: [2001:4898:80e8:4::5b4]
x-microsoft-exchange-diagnostics: 1; BY1PR03MB1420; 5:1JPTCFGaerFF+SVSU9VjfLwYxerQa7fl9S0r0UwMexOxQdEYPVjB+wupIXmTFA0CkhpzNJ3dA2dZXmZq4LAksG8TuYvHy6iQySRCX7ypd4KILLImuInXrPXMSsJ/ZyDsSQEdMVZTcUqPxeo1jSjWpA==; 24:5f5do+TPyNfBORJ35Kko1E8vedRbDFnAR6KimrzV3ZS5YUV9BIXHfyG4TR2Sd7wNKv0VTpL3vdFisUquM3jdoIxswtDspg2Ap+W0UROtLR0=; 20:o5YBkRFx9p9RetWyjQPvc2lEUZ+2WFwt2C/x7piOhT5pjmzLL2o1MQxzE3afMGjKtPSu9eyTF/M/rcqgpChQZA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1420;
x-microsoft-antispam-prvs: <BY1PR03MB142040E3450799D61A352658D0300@BY1PR03MB1420.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(61426024)(61427024); SRVR:BY1PR03MB1420; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1420; 
x-forefront-prvs: 07283408BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(57704003)(13464003)(24454002)(164054003)(77096005)(5001920100001)(10290500002)(5005710100001)(76576001)(5001960100002)(8990500004)(76176999)(64706001)(87936001)(5004730100002)(19580405001)(10400500002)(102836002)(54356999)(97736004)(99286002)(15975445007)(101416001)(106116001)(5007970100001)(11100500001)(81156007)(110136002)(189998001)(5002640100001)(19580395003)(105586002)(2900100001)(2950100001)(86362001)(122556002)(92566002)(50986999)(230783001)(86612001)(5008740100001)(551544002)(10090500001)(106356001)(33656002)(74316001)(5003600100002)(46102003)(40100003)(2171001)(290074003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1420; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2015 18:49:32.9734 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1420
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/FTNKRxZ_hPqwI8CymU5l4wR1Guc>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 18:54:45 -0000

Sorry for the delay in responding, but before I published the next draft, I=
 wanted to review all the feedback from the beginning since a couple of thi=
ngs keep coming back. Hoping we can get closure in email rather than having=
 another discussion after the next draft. I did not provide the editorial c=
hanges since I do not think they are controversial.=20

There was feedback to tightening up the intro:

Previous version
1.  Introduction
The Kerberos PKINIT extension [RFC4556] defines two schemes for using asymm=
etric cryptography in a Kerberos preauthenticator.  One uses Diffie-Hellman=
 key exchange and the other depends on public key encryption.  The public k=
ey encryption scheme is less commonly used for two reasons:
o  Elliptic Curve Cryptography (ECC) Support for PKINIT [RFC5349] only spec=
ified Elliptic Curve Diffie-Hellman (ECDH) key agreement, so it cannot be u=
sed for public key encryption.
o  Public key encryption requires certificates with an encryption key, that=
 is not deployed on many existing smart cards.

In the Diffie-Hellman exchange, the client uses its private key only to sig=
n the AuthPack structure (specified in Section 3.2.1 of [RFC4556]), that is=
 performed before any traffic is sent to the KDC. Thus a client can generat=
e requests with future times in the PKAuthenticator, and then send those re=
quests at those future times. Unless the time is outside the validity perio=
d of the client's certificate, the KDC will validate the PKAuthenticator an=
d return a TGT the client can use without possessing the private key.

As a result, a client performing PKINIT with the Diffie-Hellman key exchang=
e does not prove current possession of the private key being used for authe=
ntication.  It proves only prior use of that key. Ensuring that the client =
has current possession of the private key requires that the signed PKAuthen=
ticator data include information that the client could not have predicted.

Proposed revision
1.  Introduction
The Kerberos PKINIT extension [RFC4556] defines two schemes for using asymm=
etric cryptography in a Kerberos preauthenticator.  In the Diffie-Hellman e=
xchange, the client uses its private key only to sign the AuthPack structur=
e (specified in Section 3.2.1 of [RFC4556]), that is performed before any t=
raffic is sent to the KDC. Thus a client can generate requests with future =
times in the PKAuthenticator, and then send those requests at those future =
times. Unless the time is outside the validity period of the client's certi=
ficate, the KDC will validate the PKAuthenticator and return a TGT the clie=
nt can use without possessing the private key.

As a result, a client performing PKINIT with the Diffie-Hellman key exchang=
e does not prove current possession of the private key being used for authe=
ntication.  It proves only prior use of that key. Ensuring that the client =
has current possession of the private key requires that the signed PKAuthen=
ticator data include information that the client could not have predicted.

Client requesting freshness behavior discussions:

We have the client request freshness for multiple reasons
	1. RFC 4120 Section 1.5.2 specifies that the KDC should only use new exten=
sions if the padata element is present in the AS-REQ.
	2. KDC performance impact. The KDC cannot tell the difference between an A=
S ping for a password-based client vs certificate if the client does not ex=
plicitly ask for the token. Many (maybe most) realms are a mix of password-=
based and certificates.   =20
	3. In Windows Active Directory, accounts configured with AltSecID can rece=
ive a principal not found error and fail logon when the normal password AS =
ping is sent since the cname is not in the global catalog. By requesting th=
e freshness token, the KDC can choose to return the preauth failure with th=
e token when the account cannot be found. =20


KDC_ERR_PREAUTH_FAILED vs KDC_ERR_PREAUTH_EXPIRED=20
The first thing I can think of is that currently the draft only requires RF=
C 4120 & 4556 and FAST is just an informative reference (not to mention tha=
t the error is MAY and not in all implementations of FAST). Not sure what t=
he precedence is for pulling just the error behavior from an RFC.

We choose KDC_ERR_PREAUTH_FAILED because it was supported already and "Pre-=
authentication information was invalid" seemed accurate for the situation.=
=20



KDC validation behavior:
Every time I release a version this comes up. :) There already is a precede=
nt in IETF for not standardizing the KDC-only elements. The consensus is th=
at there are lots of ways to do this and the standard will not specify it.=
=20

How about the following to cover KDC requirements and upgrade advice:

7.  Security Considerations
A freshness token can prove recent possession of the key only if:
1.  The freshness token cannot pre-generated.
2.  The KDC can determine authenticity and prevent tampering.
       Kerberos error messages are not integrity protected unless
       authenticated using Kerberos FAST [RFC6113].  Even if FAST is
       required to provide integrity protection, a different KDC would
       not be able to validate freshness tokens without some kind of
       shared database which is unlikely as most KDCs are stateless.
       Signing, encrypting or sealing data SHOULD be used.
3.  Reuse of a freshness token is only valid within the allowable
       time window.  Freshness tokens are not required to be single use
       tokens or bound to specific AS exchanges, simply to guarantee
       that the client had the key during the allowable time window.
       Part of the reason the token is opaque is to allow KDC
       implementers the freedom to add additional functionality as long
       as the "freshness" guarantee remains.
4.  The client returns the freshness token.  Since upgrading clients
       takes time, implementers may consider allowing both unproven
       and fresh authentications.  As long as freshness tokens are not
       required then pre-generated PKAuthenticators can be used.

-----Original Message-----
From: Benjamin Kaduk [mailto:kaduk@MIT.EDU]=20
Sent: Sunday, October 4, 2015 4:31 PM
To: Michiko Short <michikos@microsoft.com>
Cc: kitten@ietf.org
Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01

Hi Michiko,

On Sun, 16 Aug 2015, Benjamin Kaduk wrote:

> This message begins the Working Group Last Call (WGLC) of "Public Key=20
> Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness=20
> Extension" <draft-ietf-kitten-pkinit-freshness-01>. The WGLC will last=20
> two weeks, ending on Sunday, August 30th.  The draft is available at:

Looking over the traffic from the WGLC period, it seems that some revisions=
 to the document are required.  Going over the list's archive:

Greg noted that there was some ambiguity in section 2.4 regarding the conte=
nts of the KRB-ERROR message in the case when a supplied freshness token is=
 not valid, in his message at http://www.ietf.org/mail-archive/web/kitten/c=
urrent/msg05783.html .

That message also raised the question of using KDC_ERR_PREAUTH_FAILED for a=
 retriable answer, which does not seem to have been resolved yet.  With no =
hat on, I'm inclined to avoid KDC_ERR_PREAUTH_FAILED for retriable errors.

Greg also made some editorial comments in that same message.

Bryce Nordgren also found an editorial change in http://www.ietf.org/mail-a=
rchive/web/kitten/current/msg05794.html (the content question in that messa=
ge seems to have been resolved in subsequent list traffic).

Bryce also notes in a later message that the document should say that the i=
mplementation-defined validation procedure must actually guarantee freshnes=
s.  Something similar to Greg's explanation in http://www.ietf.org/mail-arc=
hive/web/kitten/current/msg05795.html might be reasonable, say, in the secu=
rity considerations.

I also supplied a couple editorial comments in http://www.ietf.org/mail-arc=
hive/web/kitten/current/msg05801.html

jhutz made some (mostly) editorial suggestions in his review, http://www.ie=
tf.org/mail-archive/web/kitten/current/msg05802.html (some of the non-edito=
rial comments are mitigated by Greg's follow-up in http://www.ietf.org/mail=
-archive/web/kitten/current/msg05803.html )

This question from jhutz's message remains unresolved:
"Do we need to call out that a client MUST use a freshness token it got dur=
ing an earlier iteration of the same AS exchange?  So, for example, it can'=
t change its mind about principal names or KDC options or requested AD and =
still expect the freshness token to be valid?"  I don't think this is a par=
ticularly critical issue, so it may suffice to just note that a KDC impleme=
ntation MAY bind the freshness token to parameters in the AS-REQ, so the cl=
ient implementation should use the freshness token it got during an earlier=
 iteration of the same AS exchange or be prepared to handle failures result=
ing from the KDC validation failure for the binding to the AS-REQ parameter=
(s).


Can you please generate a revised I-D addressing these comments (i.e., incl=
uding proposed resolutions to the as-yet-unresolved questions)?
Depending on the scope of the changes, another WGLC may be needed; if the c=
hanges are minor and uncontroversial, we might be able to skip it.

Thanks,

Ben


From nobody Tue Oct 13 13:56:41 2015
Return-Path: <ghudson@mit.edu>
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 0DEBC1A8BB6 for <kitten@ietfa.amsl.com>; Tue, 13 Oct 2015 13:56:40 -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 cvcSRWAtRJSm for <kitten@ietfa.amsl.com>; Tue, 13 Oct 2015 13:56:37 -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 A89171A8BB4 for <kitten@ietf.org>; Tue, 13 Oct 2015 13:56:36 -0700 (PDT)
X-AuditID: 1209190c-f79b76d000007c4e-24-561d700266cb
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A5.B3.31822.2007D165; Tue, 13 Oct 2015 16:56:34 -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 t9DKuYr7018469 for <kitten@ietf.org>; Tue, 13 Oct 2015 16:56:34 -0400
Received: from [18.101.8.171] (vpn-18-101-8-171.mit.edu [18.101.8.171]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9DKuWNn012861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <kitten@ietf.org>; Tue, 13 Oct 2015 16:56:33 -0400
To: kitten@ietf.org
References: <alpine.GSO.1.10.1508161121510.22210@multics.mit.edu> <alpine.GSO.1.10.1510012326350.26829@multics.mit.edu> <BY1PR03MB1417F6EC192399445C5A2A83D0300@BY1PR03MB1417.namprd03.prod.outlook.com>
From: Greg Hudson <ghudson@mit.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <561D7000.9080605@mit.edu>
Date: Tue, 13 Oct 2015 16:56:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <BY1PR03MB1417F6EC192399445C5A2A83D0300@BY1PR03MB1417.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrstUIBtm0PpGz+Lo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKePN6BlPBLsmKholdLA2M10W6GDk5JARMJK5P7WKCsMUkLtxb z9bFyMUhJLCYSeLnx0esIAkhgeOMEmfmaUHYt5gkdl9RBbGFBZwlbs88ww5iiwgIS+ze+o4Z ovkMo8TGd0vBprIJKEus37+VBWKDnERv9yQwm1dATeLIxl9ADRwcLAKqEl3z5UHCogIREqfO vmWDKBGUODnzCVg5p0CsxK4/z8FGMgvoSey4/osVwpaXaN46m3kCo+AsJC2zkJTNQlK2gJF5 FaNsSm6Vbm5iZk5xarJucXJiXl5qka6hXm5miV5qSukmRlCockry7GB8c1DpEKMAB6MSD++L SJkwIdbEsuLK3EOMkhxMSqK8nxNlw4T4kvJTKjMSizPii0pzUosPMUpwMCuJ8BqlAuV4UxIr q1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4D+UBNQoWpaanVqRl5pQgpJk4 OEGG8wANjwKp4S0uSMwtzkyHyJ9iVJQS540ESQiAJDJK8+B6wakklWP1K0ZxoFeEeTVAqniA aQiu+xXQYCaQq9mlQAaXJCKkpBoY7ZirItKkLi9zr6k73Dtl6u/bnGdPNjF6rz/anvEvS3ra t6nbe1vLopx+v2I1ObFXfNumHQq/i0W27rudMb/r1lHOP4k8PuYM2//sUdMqMOi622n4cHah 8sRUv0l94UqRD2xLJsfxfN02/YDs2r18NZLHnsyotNYXN/4yWf3Ksfd+X72b93U9UGIpzkg0 1GIuKk4EAATJ9BwAAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ZYgiYsdmbDw6IZ3ChYENk5dqC6Y>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 20:56:40 -0000

On 10/13/2015 02:49 PM, Michiko Short wrote:
> 	1. RFC 4120 Section 1.5.2 specifies that the KDC should only use new extensions if the padata element is present in the AS-REQ.

I'm not asking to get rid of the request, but I want to reiterate that I
don't think this is a correct reading of RFC 4120 section 1.5.2.  We
know exactly what an old client will do with a PA-AS-FRESHNESS value in
METHOD-DATA: ignore it.  We have relied on this client behavior numerous
times in the past, such as when we added PA-ETYPE-INFO and PA-ETYPE-INFO2.

> 	2. KDC performance impact. The KDC cannot tell the difference between an AS ping for a password-based client vs certificate if the client does not explicitly ask for the token. Many (maybe most) realms are a mix of password-based and certificates.    

There are other ways to address any performance impact such as reusing
freshness tokens, but I understand the desire for simplicity.

> 	3. In Windows Active Directory, accounts configured with AltSecID can receive a principal not found error and fail logon when the normal password AS ping is sent since the cname is not in the global catalog. By requesting the freshness token, the KDC can choose to return the preauth failure with the token when the account cannot be found.  

I don't understand this.  What is the message sequence?  Do you want to
return a freshness token in a KDC_ERR_C_PRINCIPAL_UNKNOWN error?

> KDC_ERR_PREAUTH_FAILED vs KDC_ERR_PREAUTH_EXPIRED 
> The first thing I can think of is that currently the draft only requires RFC 4120 & 4556 and FAST is just an informative reference (not to mention that the error is MAY and not in all implementations of FAST). Not sure what the precedence is for pulling just the error behavior from an RFC.

I don't think there is any problem with making RFC 6113 a normative
reference just to use the error code.  We would not be requiring KDCs or
clients to implement FAST; RFC 6113 describes a general framework for
pre-authentication, with FAST as one component.

> We choose KDC_ERR_PREAUTH_FAILED because it was supported already and "Pre-authentication information was invalid" seemed accurate for the situation. 

In MIT krb5, would be rather difficult for us to perform a retry of the
same preauth mechanism after KDC_ERR_PREAUTH_FAILED without creating
unfortunate edge cases.  (For example, we definitely don't want to retry
encrypted timestamp after KDC_ERR_PREAUTH_FAILED, because of password
lockout.)  Most likely we would wind up ignoring that part of the spec
and fail out when a freshness token expired due to prompting delay.

In contrast, we already (in 1.14) perform a retry from scratch on
KDC_ERR_PREAUTH_EXPIRED, so we would not need to make any changes to the
core preauth code.

> 7.  Security Considerations

This looks mostly okay aside from editorial concerns, except:

> 2.  The KDC can determine authenticity and prevent tampering.

Discussing FAST here seems confusing than helpful.  FAST protects
against some kinds of tampering by a network attacker, but wouldn't even
begin to protect against a rogue client tampering with the contents of
the freshness token (e.g. changing a timestamp to make an old token look
new).


From nobody Wed Oct 14 17:33:01 2015
Return-Path: <kaduk@mit.edu>
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 1E6921B2DD7 for <kitten@ietfa.amsl.com>; Wed, 14 Oct 2015 17:33: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 RHZJy1teN_4p for <kitten@ietfa.amsl.com>; Wed, 14 Oct 2015 17:32:58 -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 B69A81B2D9C for <kitten@ietf.org>; Wed, 14 Oct 2015 17:32:56 -0700 (PDT)
X-AuditID: 12074424-f79106d000007367-cd-561ef4361b96
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 22.A2.29543.734FE165; Wed, 14 Oct 2015 20:32:55 -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 t9F0Wsnc027054 for <kitten@ietf.org>; Wed, 14 Oct 2015 20:32:54 -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 t9F0Wp6R019192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <kitten@ietf.org>; Wed, 14 Oct 2015 20:32:54 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9F0WpRh006117; Wed, 14 Oct 2015 20:32:51 -0400 (EDT)
Date: Wed, 14 Oct 2015 20:32:51 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
In-Reply-To: <alpine.GSO.1.10.1510041931331.26829@multics.mit.edu>
Message-ID: <alpine.GSO.1.10.1510142032030.26829@multics.mit.edu>
References: <alpine.GSO.1.10.1510041931331.26829@multics.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+NgFrrKIsWRmVeSWpSXmKPExsUixCmqrWv+RS7MYPMXVoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/61rILHAhW3byU1ML7k7WLk5JAQMJFou3+NHcIWk7hwbz1b FyMXh5DAYiaJiUfnskA4xxklPnb2sEI4N5gkPi44wAzSIiTQwCjxYL8PiM0ioC2x/thaJhCb TUBFYuabjWwgtoiAsMTure/A6oUFLCWunGgFq+EUcJJ4178ObDWvgKPEgmPPGSFmOkpseDYL rF5UQEdi9f4pLBA1ghInZz4Bs5kFtCSWT9/GMoFRYBaS1CwkqQWMTKsYZVNyq3RzEzNzilOT dYuTE/PyUot0zfVyM0v0UlNKNzGCQo/dRWUHY/MhpUOMAhyMSjy8Jx7IhQmxJpYVV+YeYpTk YFIS5c15BxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwqu9ASjHm5JYWZValA+TkuZgURLn3fSD L0RIID2xJDU7NbUgtQgmK8PBoSTB2/oJqFGwKDU9tSItM6cEIc3EwQkynAdouDFIDW9xQWJu cWY6RP4Uo6KUOK/ZZ6CEAEgiozQPrhecGnYzqb5iFAd6RZj3EUg7DzCtwHW/AhrMBDR4z39Z kMEliQgpqQbGtfLPJs0o3pa/x/mzk8rEt9siJtgZfnL9/YK9wn3Z8oYfzx79W7xM3tXw4h4O 9pmq50q00vsivV6/+LJ1wi77ayaq20zPJRqZFxf35hYn3Nn5q2+W0/P3Mr42r4zcFTe+iNvl fGzin283RJe0igcZrLFXrd879/OEs54JjnfCW9XWvVJc8+JhqBJLcUaioRZzUXEiADHes5Lo AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/WK5WFzgUDg-VaSf4zHoITGtwiBw>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-cammac-03
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 00:33:01 -0000

Just four days remain in this WGLC.
We've already gotten some comments from Greg, but more review would be
most welcome.

-Ben



On Sun, 4 Oct 2015, Benjamin Kaduk wrote:

> This message begins the second Working Group Last Call (WGLC) of "Kerberos
> Authorization Data Container Authenticated by Multiple MACs"
> <draft-ietf-kitten-cammac-03>.  A previous version of this document was
> approved by the IESG for publication, but while the document was in the
> RFC Editor queue, an error was discovered regarding processing CAMMACs in
> cross-realm TGTs [0] that required changes to the document, so it was
> brought back to the working group for further modifications.
>
> Although the changes since the previously approved version are only in the
> Security Considerations section, the entire document is open for review
> during this WGLC.  The WGLC will last two weeks, ending on Sunday, October
> 18th.  The draft is available at:
>
> https://tools.ietf.org/html/draft-ietf-kitten-cammac-03
>
> A diff of the changes since the previously approved version is available
> at:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-03.txt&url1=draft-ietf-kitten-cammac-01.txt
>
> Please review the document and send comments to the Working Group mailing
> list kitten@ietf.org or the co-chairs kitten-chairs@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.  This is particularly important if you found issues with the
> previous version.
>
> 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
>
> [0] http://www.ietf.org/mail-archive/web/kitten/current/msg05336.html
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>


From nobody Thu Oct 15 12:59:54 2015
Return-Path: <hbhotz@oxy.edu>
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 D8BC61A1A5F for <kitten@ietfa.amsl.com>; Thu, 15 Oct 2015 12:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywFMnB_Vm36p for <kitten@ietfa.amsl.com>; Thu, 15 Oct 2015 12:59:52 -0700 (PDT)
Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29811A1A5D for <kitten@ietf.org>; Thu, 15 Oct 2015 12:59:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 53AA3E335 for <kitten@ietf.org>; Thu, 15 Oct 2015 15:59:49 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca
Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj0tljSaDzMP for <kitten@ietf.org>; Thu, 15 Oct 2015 15:59:49 -0400 (EDT)
Received: from [192.168.1.180] (wsip-70-184-69-253.oc.oc.cox.net [70.184.69.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id E761AE087 for <kitten@ietf.org>; Thu, 15 Oct 2015 15:59:48 -0400 (EDT)
From: "Henry B (Hank) Hotz, CISSP" <hbhotz@oxy.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <63860D22-138C-430F-B615-06CBB14654CC@oxy.edu>
Date: Thu, 15 Oct 2015 12:59:46 -0700
To: kitten@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/l7p-7cnrkfiwmf4u37R6Qo1td2o>
Subject: [kitten] Non-Password Password Change
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 19:59:54 -0000

There=E2=80=99s been work on improved password change protocols, but =
I=E2=80=99m not sure how much actually completed. I also remember once =
suggesting that loading a KDB entry from a keytab file would be useful, =
at least for handling cross-realm principals.

Are there any password change protocols where you can supply the enctype =
and a key instead of a text password? Or is the only way to do that via =
the kdc=E2=80=99s kadmin interface.


Personal:  hbhotz@oxy.edu
Business: hhotz@securechannels.com


From nobody Thu Oct 15 14:51:58 2015
Return-Path: <ghudson@mit.edu>
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 DEA8F1A6FC0 for <kitten@ietfa.amsl.com>; Thu, 15 Oct 2015 14:51: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 eC0npsqsQwEG for <kitten@ietfa.amsl.com>; Thu, 15 Oct 2015 14:51:55 -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 4D6D11A6FAD for <kitten@ietf.org>; Thu, 15 Oct 2015 14:51:55 -0700 (PDT)
X-AuditID: 12074424-f79106d000007367-1a-56201ff9e2b0
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 6C.E7.29543.AFF10265; Thu, 15 Oct 2015 17:51:54 -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 t9FLpr6u032763; Thu, 15 Oct 2015 17:51:53 -0400
Received: from [18.101.8.93] (vpn-18-101-8-93.mit.edu [18.101.8.93]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9FLpobK004240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Oct 2015 17:51:52 -0400
To: "Henry B (Hank) Hotz, CISSP" <hbhotz@oxy.edu>, kitten@ietf.org
References: <63860D22-138C-430F-B615-06CBB14654CC@oxy.edu>
From: Greg Hudson <ghudson@mit.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <56201FF6.4070902@mit.edu>
Date: Thu, 15 Oct 2015 17:51:50 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <63860D22-138C-430F-B615-06CBB14654CC@oxy.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6novtLXiHMYP4adouP9xayWBzdvIrF gcljyZKfTB5bm/4yBzBFcdmkpOZklqUW6dslcGVsP3CbqeAyZ0VvewNrA+N79i5GTg4JAROJ k53PWCFsMYkL99azdTFycQgJLGaSWHa6hwnC2cgoMfXdWkYI5yCTxLwjV9hAWoQFjCTuTH4N ZHNwiAg4SZydVQsSFhKwkvi7aBXYVDYBZYn1+7eyQGyQk+jtngRm8wqoSfw5Mw2shkVAVWLu pS6wuKhAhMSps2/ZIGoEJU7OfAIW5xSwlrgzaTFYPbOAusSfeZeYIWx5ieats5knMArOQtIy C0nZLCRlCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuma6+VmluilppRuYgQHsIvKDsbmQ0qH GAU4GJV4eDuAgS3EmlhWXJl7iFGSg0lJlPesEFCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO8d NqAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IE72M5oEbBotT01Iq0 zJwShDQTByfIcB6g4c9AaniLCxJzizPTIfKnGBWlxHmPgyQEQBIZpXlwveAEk8oR+4pRHOgV YV5ekFd4gMkJrvsV0GAmoMF7/suCDC5JREhJNTBaql8ySDWb+CTu+q/G3TFeJUvfach4X3jw 5LXoeYkNK3Zt277l1fPyLJH4hXsXGd+ZdnB3Fgvz0V3zJm0xZi7/4SdnN3kZo+Hdlo+n3rP0 5Ab2cd2bZrpt5zQRAYmeX89v5G5nOS0neuEYW4MA5/cSnSMNM289kf4Yk/iw9pjDKZc9b4NK +trvKLEUZyQaajEXFScCAIEIToILAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/4uKeu1LVkIhqlmk-qz8LxL-yCZ8>
Subject: Re: [kitten] Non-Password Password Change
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 21:51:57 -0000

On 10/15/2015 03:59 PM, Henry B (Hank) Hotz, CISSP wrote:
> There’s been work on improved password change protocols, but I’m not sure how much actually completed. I also remember once suggesting that loading a KDB entry from a keytab file would be useful, at least for handling cross-realm principals.

I believe the most recent work is:

    https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08

I vaguely recall an explicit decision not to continue with that work
because no one believed they were likely to implement it.

> Are there any password change protocols where you can supply the enctype and a key instead of a text password?

This is probably obvious, but any such facility allows the client to
circumvent password policies, and therefore usually require special
permissions.

I believe you are correct that in current implementations, the only way
to do that is via implementation-specific admin interfaces.

Another mode I would find interesting is one where the server makes up a
new password and tells you what it is.  I don't know if it would get
much use (I've never seen passwords managed that way in any
environment), but it seems like a reasonable way to mitigate risk.


From nobody Thu Oct 15 16:19:41 2015
Return-Path: <hbhotz@oxy.edu>
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 E5D5A1A036F for <kitten@ietfa.amsl.com>; Thu, 15 Oct 2015 16:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vyz0sYhlvpg for <kitten@ietfa.amsl.com>; Thu, 15 Oct 2015 16:19:39 -0700 (PDT)
Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487A51A036E for <kitten@ietf.org>; Thu, 15 Oct 2015 16:19:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 118D0E42F; Thu, 15 Oct 2015 19:19:36 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca
Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHKvsXxQGKx3; Thu, 15 Oct 2015 19:19:35 -0400 (EDT)
Received: from [192.168.1.180] (wsip-70-184-69-253.oc.oc.cox.net [70.184.69.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 473A5E41D; Thu, 15 Oct 2015 19:19:35 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Henry B (Hank) Hotz, CISSP" <hbhotz@oxy.edu>
In-Reply-To: <56201FF6.4070902@mit.edu>
Date: Thu, 15 Oct 2015 16:19:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4A08531-53D5-4FF8-AFA0-8A1928CDF9B7@oxy.edu>
References: <63860D22-138C-430F-B615-06CBB14654CC@oxy.edu> <56201FF6.4070902@mit.edu>
To: Greg Hudson <ghudson@MIT.EDU>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/fSufTVLa-Udpf0yZi2zNLrNAw94>
Cc: kitten@ietf.org
Subject: Re: [kitten] Non-Password Password Change
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 23:19:41 -0000

> On Oct 15, 2015, at 2:51 PM, Greg Hudson <ghudson@MIT.EDU> wrote:
>=20
> On 10/15/2015 03:59 PM, Henry B (Hank) Hotz, CISSP wrote:
>> There=E2=80=99s been work on improved password change protocols, but =
I=E2=80=99m not sure how much actually completed. I also remember once =
suggesting that loading a KDB entry from a keytab file would be useful, =
at least for handling cross-realm principals.
>=20
> I believe the most recent work is:
>=20
>    =
https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08
>=20
> I vaguely recall an explicit decision not to continue with that work
> because no one believed they were likely to implement it.

I see a set_keys() operation in there. I don=E2=80=99t think I=E2=80=99m =
likely to implement it though.

>> Are there any password change protocols where you can supply the =
enctype and a key instead of a text password?
>=20
> This is probably obvious, but any such facility allows the client to
> circumvent password policies, and therefore usually require special
> permissions.

Given PKINIT and FAST/OTP, all you need is a policy which says =
NO-PASSWORDS. ;-)

> I believe you are correct that in current implementations, the only =
way
> to do that is via implementation-specific admin interfaces.
>=20
> Another mode I would find interesting is one where the server makes up =
a
> new password and tells you what it is.  I don't know if it would get
> much use (I've never seen passwords managed that way in any
> environment), but it seems like a reasonable way to mitigate risk.

I once built a service which chose users=E2=80=99 passwords and emailed =
them to them. I didn=E2=80=99t have to implement any set/change password =
functionality and the reset function was dead simple.

The above draft supports it. What would be nice is if you could update =
application servers' keytabs *before* the kdc started issuing tickets =
with the new keys.


Personal:  hbhotz@oxy.edu
Business: hhotz@securechannels.com


From nobody Fri Oct 16 11:04:29 2015
Return-Path: <michikos@microsoft.com>
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 CF4181B32D3 for <kitten@ietfa.amsl.com>; Fri, 16 Oct 2015 11:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 xzuF0Gabrya0 for <kitten@ietfa.amsl.com>; Fri, 16 Oct 2015 11:04:25 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B7E1B32C8 for <kitten@ietf.org>; Fri, 16 Oct 2015 11:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2FAW2ShPzkwAwia+dVvHuF6B2Q+u7D15rud9VN3AG30=; b=Ogfa0Su0SoEp4+i/dzvcCoLcGyGqFd+mv5GgRtm7/AU4qxJ2QIfhQwP1MCZP1eNfe19idHJDTK7jc8f3NybGyZLz7aRFZrUP9vWUMXoHoeF1PWFHB4sIn1LItgMa46Ae/x16esG3QECvhfkxfiBO6eP+j70eK0R6qvDRj2ucEsE=
Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by BY1PR03MB1420.namprd03.prod.outlook.com (10.162.127.150) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 18:04:19 +0000
Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0300.010; Fri, 16 Oct 2015 18:04:19 +0000
From: Michiko Short <michikos@microsoft.com>
To: "kitten@ietf.org" <kitten@ietf.org>
Thread-Topic: Re:  WGLC on draft-ietf-kitten-pkinit-freshness-01 
Thread-Index: AdEHbQ4IHm1emDE7QC2p75sYpFU2AQ==
Date: Fri, 16 Oct 2015 18:04:18 +0000
Message-ID: <BY1PR03MB14177E50FC4283137136D705D03D0@BY1PR03MB1417.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michikos@microsoft.com; 
x-originating-ip: [2001:4898:80e8:7::372]
x-microsoft-exchange-diagnostics: 1; BY1PR03MB1420; 5:ErGfTlBK7DAwqYZevMnuktoWXPYAbG2wqogVlhSNqymkvqGHe8SRozJHJPq0a4wYKBPxK7akTaHta+xe4hAxr78QaCDK19NFEk7IJ7lWtJRU1JX0Dp1XV0/5q7wYtRaowESOMNTCkShbfwfTVUPmsQ==; 24:2HOjc2oZwBVI6bmC8/Al9U7HbbDmpfn3dHfYtv8BDS87x29PFvl903cUtMlHAe1VcAlJ0EFVoj0jvI6fLcV4azTMsvXyunoWHtCSBVDJpJM=; 20:6npVoC9TAD6Ep70p/cIEVUmZ5E7kA4rxnvmaJn9McOs6QYhvTBNJdvNfIiQSf0OaX506fEVUuKwqxRjJr8AejA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1420;
x-microsoft-antispam-prvs: <BY1PR03MB142000A45EC461D364BDC764D03D0@BY1PR03MB1420.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(42673675456677)(108003899814671)(83020558694031); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(61426024)(61427024); SRVR:BY1PR03MB1420; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1420; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(51914003)(64706001)(230783001)(5002640100001)(10090500001)(110136002)(81156007)(2501003)(5004730100002)(87936001)(76576001)(10290500002)(40100003)(10400500002)(5003600100002)(74316001)(122556002)(5007970100001)(92566002)(5005710100001)(11100500001)(86612001)(107886002)(8990500004)(450100001)(189998001)(97736004)(5001960100002)(99286002)(5008740100001)(86362001)(46102003)(106356001)(19300405004)(2351001)(105586002)(5001920100001)(33656002)(77096005)(2900100001)(102836002)(551544002)(15975445007)(16236675004)(19625215002)(19580395003)(50986999)(54356999)(101416001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1420; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY1PR03MB14177E50FC4283137136D705D03D0BY1PR03MB1417namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 18:04:18.9327 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1420
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/U5bZdDscdTpWutKul8O5iXfZCJY>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 18:04:28 -0000

--_000_BY1PR03MB14177E50FC4283137136D705D03D0BY1PR03MB1417namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greg, as always, thanks for the fast response.

In regards to the client request behavior, the bottom line is that I would =
prefer not to remove it from the RFC. We can make is optional, but it would=
 need to be required to interoperate with some Microsoft Active Directory d=
omains. We may be the only PKINIT implementation impacted. I don't know.


>>           3. In Windows Active Directory, accounts configured with AltSe=
cID can receive a principal not found error and fail logon when the normal =
password AS ping is sent since the cname is not in the global catalog. By r=
equesting the freshness token, the KDC can choose to return the preauth fai=
lure with the token when the account cannot be found.



> I don't understand this.  What is the message sequence?  Do you want to r=
eturn a freshness token in a KDC_ERR_C_PRINCIPAL_UNKNOWN error?



No, the message sequence is that the client requests freshness, so the KDC =
can ignore the principal not found issue and return the freshness token wit=
h preauthn required. Then when they have preauth, the KDC can find the acco=
unt and proceed as normal.





In regards to the error, I'll update the draft to use KDC_ERR_PREAUTH_EXPIR=
ED and make FAST a normative reference. If anyone disagrees, then speak up.



>> 7.  Security Considerations



>> 2.  The KDC can determine authenticity and prevent tampering.



> Discussing FAST here seems confusing than helpful.  FAST protects against=
 some kinds of tampering by a network attacker, but wouldn't even begin to =
protect against a rogue client tampering with the contents of the freshness=
 token (e.g. changing a timestamp to make an old token look new).

I have removed the FAST statement and gotten bit of feedback on our side so=
 I'll shoot another proposed draft later today.


Thanks,
Michiko Short
Program Manager | Authentication Protocols
Windows & Devices Group: OS Security


--_000_BY1PR03MB14177E50FC4283137136D705D03D0BY1PR03MB1417namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri",sans-serif;}
span.EmailStyle20
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Greg, as always, thanks for the fast response. <o:p>=
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">In regards to the client request behavior, the botto=
m line is that I would prefer not to remove it from the RFC. We can make is=
 optional, but it would need to be required to interoperate with some Micro=
soft Active Directory domains. We
 may be the only PKINIT implementation impacted. I don&#8217;t know. <o:p><=
/o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 3. In Windows Active Directory, accounts configured with Alt=
SecID can receive a principal not found error and fail logon when the norma=
l password AS ping is sent since the cname is not in the global catalog. By=
 requesting
 the freshness token, the KDC can choose to return the preauth failure with=
 the token when the account cannot be found.&nbsp;
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&gt; I don't understand this.&nbsp; What is the m=
essage sequence?&nbsp; Do you want to return a freshness token in a KDC_ERR=
_C_PRINCIPAL_UNKNOWN error?<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">No, the message sequence is that the client reque=
sts freshness, so the KDC can ignore the principal not found issue and retu=
rn the freshness token with preauthn required. Then when they have preauth,=
 the KDC can find the account and
 proceed as normal. <o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">In regards to the error, I&#8217;ll update the dr=
aft to use KDC_ERR_PREAUTH_EXPIRED and make FAST a normative reference. If =
anyone disagrees, then speak up.
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&gt;&gt; 7.&nbsp; Security Considerations<o:p></o=
:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&gt;&gt; 2.&nbsp; The KDC can determine authentic=
ity and prevent tampering.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&gt; Discussing FAST here seems confusing than he=
lpful.&nbsp; FAST protects against some kinds of tampering by a network att=
acker, but wouldn't even begin to protect against a rogue client tampering =
with the contents of the freshness token (e.g.
 changing a timestamp to make an old token look new).<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I have removed the FAST statement and gotten bit of =
feedback on our side so I&#8217;ll shoot another proposed draft later today=
.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal"><b>Michiko S<span style=3D"color:gray">hort<o:p></o:=
p></span></b></p>
<p class=3D"MsoNormal">Program Manager | Authentication Protocols<o:p></o:p=
></p>
<p class=3D"MsoNormal">Windows &amp; Devices Group: OS Security<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_BY1PR03MB14177E50FC4283137136D705D03D0BY1PR03MB1417namp_--


From nobody Mon Oct 19 14:48:08 2015
Return-Path: <D.Rogers@gmx.net>
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 1FD5E1B2D00 for <kitten@ietfa.amsl.com>; Mon, 19 Oct 2015 14:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Level: 
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, 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 sX-3TGL_-biv for <kitten@ietfa.amsl.com>; Mon, 19 Oct 2015 14:48:06 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 4B1221AD0B7 for <kitten@ietf.org>; Mon, 19 Oct 2015 14:48:06 -0700 (PDT)
Received: from [217.244.146.93] by 3capp-gmx-bs18.server.lan (via HTTP); Mon, 19 Oct 2015 23:48:04 +0200
MIME-Version: 1.0
Message-ID: <trinity-2f423d5f-4c7e-4e1d-94f0-1e866352725d-1445291284061@3capp-gmx-bs18>
From: D.Rogers@gmx.net
To: "Greg Hudson" <ghudson@mit.edu>
Content-Type: text/html; charset=UTF-8
Date: Mon, 19 Oct 2015 23:48:04 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <56201FF6.4070902@mit.edu>
References: <63860D22-138C-430F-B615-06CBB14654CC@oxy.edu>, <56201FF6.4070902@mit.edu>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K0:alZrvHIxVIZS7bjG2zttnihrrO7dSb9xFSTA/5z3TI+ qmpnn+t86CsUsiFhesVS7qFZ4a/SQx7+4TkBStGdtMfE0Xzjiu agA84ohpOMCuN0SJy2HHjPIuuOnJUiguU05eePxZXLmGyfPk/M aoQaOasAC3dSH0gS1jTg0AvV0G03ymaEk6UM3cfIlBi5UlXkFk ooI36ljl2WP/y68f8DXqwTNAzjr4/DEGCM9iUtaFuEQOSjdqCA aZWTIglho8rWk5iX6zPqNeeCXakvK7xACdGKGrAoE/tki+3Z+K BSjHYY=
X-UI-Out-Filterresults: notjunk:1;V01:K0:fYVWpoohBZE=:EH0GQdiC6Q1TIle8+9sxhS J8RcewjKXntQW8JQslvd4blPCkJQ3KLPmy4mTCRLHx+bRpSRKd/8YPcv6indeZrs7rs0oG3/N RuKAVfb9SaK7iibIX52x7KMdMlDatTOXPDfnzafNGAp79EtZzz4XOJVZiJDD5t8ydKWbP/INL /jL27tvjwYwvvZvijOSHkEeGeh0kedfkIdG9Bm2dtbtqLccztQUFPseZigea6xCUitQvVhPkS 53ld9GN/BurK0WTIvT3dKD/HjMaTSE2Y6eOPfSvrTkcR5MGDEDkdtFLwCTElj7qdBAQwjsSrq 7mkjrY4I2Y2B1j7XgNYF4/mCms2IF3Z4kmsNHH2ndmD14+sP5jYA6qeN8sJ1VRKzQPjGBesn1 PiE7anjKvfdMFwnkshPNDv7V655DXjpiULlKdLTx7ctGM9twp4LKIbttbsAOxWqXdlRWpV+cw sJxMuAaHJA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ADyOvnZfM6dJoqFbE9cXPooSPvw>
Cc: kitten@ietf.org
Subject: Re: [kitten] Non-Password Password Change
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 21:48:08 -0000

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Isnt the Server generating a random password effectively&nbsp;similar to many hardware Tokens, or more recently Smart Apps, generating one.</div>

<div>The password change protocol would then have to consider changes to the semi-static (user pwd) concatenating it with the spontaneously generated one.</div>

<div>Observation shows these implementations exist, though they may be proprietary.</div>

<div>&nbsp;</div>

<div>Dean</div>

<div>
<div name="quote" style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left-color: rgb(195, 217, 229); border-left-width: 2px; border-left-style: solid; -ms-word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin: 0px 0px 10px;"><b>Gesendet:</b>&nbsp;Donnerstag, 15. Oktober 2015 um 23:51 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Greg Hudson&quot; &lt;ghudson@mit.edu&gt;<br/>
<b>An:</b>&nbsp;&quot;Henry B (Hank) Hotz, CISSP&quot; &lt;hbhotz@oxy.edu&gt;, kitten@ietf.org<br/>
<b>Betreff:</b>&nbsp;Re: [kitten] Non-Password Password Change</div>

<div name="quoted-content">On 10/15/2015 03:59 PM, Henry B (Hank) Hotz, CISSP wrote:<br/>
&gt; There&rsquo;s been work on improved password change protocols, but I&rsquo;m not sure how much actually completed. I also remember once suggesting that loading a KDB entry from a keytab file would be useful, at least for handling cross-realm principals.<br/>
<br/>
I believe the most recent work is:<br/>
<br/>
<a href="https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08" target="_blank">https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08</a><br/>
<br/>
I vaguely recall an explicit decision not to continue with that work<br/>
because no one believed they were likely to implement it.<br/>
<br/>
&gt; Are there any password change protocols where you can supply the enctype and a key instead of a text password?<br/>
<br/>
This is probably obvious, but any such facility allows the client to<br/>
circumvent password policies, and therefore usually require special<br/>
permissions.<br/>
<br/>
I believe you are correct that in current implementations, the only way<br/>
to do that is via implementation-specific admin interfaces.<br/>
<br/>
Another mode I would find interesting is one where the server makes up a<br/>
new password and tells you what it is. I don&#39;t know if it would get<br/>
much use (I&#39;ve never seen passwords managed that way in any<br/>
environment), but it seems like a reasonable way to mitigate risk.<br/>
<br/>
_______________________________________________<br/>
Kitten mailing list<br/>
Kitten@ietf.org<br/>
<a href="https://www.ietf.org/mailman/listinfo/kitten" target="_blank">https://www.ietf.org/mailman/listinfo/kitten</a></div>
</div>
</div>
</div></div></body></html>