From nobody Thu Jul 6 09:02:02 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D206131630; Thu, 6 Jul 2017 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GLuypDPaTwGA; Thu, 6 Jul 2017 09:01:53 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0DB12EBFE; Thu, 6 Jul 2017 09:01:52 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id h22so6699089lfk.3; Thu, 06 Jul 2017 09:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uwpUJYZNlL9l/SHA8riXNBcIUHUtst5Sm1coraIHTgA=; b=EdqDeqT25FbhyM8KyTDDO8kVbfUIdR92hq4rMHtTWsiuoC9utHryGqQ6lVLzgqzx+0 j+XEC8672QPFnXt3yc/BSzaD/+lB5dHrrsIUjR3Btu6JEHtb13dZyOHSY3bvuGnsxCnH Qdnxcb1KyDIkHMl+hFSNsQfnts2CC0J0msOpj/b0Md3wIR+cL3ac/wgBVfRrgLJAgzNg s6FnCW3pi3yv/Iv9DxP8/15rK43fsRt4GyJd6qHNL76F92VuO+pZCRudb2wArWihEzRt T0LjAvUE/lWX6nyYC1DdwJ+Juk9ycse3/uIE/YQALyuvza69/yOIsF0vKq7Hr+tta8F/ 24/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uwpUJYZNlL9l/SHA8riXNBcIUHUtst5Sm1coraIHTgA=; b=NhdJfnWlJ/F8VZMi1TtAMMcEPywgswLpzyLLHQBF+uVWIobQTlG8F/euIF2MLL53wJ 6s+0VUQH/Gw7zV2neLnpc/mVbumj0Yad+DZO1oC+twCO/NGQ9NA//rHS2fepjTM1ZJjC 7gihXEZpAIAa+aP1vtvOFiz81mxijtWuuxv4z9WrALniDwxTHPLIWcc+6n415mL+MUUK QEtZ7OvwS3nY8P8jUiKnRYo4GAdjHucGILrhjUZaAS6YHZB3nx8p3U+fdtJGTxuBc6OV SwKAqTmWEysdABeFuUldlkyc38nOSbyWOyFq0g7LIwDj+GNa4p4CJItbwv5dkeWEFSUA sqow== X-Gm-Message-State: AKS2vOw7sDzkmU6VCGdqDDwuSCMf0vZtQlGTr6OpWZ66G0kQyCpSJtHq V9fSz4WQwUq4Gu0m0Cx35T2qXJP+bg== X-Received: by 10.46.22.5 with SMTP id w5mr14244174ljd.26.1499356910766; Thu, 06 Jul 2017 09:01:50 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.5.20 with HTTP; Thu, 6 Jul 2017 09:01:49 -0700 (PDT) In-Reply-To: <20170626021135.GF17840@kduck.kaduk.org> References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> <20170626021135.GF17840@kduck.kaduk.org> From: Daniel Migault Date: Thu, 6 Jul 2017 12:01:49 -0400 X-Google-Sender-Auth: E2b5Z0emWnIB45XGF_HeUQvh4SM Message-ID: To: Benjamin Kaduk Cc: Martin Rex , jaltman@secure-endpoints.com, kitten@ietf.org, curdle Content-Type: multipart/alternative; boundary="f403045fbada0ed3e90553a83c36" Archived-At: Subject: Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:01:55 -0000 --f403045fbada0ed3e90553a83c36 Content-Type: text/plain; charset="UTF-8" Hi, Thank you for the discussion. It seems that overall the current draft has a reached consensus. Are we ready to move the draft forward or do we need any additional discussions ? If you think more discussion is needed please let us know as soon as possible. Unless concerns are raised, I am planning to set the shepherd write up early next week. Regards, Daniel On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk wrote: > Hi Martin, > > On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote: > > Benjamin Kaduk wrote: > > > > > > It sounds like you are asking for the addition of some text along > > > the lines of: > > > > > > Software support is only a bare minimum requirement for deprecating > > > RC4 enctypes; there may be additional logistical considerations > > > involved such as provisioning AES keys for all principals and > > > updating software configuration to enable AES and disable deprecated > > > encryption types. > > > > > > Is that something you are asking for? > > > > Yes, thank your. This sounds good to me. I consider it even more > > helpful than the reference to particular versions of particular > > OpenSource Kerberos implementations, because this is a characteristic > > that is sort-of implied by how kerberos-enctypes keys are created > > (derived by string2key) and probably affect all implementations of > > Kerberos, yet it is non-obvious to consumers of the technology. > > Thank you for clarifying your comment into a request. > > > > > There is a substantial difference between cipher suites in TLS, where > > key length, strength and algorithm for the symmetric crypto is mostly > > irrelevant to the (PKI) credentials, and where using new TLS cipher > suites > > and deprecating old TLS cipher suites does not have a rekeying > requirement. > > To some extent this is inherent in Kerberos's use of symmetric crypto for > authentication, as opposed to TLS which uses asymmetric crypto for > authentication and switches to symmetric crypto for efficiency for > bulk data transfer. > > > (Jeffrey Altman wrote:) > % In my opinion, such text is inappropriate for an RFC. The deprecation > % of the encryption type is a protocol action. The RFC is not guidance > % for system administrators. Such guidance should come from the protocol > % implementations. > % > % As such I believe the addition of text similar to the above is > % unnecessary for publication. > > > > > I do believe that it is very appropriate to provide such kind of a > > guidance in an RFC, so that it this recommendation for deprecation > > becomes more comprehensible and the trade-offs clearer to mere consumers > > of the Kerberos technology, readers that aren't Kerberos protocol experts > > and senior Kerberos implementers. > > In general I tend to hew more to Jeffrey's track that protocol > specifications > should limit themseles to protocol-level work. I could see some grounds > for an exception here, though, in that the deployment difficulties are > inherent to any Kerberos deployment that follows best practice of not > storing > user passwords (only derived keys). > > Given Jeffrey's reasoning, I do not think my above "proposed text" > (to get clarification from Martin) should be used as-is; if we do want > to provide the clarification that Martin wants, I would want to rephrase > things somewhat. But, it still seems unclear where the WG consensus lies > on the question of including any guidance at all, here. Can others > please weigh in? > > > > When making admins sufficiently aware of predictable interop-problems, > > we may actually see more administrative deprecation of weak Kerberos > > enctypes than leaving them in the dark, and it helps reducing the amount > > of stumped users, helpdesks and admins. > > Admins are more likely to read software-provided documentation than > protocol specs; this argument seems speculative to me. > > -Ben > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --f403045fbada0ed3e90553a83c36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for the discussion. It see= ms that overall the current draft has a reached consensus. Are we ready to = move the draft forward or do we need any additional discussions ? If you th= ink more discussion is needed please let us know as soon as possible. Unles= s concerns are raised, I am planning to set=C2=A0 the shepherd write up ear= ly next week.

Regards,
Daniel

On Sun, Jun 25, 2017 at 10:11 = PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Martin,

On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote:
> Benjamin Kaduk wrote:
> >
> > It sounds like you are asking for the add= ition of some text along
> > the lines of:
> >
> >=C2=A0 =C2=A0Software support is only a bare minimum requirement f= or deprecating
> >=C2=A0 =C2=A0RC4 enctypes; there may be additional logistical cons= iderations
> >=C2=A0 =C2=A0involved such as provisioning AES keys for all princi= pals and
> >=C2=A0 =C2=A0updating software configuration to enable AES and dis= able deprecated
> >=C2=A0 =C2=A0encryption types.
> >
> > Is that something you are asking for?
>
> Yes, thank your.=C2=A0 This sounds good to me.=C2=A0 I consider it eve= n more
> helpful than the reference to particular versions of particular
> OpenSource Kerberos implementations, because this is a characteristic<= br> > that is sort-of implied by how kerberos-enctypes keys are created
> (derived by string2key) and probably affect all implementations of
> Kerberos, yet it is non-obvious to consumers of the technology.

Thank you for clarifying your comment into a request.

>
> There is a substantial difference between cipher suites in TLS, where<= br> > key length, strength and algorithm for the symmetric crypto is mostly<= br> > irrelevant to the (PKI) credentials, and where using new TLS cipher su= ites
> and deprecating old TLS cipher suites does not have a rekeying require= ment.

To some extent this is inherent in Kerberos's use of symmetric c= rypto for
authentication, as opposed to TLS which uses asymmetric crypto for
authentication and switches to symmetric crypto for efficiency for
bulk data transfer.


(Jeffrey Altman wrote:)
% In my opinion, such text is inappropriate for an RFC.=C2=A0 The deprecati= on
% of the encryption type is a protocol action.=C2=A0 The RFC is not guidanc= e
% for system administrators.=C2=A0 Such guidance should come from the proto= col
% implementations.
%
% As such I believe the addition of text similar to the above is
% unnecessary for publication.

>
> I do believe that it is very appropriate to provide such kind of a
> guidance in an RFC, so that it this recommendation for deprecation
> becomes more comprehensible and the trade-offs clearer to mere consume= rs
> of the Kerberos technology, readers that aren't Kerberos protocol = experts
> and senior Kerberos implementers.

In general I tend to hew more to Jeffrey's track that protocol s= pecifications
should limit themseles to protocol-level work.=C2=A0 I could see some groun= ds
for an exception here, though, in that the deployment difficulties are
inherent to any Kerberos deployment that follows best practice of not stori= ng
user passwords (only derived keys).

Given Jeffrey's reasoning, I do not think my above "proposed text&= quot;
(to get clarification from Martin) should be used as-is; if we do want
to provide the clarification that Martin wants, I would want to rephrase things somewhat.=C2=A0 But, it still seems unclear where the WG consensus l= ies
on the question of including any guidance at all, here.=C2=A0 Can others please weigh in?


> When making admins sufficiently aware of predictable interop-problems,=
> we may actually see more administrative deprecation of weak Kerberos > enctypes than leaving them in the dark, and it helps reducing the amou= nt
> of stumped users, helpdesks and admins.

Admins are more likely to read software-provided documentation than<= br> protocol specs; this argument seems speculative to me.

-Ben

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--f403045fbada0ed3e90553a83c36-- From nobody Fri Jul 7 01:15:50 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27DA1241FC; Fri, 7 Jul 2017 01:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 76BtGmKTfiQK; Fri, 7 Jul 2017 01:15:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 BF21113187B; Fri, 7 Jul 2017 01:15:45 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v678Fi2C001733 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Jul 2017 08:15:44 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v678FhGw029965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Jul 2017 08:15:43 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v678Fhph012680; Fri, 7 Jul 2017 08:15:43 GMT Received: from dhcp-adc-twvpn-3-vpnpool-10-154-121-82.vpn.oracle.com (/10.154.121.82) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jul 2017 01:15:42 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Weijun Wang In-Reply-To: <1101e365-22f9-f850-cfce-f1fa2a626422@oracle.com> Date: Fri, 7 Jul 2017 16:15:36 +0800 Cc: kitten , draft-ietf-kitten-rfc5653bis@ietf.org, Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170619034152.GZ39245@kduck.kaduk.org> <1101e365-22f9-f850-cfce-f1fa2a626422@oracle.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 08:15:48 -0000 Hi Ekr I=E2=80=99m about to write another version of this I-D. Except for the = rearrangement of example codes in S 6, do you have any other particular = parts I need to update? Thanks Max > On Jun 19, 2017, at 3:52 PM, Weijun Wang = wrote: >=20 > Hi Ekr, >=20 > Thanks for the review. >=20 > Below I keep questions that I can answer. For other general GSS-API = questions, I could not answer better than Ben. Thanks a lot, Ben. >=20 > On 06/19/2017 11:41 AM, Benjamin Kaduk wrote: >> On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote: >>> S 6.1.16. >>> Can addProviderAtFront() be used to add new providers which >>> the API would not normally use at all? >> It seems likely. In the C bindings we generally have mechanisms >> globally enabled, and site-local customizations go in >> /etc/gss/mechs.d . >=20 > Yes. >=20 > A Java security provider advertises what service(s) it provides (for = GSS-API, GssApiMechanism). If someone adds a provider that does not = contains this service, it will be ignored. >=20 >>> S 6.5.7. >>> Does "privacy" here mean "confidentiality"? Can you clarify. >> That's the only interpretation I can come up with that makes sense, >> but let's check with the authors. >=20 > Yes. >=20 >>>=20 >>> EDITORIAL >>> S 3.3. >>> Please do not use the phrase "cryptographic checksum", I recognize >>> that the terminology in this document is idiosyncratic because of >>> age, but this isn't really a modern term. Typically >>> we would now use "authentication tag" or "integrity tag" >=20 > We can use "integrity tag". >=20 >>>=20 >>> S 4.12.3. >>> So an exception is thrown for an invalid token? >> I think so. >=20 > Correct, if the input token is not well-formed or was not correctly = signed/encrypted by the peer, an exception will be thrown. >=20 >>>=20 >>> S 5.3. >>> gss_release_cred() is just eager, right? In any case the data will >>> be cleaned up on GC? In any case you should make this clear. >> I think so, though there is an implicit recommendation to destroy >> sensitive crypto material immediately after use. >=20 > Well... >=20 > Java has a mechanism to provide a callback method called finalize() = and hope GC will call it, and Oracle's SunNativeGSS provider (as a = bridge to a native GSS-API lib) does provide one to release the native = cred handle explicitly. That said, everyone is saying finalize() is = unreliable and it usage is already deprecated. >=20 > Even if finalize() is reliable, whether it should dispose the cred is = not documented and up to the implementation. >=20 >>> S 6.1.15. >>> I wouldn't say you are "creating a previously exported context". You >>> are either importing it or creating a new context from a previously >>> exported one. >> "importing" would be more consistent with the language used by the C >> bindings. >=20 > Yes. >=20 >>> S 6.2.1. >>>=20 >>> // export and re-import the name >>> byte[] exportName =3D mechName.export(); >>>=20 >>> // create a new name object from the exported buffer >>> GSSName newName =3D mgr.createName(exportName, >>> GSSName.NT_EXPORT_NAME); >>>=20 >>> This comment structure is confusing, because the first is just >>> the export. I would change that. >=20 > Correct. >=20 >>>=20 >>>=20 >>> S 6.2.6. >>> It's a bit unclear to me under what circumstances you can compare = GSS >>> names. I see you can do .equals() and export/memcmp, but can you >>> compare strings? Perhaps after you canonicalize them? >> You have stumbled upon one of the worst warts on the GSS-API ;) >> It is confusing no matter whether you look at the abstract spec or >> language bindings. When you first create a name you end up with a >> generic "internal name", and certain operations can cause that to be >> transformed into a "mechanism name" that contains additional >> mechanism-specific information. The offically recommended way to >> compare GSS names is to GSS_Export_name() and use memcmp(), noting >> that you must GSS_Canonicalize_name() between GSS_Import_name() and >> GSS_Export_name(). >>> =46rom RFC 2743: >> Note that the results obtained by using GSS_Compare_name() will in >> general be different from those obtained by invoking >> GSS_Canonicalize_name() and GSS_Export_name(), and then comparing = the >> exported names. The first series of operations determines whether >> two (unauthenticated) names identify the same principal; the = second >> whether a particular mechanism would authenticate them as the same >> principal. These two operations will in general give the same >> results only for MNs. >> Sadly, lots of applications use GSS_Display_name() and strcmp(), >> which is something of a security vulnerability waiting to happen. >> I'm not entirely sure that I've answered your question, though. >=20 > Oracle's Java implementation looks like this: >=20 > 1. If they are both canonicalized, compare the canonicalized mech = element inside. >=20 > 2. If only one is canonicalized, try to canonicalize the other one = using this one's mechanism, and compare the result. >=20 > 3. Otherwise, canonicalize both to Kerberos 5 and compare the result. >=20 > By comparing 2 canonicalized mech elements, I mean comparing the type = and the string or byte array name, which is equivalent to comparing the = exported form. >=20 >>>=20 >>> S 6.3.9. >>> Does "union over all mechanisms" mean that if mechanism A supports >>> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT" >> Yes. >> Again quoting RFC 2743: >> GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for >> "cred_usage" if both of the following conditions hold: >> (1) there exists in the credential an element which allows = context >> initiation using some mechanism >> (2) there exists in the credential an element which allows = context >> acceptance using some mechanism (allowably, but not = necessarily, >> one of the same mechanism(s) qualifying for (1)). >=20 > Same as in Java. >=20 >>> S 6.4.X >>> The presentation order here is weird because you show = initSecContext() >>> in the 6.4.1. example but then define it in 6.4.3 and then show >>> another example that's reduced in 6.4.4. Perhaps you can consolidate >>> these? >> I'll leave that for the authors. >=20 > Yes, it's confused. >=20 > Basically, 6.4.4 and 6.4.6 are meant to demonstrate initSecContext() = and acceptSecContext(), and 6.4.1 is meant to demonstrate all methods in = GSSContext (here, from the initiator's perspective). >=20 > For this bis, I am OK with just removing 6.4.4 and 6.4.6. The examples = shown here are only of the most common usage and can be read again in S = 7. >=20 > Or, we can indent 6.4.4 and 6.4.6 (plus 6.1.17 and 6.1.19) one level = deeper to become 6.4.3.1 etc and/or rename the title to "initSecContext = Example code" etc. >=20 > Or maybe the order looks weird because every class has an example as = the first sub-section (see 6.1.1, 6.2.1, and 6.3.1) before talking about = what this class is about. If this is the major reason, we can move these = examples (6.1.1, 6.2.1, 6.3.1, and 6.4.1) to the end of each section. = But then we will also need to indent/rename 6.1.17 and 6.1.19 to avoid = two "Example code" in a row. >=20 > Thanks, > Weijun >=20 >> -Ben From nobody Sat Jul 8 11:43:40 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AB412EC51 for ; Sat, 8 Jul 2017 11:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 OwAHs1nPr-y8 for ; Sat, 8 Jul 2017 11:43:36 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055E7126DFF for ; Sat, 8 Jul 2017 11:43:36 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id f194so18764550yba.3 for ; Sat, 08 Jul 2017 11:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VDiwVXvGshz60Duqe7iOlPcJr1+dXuNcm346JklGI3c=; b=Qr5tEHpFVLULun0UHsTGKwjjJn2uBZSqxqGCQ9DSQWe6xOcMNPb1AwEA0fkC/YoTMV caV4ZPDf+W5CjsWD3CryGah4cUum2l4vFO2BZSkaW1up8BKIsTxVbFsxsCJCEAASnN6s koePXmW8HTdhKoIWPe3uuu3LZyqRDAOYzeXR6hSXHRssELOPcF41vCK9rvKNFqib3Sbs C59SOoWg/Xwje98htq770/4aHdc2yxTlZMjg7ctaX9AGyulqwKBXTLLJR5d4B9TqPh6U a3XdVGYRFu0SpoDI0aF1YpGIRObBPDSJ0xmiXWAIuyZLZoDxzyGs+hhEnOHRmz+FbPlm oF8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VDiwVXvGshz60Duqe7iOlPcJr1+dXuNcm346JklGI3c=; b=IdTf94Ogz7sSx8zHhflGVbRA2yvbfe5gi9eFAq/hMxGJ2cLz95KGyL9+tDUXM9aSra dN+LpCaUbCEtMtPkZ2/h1fgH4UqBFNgWkHoFX2vF3Usr46wKqqK71PqRs6Aye/DkY4hA LOLGtbX/Eiyk5c66kMUW88hX2k4PZ+xYcOXUuLLszwfsInhizjZ7gLqZJbX+GN0tmn0g sxrvsrTZtgypwf2OGQpqMfZZlgllh9UbMj686a35RmLeI+r6WMD+QaoZOjR6HTF8eO6c NPQ0saxcspllUJlI0iM5cR3Gh4xHBTGFfl1PUR/REax/GT6EEPE54WOZDKZ7IH46xwDe LrWg== X-Gm-Message-State: AIVw112s3253T7B8LRGpbvYuhYOVhWhZnFgu0350xg0qyE9Fkq+w9KLd RLto+yHvczv84JgHdqAC9Jm6xjQix5dr X-Received: by 10.37.48.67 with SMTP id w64mr8859934ybw.89.1499539415190; Sat, 08 Jul 2017 11:43:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 8 Jul 2017 11:42:54 -0700 (PDT) In-Reply-To: References: <20170619034152.GZ39245@kduck.kaduk.org> <1101e365-22f9-f850-cfce-f1fa2a626422@oracle.com> From: Eric Rescorla Date: Sat, 8 Jul 2017 11:42:54 -0700 Message-ID: To: Weijun Wang Cc: kitten , draft-ietf-kitten-rfc5653bis@ietf.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="001a114899c42b96e80553d2ba85" Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 18:43:39 -0000 --001a114899c42b96e80553d2ba85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, anything where I had a question probably needs some clarifying text. -Ekr On Fri, Jul 7, 2017 at 1:15 AM, Weijun Wang wrote: > Hi Ekr > > I=E2=80=99m about to write another version of this I-D. Except for the > rearrangement of example codes in S 6, do you have any other particular > parts I need to update? > > Thanks > Max > > > On Jun 19, 2017, at 3:52 PM, Weijun Wang wrote= : > > > > Hi Ekr, > > > > Thanks for the review. > > > > Below I keep questions that I can answer. For other general GSS-API > questions, I could not answer better than Ben. Thanks a lot, Ben. > > > > On 06/19/2017 11:41 AM, Benjamin Kaduk wrote: > >> On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote: > >>> S 6.1.16. > >>> Can addProviderAtFront() be used to add new providers which > >>> the API would not normally use at all? > >> It seems likely. In the C bindings we generally have mechanisms > >> globally enabled, and site-local customizations go in > >> /etc/gss/mechs.d . > > > > Yes. > > > > A Java security provider advertises what service(s) it provides (for > GSS-API, GssApiMechanism). If someone adds a provider that does not > contains this service, it will be ignored. > > > >>> S 6.5.7. > >>> Does "privacy" here mean "confidentiality"? Can you clarify. > >> That's the only interpretation I can come up with that makes sense, > >> but let's check with the authors. > > > > Yes. > > > >>> > >>> EDITORIAL > >>> S 3.3. > >>> Please do not use the phrase "cryptographic checksum", I recognize > >>> that the terminology in this document is idiosyncratic because of > >>> age, but this isn't really a modern term. Typically > >>> we would now use "authentication tag" or "integrity tag" > > > > We can use "integrity tag". > > > >>> > >>> S 4.12.3. > >>> So an exception is thrown for an invalid token? > >> I think so. > > > > Correct, if the input token is not well-formed or was not correctly > signed/encrypted by the peer, an exception will be thrown. > > > >>> > >>> S 5.3. > >>> gss_release_cred() is just eager, right? In any case the data will > >>> be cleaned up on GC? In any case you should make this clear. > >> I think so, though there is an implicit recommendation to destroy > >> sensitive crypto material immediately after use. > > > > Well... > > > > Java has a mechanism to provide a callback method called finalize() and > hope GC will call it, and Oracle's SunNativeGSS provider (as a bridge to = a > native GSS-API lib) does provide one to release the native cred handle > explicitly. That said, everyone is saying finalize() is unreliable and it > usage is already deprecated. > > > > Even if finalize() is reliable, whether it should dispose the cred is > not documented and up to the implementation. > > > >>> S 6.1.15. > >>> I wouldn't say you are "creating a previously exported context". You > >>> are either importing it or creating a new context from a previously > >>> exported one. > >> "importing" would be more consistent with the language used by the C > >> bindings. > > > > Yes. > > > >>> S 6.2.1. > >>> > >>> // export and re-import the name > >>> byte[] exportName =3D mechName.export(); > >>> > >>> // create a new name object from the exported buffer > >>> GSSName newName =3D mgr.createName(exportName, > >>> GSSName.NT_EXPORT_NAME); > >>> > >>> This comment structure is confusing, because the first is just > >>> the export. I would change that. > > > > Correct. > > > >>> > >>> > >>> S 6.2.6. > >>> It's a bit unclear to me under what circumstances you can compare GSS > >>> names. I see you can do .equals() and export/memcmp, but can you > >>> compare strings? Perhaps after you canonicalize them? > >> You have stumbled upon one of the worst warts on the GSS-API ;) > >> It is confusing no matter whether you look at the abstract spec or > >> language bindings. When you first create a name you end up with a > >> generic "internal name", and certain operations can cause that to be > >> transformed into a "mechanism name" that contains additional > >> mechanism-specific information. The offically recommended way to > >> compare GSS names is to GSS_Export_name() and use memcmp(), noting > >> that you must GSS_Canonicalize_name() between GSS_Import_name() and > >> GSS_Export_name(). > >>> From RFC 2743: > >> Note that the results obtained by using GSS_Compare_name() will in > >> general be different from those obtained by invoking > >> GSS_Canonicalize_name() and GSS_Export_name(), and then comparing t= he > >> exported names. The first series of operations determines whether > >> two (unauthenticated) names identify the same principal; the second > >> whether a particular mechanism would authenticate them as the same > >> principal. These two operations will in general give the same > >> results only for MNs. > >> Sadly, lots of applications use GSS_Display_name() and strcmp(), > >> which is something of a security vulnerability waiting to happen. > >> I'm not entirely sure that I've answered your question, though. > > > > Oracle's Java implementation looks like this: > > > > 1. If they are both canonicalized, compare the canonicalized mech > element inside. > > > > 2. If only one is canonicalized, try to canonicalize the other one usin= g > this one's mechanism, and compare the result. > > > > 3. Otherwise, canonicalize both to Kerberos 5 and compare the result. > > > > By comparing 2 canonicalized mech elements, I mean comparing the type > and the string or byte array name, which is equivalent to comparing the > exported form. > > > >>> > >>> S 6.3.9. > >>> Does "union over all mechanisms" mean that if mechanism A supports > >>> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT" > >> Yes. > >> Again quoting RFC 2743: > >> GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for > >> "cred_usage" if both of the following conditions hold: > >> (1) there exists in the credential an element which allows conte= xt > >> initiation using some mechanism > >> (2) there exists in the credential an element which allows conte= xt > >> acceptance using some mechanism (allowably, but not necessarily, > >> one of the same mechanism(s) qualifying for (1)). > > > > Same as in Java. > > > >>> S 6.4.X > >>> The presentation order here is weird because you show initSecContext(= ) > >>> in the 6.4.1. example but then define it in 6.4.3 and then show > >>> another example that's reduced in 6.4.4. Perhaps you can consolidate > >>> these? > >> I'll leave that for the authors. > > > > Yes, it's confused. > > > > Basically, 6.4.4 and 6.4.6 are meant to demonstrate initSecContext() an= d > acceptSecContext(), and 6.4.1 is meant to demonstrate all methods in > GSSContext (here, from the initiator's perspective). > > > > For this bis, I am OK with just removing 6.4.4 and 6.4.6. The examples > shown here are only of the most common usage and can be read again in S 7= . > > > > Or, we can indent 6.4.4 and 6.4.6 (plus 6.1.17 and 6.1.19) one level > deeper to become 6.4.3.1 etc and/or rename the title to "initSecContext > Example code" etc. > > > > Or maybe the order looks weird because every class has an example as th= e > first sub-section (see 6.1.1, 6.2.1, and 6.3.1) before talking about what > this class is about. If this is the major reason, we can move these > examples (6.1.1, 6.2.1, 6.3.1, and 6.4.1) to the end of each section. But > then we will also need to indent/rename 6.1.17 and 6.1.19 to avoid two > "Example code" in a row. > > > > Thanks, > > Weijun > > > >> -Ben > > --001a114899c42b96e80553d2ba85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, anything where I had a question probably needs some = clarifying text.

-Ekr


On Fri, Jul 7, 2017 at 1:= 15 AM, Weijun Wang <weijun.wang@oracle.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi Ekr

I=E2=80=99m about to write another version of this I-D. Except for the rear= rangement of example codes in S 6, do you have any other particular parts I= need to update?

Thanks
Max

> On Jun 19, 2017, at 3:52 PM, Weijun Wang <weijun.wang@oracle.com> wrote:
>
> Hi Ekr,
>
> Thanks for the review.
>
> Below I keep questions that I can answer. For other general GSS-API qu= estions, I could not answer better than Ben. Thanks a lot, Ben.
>
> On 06/19/2017 11:41 AM, Benjamin Kaduk wrote:
>> On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote:
>>> S 6.1.16.
>>> Can addProviderAtFront() be used to add new providers which >>> the API would not normally use at all?
>> It seems likely.=C2=A0 In the C bindings we generally have mechani= sms
>> globally enabled, and site-local customizations go in
>> /etc/gss/mechs.d .
>
> Yes.
>
> A Java security provider advertises what service(s) it provides (for G= SS-API, GssApiMechanism). If someone adds a provider that does not contains= this service, it will be ignored.
>
>>> S 6.5.7.
>>> Does "privacy" here mean "confidentiality"= ? Can you clarify.
>> That's the only interpretation I can come up with that makes s= ense,
>> but let's check with the authors.
>
> Yes.
>
>>>
>>> EDITORIAL
>>> S 3.3.
>>> Please do not use the phrase "cryptographic checksum"= ;, I recognize
>>> that the terminology in this document is idiosyncratic because= of
>>> age, but this isn't really a modern term. Typically
>>> we would now use "authentication tag" or "integ= rity tag"
>
> We can use "integrity tag".
>
>>>
>>> S 4.12.3.
>>> So an exception is thrown for an invalid token?
>> I think so.
>
> Correct, if the input token is not well-formed or was not correctly si= gned/encrypted by the peer, an exception will be thrown.
>
>>>
>>> S 5.3.
>>> gss_release_cred() is just eager, right? In any case the data = will
>>> be cleaned up on GC? In any case you should make this clear. >> I think so, though there is an implicit recommendation to destroy<= br> >> sensitive crypto material immediately after use.
>
> Well...
>
> Java has a mechanism to provide a callback method called finalize() an= d hope GC will call it, and Oracle's SunNativeGSS provider (as a bridge= to a native GSS-API lib) does provide one to release the native cred handl= e explicitly. That said, everyone is saying finalize() is unreliable and it= usage is already deprecated.
>
> Even if finalize() is reliable, whether it should dispose the cred is = not documented and up to the implementation.
>
>>> S 6.1.15.
>>> I wouldn't say you are "creating a previously exporte= d context". You
>>> are either importing it or creating a new context from a previ= ously
>>> exported one.
>> "importing" would be more consistent with the language u= sed by the C
>> bindings.
>
> Yes.
>
>>> S 6.2.1.
>>>
>>>=C2=A0 =C2=A0 // export and re-import the name
>>>=C2=A0 =C2=A0 byte[] exportName =3D mechName.export();
>>>
>>>=C2=A0 =C2=A0 // create a new name object from the exported buf= fer
>>>=C2=A0 =C2=A0 GSSName newName =3D mgr.createName(exportName, >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 GSSName.NT_EXPORT_NAME);
>>>
>>> This comment structure is confusing, because the first is just=
>>> the export. I would change that.
>
> Correct.
>
>>>
>>>
>>> S 6.2.6.
>>> It's a bit unclear to me under what circumstances you can = compare GSS
>>> names. I see you can do .equals() and export/memcmp, but can y= ou
>>> compare strings? Perhaps after you canonicalize them?
>> You have stumbled upon one of the worst warts on the GSS-API ;) >> It is confusing no matter whether you look at the abstract spec or=
>> language bindings.=C2=A0 When you first create a name you end up w= ith a
>> generic "internal name", and certain operations can caus= e that to be
>> transformed into a "mechanism name" that contains additi= onal
>> mechanism-specific information.=C2=A0 The offically recommended wa= y to
>> compare GSS names is to GSS_Export_name() and use memcmp(), noting=
>> that you must GSS_Canonicalize_name() between GSS_Import_name() an= d
>> GSS_Export_name().
>>> From RFC 2743:
>>=C2=A0 =C2=A0 Note that the results obtained by using GSS_Compare_n= ame() will in
>>=C2=A0 =C2=A0 general be different from those obtained by invoking<= br> >>=C2=A0 =C2=A0 GSS_Canonicalize_name() and GSS_Export_name(), and th= en comparing the
>>=C2=A0 =C2=A0 exported names.=C2=A0 The first series of operations = determines whether
>>=C2=A0 =C2=A0 two (unauthenticated) names identify the same princip= al; the second
>>=C2=A0 =C2=A0 whether a particular mechanism would authenticate the= m as the same
>>=C2=A0 =C2=A0 principal.=C2=A0 These two operations will in general= give the same
>>=C2=A0 =C2=A0 results only for MNs.
>> Sadly, lots of applications use GSS_Display_name() and strcmp(), >> which is something of a security vulnerability waiting to happen.<= br> >> I'm not entirely sure that I've answered your question, th= ough.
>
> Oracle's Java implementation looks like this:
>
> 1. If they are both canonicalized, compare the canonicalized mech elem= ent inside.
>
> 2. If only one is canonicalized, try to canonicalize the other one usi= ng this one's mechanism, and compare the result.
>
> 3. Otherwise, canonicalize both to Kerberos 5 and compare the result.<= br> >
> By comparing 2 canonicalized mech elements, I mean comparing the type = and the string or byte array name, which is equivalent to comparing the exp= orted form.
>
>>>
>>> S 6.3.9.
>>> Does "union over all mechanisms" mean that if mechan= ism A supports
>>> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCE= PT"
>> Yes.
>> Again quoting RFC 2743:
>>=C2=A0 =C2=A0 GSS_Inquire_cred() should indicate INITIATE-AND-ACCEP= T for
>>=C2=A0 =C2=A0 "cred_usage" if both of the following condi= tions hold:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(1) there exists in the credential an el= ement which allows context
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0initiation using some mechanism
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2) there exists in the credential an el= ement which allows context
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0acceptance using some mechanism (allowab= ly, but not necessarily,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0one of the same mechanism(s) qualifying = for (1)).
>
> Same as in Java.
>
>>> S 6.4.X
>>> The presentation order here is weird because you show initSecC= ontext()
>>> in the 6.4.1. example but then define it in 6.4.3 and then sho= w
>>> another example that's reduced in 6.4.4. Perhaps you can c= onsolidate
>>> these?
>> I'll leave that for the authors.
>
> Yes, it's confused.
>
> Basically, 6.4.4 and 6.4.6 are meant to demonstrate initSecContext() a= nd acceptSecContext(), and 6.4.1 is meant to demonstrate all methods in GSS= Context (here, from the initiator's perspective).
>
> For this bis, I am OK with just removing 6.4.4 and 6.4.6. The examples= shown here are only of the most common usage and can be read again in S 7.=
>
> Or, we can indent 6.4.4 and 6.4.6 (plus 6.1.17 and 6.1.19) one level d= eeper to become 6.4.3.1 etc and/or rename the title to "initSecContext= Example code" etc.
>
> Or maybe the order looks weird because every class has an example as t= he first sub-section (see 6.1.1, 6.2.1, and 6.3.1) before talking about wha= t this class is about. If this is the major reason, we can move these examp= les (6.1.1, 6.2.1, 6.3.1, and 6.4.1) to the end of each section. But then w= e will also need to indent/rename 6.1.17 and 6.1.19 to avoid two "Exam= ple code" in a row.
>
> Thanks,
> Weijun
>
>> -Ben


--001a114899c42b96e80553d2ba85-- From nobody Wed Jul 12 16:00:18 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21CB129482; Wed, 12 Jul 2017 16:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bqu8c8ue2DMw; Wed, 12 Jul 2017 16:00:14 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6901B12F258; Wed, 12 Jul 2017 16:00:13 -0700 (PDT) X-AuditID: 12074424-35bff70000001405-92-5966a9fb13e1 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 74.57.05125.CF9A6695; Wed, 12 Jul 2017 19:00:12 -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 v6CN0A75026325; Wed, 12 Jul 2017 19:00:11 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6CN06JS009804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2017 19:00:08 -0400 Date: Wed, 12 Jul 2017 18:00:06 -0500 From: Benjamin Kaduk To: Daniel Migault Cc: Martin Rex , kitten@ietf.org, curdle Message-ID: <20170712230006.GD80947@kduck.kaduk.org> References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> <20170626021135.GF17840@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrftnZVqkwckjwhZbF85itpgyfQ+b xdHNq1gsen/vYHZg8fj19Sqbx5IlP5k8pnzeyhjAHMVlk5Kak1mWWqRvl8CV8WzHTdaCl+oV yzr/MDcw/pTrYuTgkBAwkfg0TbeLkYtDSGAxk8TFpS8YIZyNjBJrd79jg3CuMknMfLGYBaSD RUBV4u9J/i5GTg42ARWJhu7LzCC2iICBxMsJO9lAbGYBD4mFm76wgpQLC8RKtC/UAgnzAu16 PPEVO0hYSOAGo8R6Q4iwoMTJmU9YIDq1JG78e8kEUsIsIC2x/B8HSJhTIFDi2qXDjCC2qICy xN/D91gmMArMQtI9C0n3LITuBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3 MYKCl91FZQdjd4/3IUYBDkYlHl4OzbRIIdbEsuLK3EOMkhxMSqK8KsFAIb6k/JTKjMTijPii 0pzU4kOMEhzMSiK8di1AOd6UxMqq1KJ8mJQ0B4uSOK+4RmOEkEB6YklqdmpqQWoRTFaGg0NJ gtdjBVCjYFFqempFWmZOCUKaiYMTZDgP0PD8JSDDiwsSc4sz0yHypxgVpcR5n4E0C4AkMkrz 4HpByUUie3/NK0ZxoFeEeactB6riASYmuO5XQIOZgAavyU4BGVySiJCSamDczxS+ozt7qsPM /qVWFn/UFURfLosPWRMYceljE+/bvM8XZMwePN788Evobv0guUOPZzl7BC+VeSrwpNfonP91 pfe79/NXpDdG633Wy3hTkrZR5lKf2XEBt9fHJeLlRDbZ1/hv37B5guPsfy7rW56EPhSpF9rj 3TS7fEXIJM21rEEv+K/7sNxQYinOSDTUYi4qTgQAI4YMwwkDAAA= Archived-At: Subject: Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 23:00:17 -0000 On Thu, Jul 06, 2017 at 12:01:49PM -0400, Daniel Migault wrote: > Hi, > > Thank you for the discussion. It seems that overall the current draft has a > reached consensus. Are we ready to move the draft forward or do we need any > additional discussions ? If you think more discussion is needed please let > us know as soon as possible. Unless concerns are raised, I am planning to > set the shepherd write up early next week. (Intentionally retaining quoted text below.) I think we're ready to move the draft forward (as-is). Having reviewed the extra comments, as well as the current text, I don't think that there is a need to add something along the lines of what Martin had proposed. If I was going to add anything, it would be along the lines of: Administrators are additionally expected to be capable of designing rollout plans that minimize disruption, provisioning keys with the new enctypes before enabling new enctypes in configuration. (at the end of section 5.4). But it's not clear that this is really adding value. -Ben > On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk wrote: > > > Hi Martin, > > > > On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote: > > > Benjamin Kaduk wrote: > > > > > > > > It sounds like you are asking for the addition of some text along > > > > the lines of: > > > > > > > > Software support is only a bare minimum requirement for deprecating > > > > RC4 enctypes; there may be additional logistical considerations > > > > involved such as provisioning AES keys for all principals and > > > > updating software configuration to enable AES and disable deprecated > > > > encryption types. > > > > > > > > Is that something you are asking for? > > > > > > Yes, thank your. This sounds good to me. I consider it even more > > > helpful than the reference to particular versions of particular > > > OpenSource Kerberos implementations, because this is a characteristic > > > that is sort-of implied by how kerberos-enctypes keys are created > > > (derived by string2key) and probably affect all implementations of > > > Kerberos, yet it is non-obvious to consumers of the technology. > > > > Thank you for clarifying your comment into a request. > > > > > > > > There is a substantial difference between cipher suites in TLS, where > > > key length, strength and algorithm for the symmetric crypto is mostly > > > irrelevant to the (PKI) credentials, and where using new TLS cipher > > suites > > > and deprecating old TLS cipher suites does not have a rekeying > > requirement. > > > > To some extent this is inherent in Kerberos's use of symmetric crypto for > > authentication, as opposed to TLS which uses asymmetric crypto for > > authentication and switches to symmetric crypto for efficiency for > > bulk data transfer. > > > > > > (Jeffrey Altman wrote:) > > % In my opinion, such text is inappropriate for an RFC. The deprecation > > % of the encryption type is a protocol action. The RFC is not guidance > > % for system administrators. Such guidance should come from the protocol > > % implementations. > > % > > % As such I believe the addition of text similar to the above is > > % unnecessary for publication. > > > > > > > > I do believe that it is very appropriate to provide such kind of a > > > guidance in an RFC, so that it this recommendation for deprecation > > > becomes more comprehensible and the trade-offs clearer to mere consumers > > > of the Kerberos technology, readers that aren't Kerberos protocol experts > > > and senior Kerberos implementers. > > > > In general I tend to hew more to Jeffrey's track that protocol > > specifications > > should limit themseles to protocol-level work. I could see some grounds > > for an exception here, though, in that the deployment difficulties are > > inherent to any Kerberos deployment that follows best practice of not > > storing > > user passwords (only derived keys). > > > > Given Jeffrey's reasoning, I do not think my above "proposed text" > > (to get clarification from Martin) should be used as-is; if we do want > > to provide the clarification that Martin wants, I would want to rephrase > > things somewhat. But, it still seems unclear where the WG consensus lies > > on the question of including any guidance at all, here. Can others > > please weigh in? > > > > > > > When making admins sufficiently aware of predictable interop-problems, > > > we may actually see more administrative deprecation of weak Kerberos > > > enctypes than leaving them in the dark, and it helps reducing the amount > > > of stumped users, helpdesks and admins. > > > > Admins are more likely to read software-provided documentation than > > protocol specs; this argument seems speculative to me. > > > > -Ben > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > From nobody Wed Jul 12 20:42:16 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AE01317DD for ; Wed, 12 Jul 2017 20:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ikSmWJT5vd3o for ; Wed, 12 Jul 2017 20:42:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 174CA1300BC for ; Wed, 12 Jul 2017 20:42:11 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6D3gAQu013770 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jul 2017 03:42:10 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v6D3g95g010598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jul 2017 03:42:10 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6D3g9Bo020531; Thu, 13 Jul 2017 03:42:09 GMT Received: from [192.168.1.222] (/125.33.58.26) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jul 2017 20:42:08 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Weijun Wang In-Reply-To: Date: Thu, 13 Jul 2017 11:41:59 +0800 Cc: kitten Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 03:42:15 -0000 Hi Ekr Please read my answers below to your original questions. > On Jun 18, 2017, at 2:23 AM, Eric Rescorla wrote: >=20 > This document seems generally sound. There are some things about this > API that confused/surprised me and seem perhaps unwise, but given that > this is a bis, I will mostly confine my review to mostly calling them > out and asking you to make sure I understand and that the document is > clear. >=20 > OVERALL > 1. What is a fatal error? > The document describes exceptions as indicating "fatal errors". > What does this mean for the state of the context. For instance, > if I receive an exception from initSecContext(), does that mean > that it is no longer possible to initiate it? Your example code > seems to treat them as fatal for the context. What happens > if I try to use a context after such an event? I=E2=80=99ll add a paragraph in "5.12. Error Reporting=E2=80=9D = explaining whether the context is useable after an exception is thrown, = for context establishment and per-message calls, respectively. Something = like +If an exception is thrown during context establishment, the context +negotiation has failed and the GSSContext object must be abandoned. +If it is thrown in a per-message call, the context can remain useful. >=20 >=20 > 2. How do I enforce properties for received messages? > I see that I can request services for context initialization > (requestConf), and that I can check whether a given message > was encrypted (getPrivacy) but it's not clear to me if this > causes the API to enforce these rules for tokens that I > receive. Is that possible or do I just need to check? You would have to check. Even if an established security context already = has its getConfState() being true, one can still wrap a message with = privacy state set to false and the peer will unwrap it with success. If = the peer insists only encrypted messages are allowed, she should always = check. This is already documented in 6.4.10. >=20 > 3. Are the request* flags() hard limits? E.g., if I do > requestMutualAuth() do I get it or fail? The method does not fail itself (i.e. does not throws an exception) and = you need to check the result with those getXyzState() methods after the = context is established. I can add a paragraph in S 5.9, something like: +If any retrieved attribute does not match the desired value +but it is necessary for the application protocol, the application = should +destroy the security context and not use it for application traffic. +Otherwise, at this point, the context can be used by the application to +apply cryptographic services to its data. >=20 > 4. It's a little unusual to have a structure where you keep > calling initSecContext or acceptContext() repeatedly. In > most APIs you would do like "setRole(Server)" or > "setRoleClient(), and then "Handshake(). Sorry but this is how GSS-API works now. >=20 > DETAIL > S 6.1.16. > Can addProviderAtFront() be used to add new providers which > the API would not normally use at all? No, 6.1.16 already had Only when the indicated provider does not support the needed mechanism should the GSSManager move on to a different provider. I think this implies that a new provider added might be used at all. >=20 > S 6.4.9. > Successful completion of this call does not guarantee that wrap = will > be able to protect a message of the computed length, since this > ability may depend on the availability of system resources at the > time that wrap is called. However, if the implementation itself > imposes an upper limit on the length of messages that may be > processed by wrap, the implementation should not return a value = that > is greater than this length. >=20 > This should seems pretty weak. This isn't a hard limit? I think Ben explained this perfectly. This method is mainly used to = calculate the source data size limit when you have a output token size = limit. >=20 > S 6.4.10. > Instance of MessageProp that is used by the > application to set the desired QOP and privacy > state. Set the desired QOP to 0 to request the > default QOP. Upon return from this method, this > object will contain the actual privacy state that > was applied to the message by the underlying > mechanism. >=20 > Just to be clear: if you ask for a specific QOP you always get it > (or failure). This checking thing is only if you use 0? Correct. >=20 > It would also be helpful to point out that QOP is mech-specific > as noted in RFC 2743. I=E2=80=99ll add a line saying "QOP is an integer defined by a = mechanism". >=20 >=20 > S 6.4.21. > What does requestInteg() mean? As far as I can tell the only thing > you can do with a context is wrap() or getMIC(), both of which involve > integrity. So what happens if you set it false? Ben explained it perfectly. Sometimes a mechanism only support = authentication but not secure communication. >=20 > S 6.5.7. > Does "privacy" here mean "confidentiality"? Can you clarify. I=E2=80=99ll add a line in 3.5 Confidentiality saying something like = =E2=80=9CConfidentiality will be applied if the privacy state is set to = true". Please forgive me I don=E2=80=99t want to alter the text in S 6 a = lot because those were copied as doc comment in implementations and I = don=E2=80=99t want them modified. >=20 >=20 > EDITORIAL > S 3.3. > Please do not use the phrase "cryptographic checksum", I recognize > that the terminology in this document is idiosyncratic because of > age, but this isn't really a modern term. Typically > we would now use "authentication tag" or "integrity tag=E2=80=9D GSS-API is still using the Checksum word everywhere (RFC 3961=E2=80=99s = title is =E2=80=9CEncryption and Checksum Specifications for Kerberos = 5"). I think the cryptographic word is added like we used in = cryptographic random number generator, which means it=E2=80=99s stronger = than CRC etc. I would like to continue using this word. >=20 > S 4.12.3. > So an exception is thrown for an invalid token? Yes, specifically, DEFECTIVE_TOKEN as defined in 4.12.1. S 6 has not spelt all possible GSSExceptions that a method might throw = for brevity. >=20 > S 5.3. > gss_release_cred() is just eager, right? In any case the data will > be cleaned up on GC? In any case you should make this clear. gss_release_cred() is eager, and there is no other guarantee the data = can be automatically cleaned up. Even if GC cleaned up the GSSCredential = object, there might be unreleased handles underneath. S 6.3 already has When the credential is no longer needed, the application should call = the dispose (equivalent to gss_release_cred) method to release any = resources held by the credential object and to destroy any = cryptographically sensitive information. Do you think it=E2=80=99s necessary to append something like =E2=80=9CAn = implementation should not rely on garbage control or a finalize() method = to dispose a credential=E2=80=9D? >=20 > S 6.1.15. > I wouldn't say you are "creating a previously exported context". You > are either importing it or creating a new context from a previously > exported one. Accepted. >=20 > S 6.2.1. >=20 > // export and re-import the name > byte[] exportName =3D mechName.export(); >=20 > // create a new name object from the exported buffer > GSSName newName =3D mgr.createName(exportName, > GSSName.NT_EXPORT_NAME); > =20 > This comment structure is confusing, because the first is just > the export. I would change that. Accepted. >=20 >=20 > S 6.2.6. > It's a bit unclear to me under what circumstances you can compare GSS > names. I see you can do .equals() and export/memcmp, but can you > compare strings? Perhaps after you canonicalize them? As Ben and I explained this is quite complicated. Can we not touch it in = this bis? >=20 > S 6.3.9. > Does "union over all mechanisms" mean that if mechanism A supports > INITIATE and B supports ACCEPT you get =E2=80=9CINITIATE_AND_ACCEPT" I=E2=80=99ll add some explanation: +Specifically, GSSCredential.INITIATE_AND_ACCEPT(0) should be returned +as long as there exists one credential element allowing context = initiation +and one credential element allowing context acceptance. These two = credential +elements are not necessarily the same one, nor do they need to use the +same mechanism(s). >=20 > S 6.4.X > The presentation order here is weird because you show initSecContext() > in the 6.4.1. example but then define it in 6.4.3 and then show > another example that's reduced in 6.4.4. Perhaps you can consolidate > these? I=E2=80=99ll remove the current 6.4.2 and 6.4.4. I=E2=80=99ll move the = examples for each class to the end of each sub-section. Thanks Max >=20 > -Ekr >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Fri Jul 14 08:58:16 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D60127078 for ; Fri, 14 Jul 2017 08:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 v1sXN7ORRwru for ; Fri, 14 Jul 2017 08:58:13 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E371201F2 for ; Fri, 14 Jul 2017 08:58:13 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id j80so20545520ybg.2 for ; Fri, 14 Jul 2017 08:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pXl2KagbWKkr1K+7qGSyibSDTSoMOMf1pKN+EXeEEHQ=; b=WhlUwKOELIxEiu+NcK+JnXIiD0qDxiQfqd0xUXpXrBZePhARKg0J8g3n3cXF8eVgNR sEgIwGJ0nxXZxfMUL3Y2UShdsmBj4miSCCby4Ml+tZHok+2f9bgfcdyzA9hAnXOHw7KN cIFp5YKsUFLHYruHdkZ4SDkAkTHbgwYjqfRrlBGtpfA5lvamrkOZmSdhmmpclpr/MyYS omCUmQvKWLFGrx191dr/Ht+4myOtSaNSghYJ3XgtkSINOEtL7QBFx1fEgRHN1CEBPV51 n5/FkUtiwoAX59ziImlGOw57EqyuySkgd+4jNcExDCukBZQ3XVBiJ5ITp9ScJ/5PkHqO sQUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pXl2KagbWKkr1K+7qGSyibSDTSoMOMf1pKN+EXeEEHQ=; b=mqoCexI92GuTCsOYctdzrHbnNqc7I+0BnC+dtq/ogHSMluqTjRjfB3AmFVDgUxtaL7 QgqYdSjHBMF0CdAYEAawEzND4MRW9uUJ7n3hakx9KMzU+xWcR4u6Kh1gSBkEi9ZEJaNm f8c4Kjku11ClQ7rBJMJg5WAsCvFk/asn8Un3VVVtd4KKhGPWqHYbhPJ/vD9aSQFfsrD+ WQFovIOGTY7SmJejtRfUIvnUIGA8hbALxsWTlOYuJMN0G/S1bX/u4K9vUmOGbxbWB7fI MvfoQAHu4Ay8ZFWYNgv+SWO1rm7fTqPrEBefWDEa3ROYsSKMuPGBhbZ93EwU2kPSXqbk SO/g== X-Gm-Message-State: AIVw111HKuQnOw2eBSo8sBDHR5iTPOHASBZUBAACOc5byMdbd+Z6oG3F 4pKQYqKTasqdYE+e+BumrMbnzsL++KfqBOY= X-Received: by 10.37.13.145 with SMTP id 139mr7633027ybn.89.1500047892536; Fri, 14 Jul 2017 08:58:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Fri, 14 Jul 2017 08:57:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 14 Jul 2017 08:57:32 -0700 Message-ID: To: Weijun Wang Cc: kitten Content-Type: multipart/alternative; boundary="001a11c00d52c8297f0554491d81" Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 15:58:15 -0000 --001a11c00d52c8297f0554491d81 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang wrote= : > Hi Ekr > > Please read my answers below to your original questions. > > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla wrote: > > > > This document seems generally sound. There are some things about this > > API that confused/surprised me and seem perhaps unwise, but given that > > this is a bis, I will mostly confine my review to mostly calling them > > out and asking you to make sure I understand and that the document is > > clear. > > > > OVERALL > > 1. What is a fatal error? > > The document describes exceptions as indicating "fatal errors". > > What does this mean for the state of the context. For instance, > > if I receive an exception from initSecContext(), does that mean > > that it is no longer possible to initiate it? Your example code > > seems to treat them as fatal for the context. What happens > > if I try to use a context after such an event? > > I=E2=80=99ll add a paragraph in "5.12. Error Reporting=E2=80=9D explaini= ng whether the > context is useable after an exception is thrown, for context establishmen= t > and per-message calls, respectively. Something like > > +If an exception is thrown during context establishment, the context > +negotiation has failed and the GSSContext object must be abandoned. > +If it is thrown in a per-message call, the context can remain useful. > > > > > > > 2. How do I enforce properties for received messages? > > I see that I can request services for context initialization > > (requestConf), and that I can check whether a given message > > was encrypted (getPrivacy) but it's not clear to me if this > > causes the API to enforce these rules for tokens that I > > receive. Is that possible or do I just need to check? > > You would have to check. Even if an established security context already > has its getConfState() being true, one can still wrap a message with > privacy state set to false and the peer will unwrap it with success. If t= he > peer insists only encrypted messages are allowed, she should always check= . > > This is already documented in 6.4.10. > > > > > 3. Are the request* flags() hard limits? E.g., if I do > > requestMutualAuth() do I get it or fail? > > The method does not fail itself (i.e. does not throws an exception) and > you need to check the result with those getXyzState() methods after the > context is established. > > I can add a paragraph in S 5.9, something like: > > +If any retrieved attribute does not match the desired value > +but it is necessary for the application protocol, the application should > +destroy the security context and not use it for application traffic. > +Otherwise, at this point, the context can be used by the application to > +apply cryptographic services to its data. > Sorry, I mean does the handshake fail? Or do you just hace to check. > 4. It's a little unusual to have a structure where you keep > > calling initSecContext or acceptContext() repeatedly. In > > most APIs you would do like "setRole(Server)" or > > "setRoleClient(), and then "Handshake(). > > Sorry but this is how GSS-API works now. > > > > > DETAIL > > S 6.1.16. > > Can addProviderAtFront() be used to add new providers which > > the API would not normally use at all? > > No, 6.1.16 already had > > Only when the indicated provider does not support > the needed mechanism should the GSSManager move on to a different > provider. > > I think this implies that a new provider added might be used at all. > That doesn't seem very clear to me. My point is you might have defaults and then add new omnes. > > EDITORIAL > > S 3.3. > > Please do not use the phrase "cryptographic checksum", I recognize > > that the terminology in this document is idiosyncratic because of > > age, but this isn't really a modern term. Typically > > we would now use "authentication tag" or "integrity tag=E2=80=9D > > GSS-API is still using the Checksum word everywhere (RFC 3961=E2=80=99s t= itle is > =E2=80=9CEncryption and Checksum Specifications for Kerberos 5"). I think= the > cryptographic word is added like we used in cryptographic random number > generator, which means it=E2=80=99s stronger than CRC etc. I would like t= o continue > using this word. > At least add a parenthetical, or som other note, because this is not a term others can understand. > > > S 5.3. > > gss_release_cred() is just eager, right? In any case the data will > > be cleaned up on GC? In any case you should make this clear. > > gss_release_cred() is eager, and there is no other guarantee the data can > be automatically cleaned up. Even if GC cleaned up the GSSCredential > object, there might be unreleased handles underneath. > > S 6.3 already has > > When the credential is no longer needed, the application should call > the dispose (equivalent to gss_release_cred) method to release any > resources held by the credential object and to destroy any > cryptographically sensitive information. > > Do you think it=E2=80=99s necessary to append something like =E2=80=9CAn = implementation > should not rely on garbage control or a finalize() method to dispose a > credential=E2=80=9D? > Yes. > > > S 6.1.15. > > I wouldn't say you are "creating a previously exported context". You > > are either importing it or creating a new context from a previously > > exported one. > > Accepted. > > > > > S 6.2.1. > > > > // export and re-import the name > > byte[] exportName =3D mechName.export(); > > > > // create a new name object from the exported buffer > > GSSName newName =3D mgr.createName(exportName, > > GSSName.NT_EXPORT_NAME); > > > > This comment structure is confusing, because the first is just > > the export. I would change that. > > Accepted. > > > > > > > S 6.2.6. > > It's a bit unclear to me under what circumstances you can compare GSS > > names. I see you can do .equals() and export/memcmp, but can you > > compare strings? Perhaps after you canonicalize them? > > As Ben and I explained this is quite complicated. Can we not touch it in > this bis? The fact that it's complicated seems like more reason to explain it. -Ekr > > > > S 6.3.9. > > Does "union over all mechanisms" mean that if mechanism A supports > > INITIATE and B supports ACCEPT you get =E2=80=9CINITIATE_AND_ACCEPT" > > I=E2=80=99ll add some explanation: > > +Specifically, GSSCredential.INITIATE_AND_ACCEPT(0) should be returned > +as long as there exists one credential element allowing context initiati= on > +and one credential element allowing context acceptance. These two > credential > +elements are not necessarily the same one, nor do they need to use the > +same mechanism(s). > > > > > S 6.4.X > > The presentation order here is weird because you show initSecContext() > > in the 6.4.1. example but then define it in 6.4.3 and then show > > another example that's reduced in 6.4.4. Perhaps you can consolidate > > these? > > I=E2=80=99ll remove the current 6.4.2 and 6.4.4. I=E2=80=99ll move the ex= amples for each > class to the end of each sub-section. > > Thanks > Max > > > > > -Ekr > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > --001a11c00d52c8297f0554491d81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <weijun.wang@oracle.= com> wrote:
Hi Ekr

Please read my answers below to your original questions.

> On Jun 18, 2017, at 2:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> This document seems generally sound. There are some things about this<= br> > API that confused/surprised me and seem perhaps unwise, but given that=
> this is a bis, I will mostly confine my review to mostly calling them<= br> > out and asking you to make sure I understand and that the document is<= br> > clear.
>
> OVERALL
> 1. What is a fatal error?
> The document describes exceptions as indicating "fatal errors&quo= t;.
> What does this mean for the state of the context. For instance,
> if I receive an exception from initSecContext(), does that mean
> that it is no longer possible to initiate it? Your example code
> seems to treat them as fatal for the context. What happens
> if I try to use a context after such an event?

I=E2=80=99ll add a paragraph in "5.12.=C2=A0 Error Reporting=E2= =80=9D explaining whether the context is useable after an exception is thro= wn, for context establishment and per-message calls, respectively. Somethin= g like

+If an exception is thrown during context establishment, the context
+negotiation has failed and the GSSContext object must be abandoned.
+If it is thrown in a per-message call, the context can remain useful.

>
>
> 2. How do I enforce properties for received messages?
> I see that I can request services for context initialization
> (requestConf), and that I can check whether a given message
> was encrypted (getPrivacy) but it's not clear to me if this
> causes the API to enforce these rules for tokens that I
> receive. Is that possible or do I just need to check?

You would have to check. Even if an established security context alr= eady has its getConfState() being true, one can still wrap a message with p= rivacy state set to false and the peer will unwrap it with success. If the = peer insists only encrypted messages are allowed, she should always check.<= br>
This is already documented in 6.4.10.

>
> 3. Are the request* flags() hard limits? E.g., if I do
> requestMutualAuth() do I get it or fail?

The method does not fail itself (i.e. does not throws an exception) = and you need to check the result with those getXyzState() methods after the= context is established.

I can add a paragraph in S 5.9, something like:

+If any retrieved attribute does not match the desired value
+but it is necessary for the application protocol, the application should +destroy the security context and not use it for application traffic.
+Otherwise, at this point, the context can be used by the application to +apply cryptographic services to its data.

<= div>Sorry, I mean does the handshake fail? Or do you just hace to check.=C2= =A0


> 4. It's a little unusual to have a structure where you keep
> calling initSecContext or acceptContext() repeatedly. In
> most APIs you would do like "setRole(Server)" or
> "setRoleClient(), and then "Handshake().

Sorry but this is how GSS-API works now.

>
> DETAIL
> S 6.1.16.
> Can addProviderAtFront() be used to add new providers which
> the API would not normally use at all?

No, 6.1.16 already had

=C2=A0 =C2=A0Only when the indicated provider does not support
=C2=A0 =C2=A0the needed mechanism should the GSSManager move on to a differ= ent
=C2=A0 =C2=A0provider.

I think this implies that a new provider added might be used at all.

That doesn't seem very clear to me. My po= int is you might have defaults and then add new omnes.

=
=C2=A0
> EDITORIAL
> S 3.3.
> Please do not use the phrase "cryptographic checksum", I rec= ognize
> that the terminology in this document is idiosyncratic because of
> age, but this isn't really a modern term. Typically
> we would now use "authentication tag" or "integr= ity tag=E2=80=9D

GSS-API is still using the Checksum word everywhere (RFC 3961=E2=80=99s tit= le is =E2=80=9CEncryption and Checksum Specifications for Kerberos 5")= . I think the cryptographic word is added like we used in cryptographic ran= dom number generator, which means it=E2=80=99s stronger than CRC etc. I wou= ld like to continue using this word.

At= least add a parenthetical, or som other note, because this is not a term o= thers can understand.=C2=A0


>
> S 5.3.
> gss_release_cred() is just eager, right? In any case the data will
> be cleaned up on GC? In any case you should make this clear.

gss_release_cred() is eager, and there is no other guarantee the dat= a can be automatically cleaned up. Even if GC cleaned up the GSSCredential = object, there might be unreleased handles underneath.

S 6.3 already has

=C2=A0 =C2=A0When the credential is no longer needed, the application shoul= d call the dispose (equivalent to gss_release_cred) method to release any r= esources held by the credential object and to destroy any cryptographically= sensitive information.

Do you think it=E2=80=99s necessary to append something like =E2=80=9CAn im= plementation should not rely on garbage control or a finalize() method to d= ispose a credential=E2=80=9D?

Yes.



>
> S 6.1.15.
> I wouldn't say you are "creating a previously exported contex= t". You
> are either importing it or creating a new context from a previously > exported one.

Accepted.

>
> S 6.2.1.
>
>=C2=A0 =C2=A0 // export and re-import the name
>=C2=A0 =C2=A0 byte[] exportName =3D mechName.export();
>
>=C2=A0 =C2=A0 // create a new name object from the exported buffer
>=C2=A0 =C2=A0 GSSName newName =3D mgr.createName(exportName,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 GSSName.NT_EXPORT_NAME);
>
> This comment structure is confusing, because the first is just
> the export. I would change that.

Accepted.

>
>
> S 6.2.6.
> It's a bit unclear to me under what circumstances you can compare = GSS
> names. I see you can do .equals() and export/memcmp, but can you
> compare strings? Perhaps after you canonicalize them?

As Ben and I explained this is quite complicated. Can we not touch i= t in this bis?

The fact that it's compl= icated seems like more reason to explain it.

-Ekr<= /div>


>
> S 6.3.9.
> Does "union over all mechanisms" mean that if mechanism A su= pports
> INITIATE and B supports ACCEPT you get =E2=80=9CINITIATE_AND_ACCEPT&qu= ot;

I=E2=80=99ll add some explanation:

+Specifically, GSSCredential.INITIATE_AND_ACCEPT(0) should be returned=
+as long as there exists one credential element allowing context initiation=
+and one credential element allowing context acceptance. These two credenti= al
+elements are not necessarily the same one, nor do they need to use the
+same mechanism(s).

>
> S 6.4.X
> The presentation order here is weird because you show initSecContext()=
> in the 6.4.1. example but then define it in 6.4.3 and then show
> another example that's reduced in 6.4.4. Perhaps you can consolida= te
> these?

I=E2=80=99ll remove the current 6.4.2 and 6.4.4. I=E2=80=99ll move t= he examples for each class to the end of each sub-section.

Thanks
Max

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


--001a11c00d52c8297f0554491d81-- From nobody Sat Jul 15 06:22:02 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539E113166A for ; Sat, 15 Jul 2017 06:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 q15XbDI5FWnw for ; Sat, 15 Jul 2017 06:22:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 8EB1A127977 for ; Sat, 15 Jul 2017 06:22:00 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6FDLxCW020204 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 15 Jul 2017 13:21:59 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v6FDLxVZ023312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 15 Jul 2017 13:21:59 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v6FDLweD001805; Sat, 15 Jul 2017 13:21:58 GMT Received: from [192.168.1.222] (/125.33.62.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Jul 2017 06:21:58 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Weijun Wang In-Reply-To: Date: Sat, 15 Jul 2017 21:21:48 +0800 Cc: kitten Content-Transfer-Encoding: quoted-printable Message-Id: <53178E51-2EE2-4B50-9FF5-1450DBFF5DA6@oracle.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 13:22:01 -0000 Hi Eric I=E2=80=99ll be vacation for the next 2 weeks and I will work on the = update when I=E2=80=99m back. Thanks Max > On Jul 14, 2017, at 11:57 PM, Eric Rescorla wrote: ...= From nobody Mon Jul 17 17:22:29 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3B131D02 for ; Mon, 17 Jul 2017 17:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 X5xDya_D59mb for ; Mon, 17 Jul 2017 17:22:25 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 8766D131CFC for ; Mon, 17 Jul 2017 17:22:25 -0700 (PDT) X-AuditID: 1209190f-81fff70000001f0c-ad-596d54beed4e 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 37.C3.07948.EB45D695; Mon, 17 Jul 2017 20:22:24 -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 v6I0ML9U002938; Mon, 17 Jul 2017 20:22:22 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6I0MHwi015945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jul 2017 20:22:20 -0400 Date: Mon, 17 Jul 2017 19:22:17 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: Weijun Wang , kitten Message-ID: <20170718002217.GL75962@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hTV1j0Qkhtp0HZQyGLF63PsFkc3r2Kx +Lp0A7MDs8eSJT+ZPD4+vcXiMflxG3MAcxSXTUpqTmZZapG+XQJXxrTba5gK9jlXtKz/ydzA eNyki5GTQ0LAROLzjImMXYxcHEICi5kkTjXeYwZJCAlsZJSY0McMkbjKJHF6/xlWkASLgKrE 2cZHbCA2m4CKREP3ZbAGEQEFiV9/TrCA2MwCThKrZl1hBLGFBRwkti9bDVbDC7Tt8s1Z7BBD TzNKbH5xih0iIShxcuYTqGZ1iT/zLgE1cADZ0hLL/3FAhOUlmrfOBpvDKRAo8Wf5Y7BWUQFl iXn7VrFNYBSchWTSLCSTZiFMmoVk0gJGllWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6 qSmlmxjBoS7Jv4NxToP3IUYBDkYlHl6DfTmRQqyJZcWVuYcYJTmYlER5L7JlRwrxJeWnVGYk FmfEF5XmpBYfYpTgYFYS4b1imhspxJuSWFmVWpQPk5LmYFES5xXXaIwQEkhPLEnNTk0tSC2C ycpwcChJ8P4OBmoULEpNT61Iy8wpQUgzcXCCDOcBGr4WpIa3uCAxtzgzHSJ/ilFRSpy3HiQh AJLIKM2D6wWlIons/TWvGMWBXhHmrQKp4gGmMbjuV0CDmYAGC/vmgAwuSURISTUwxngvstf6 Vbg8N8MhWH/OQ9tr/fYpG9ZKhlq+FvhS3Nq8dMHhhJeuAes+WK1P/7nDtKykMItJ9+xeX3mp nCfcl/gTjxi1n/5/8e/it53GH4Uu3hfZVNgWstmWa82phs1nl9nfZDGbtEAu5a7jRLmMwIcL zm18/15AZTlP2zrF0KN366f7Tl9tr8RSnJFoqMVcVJwIALhbA8EgAwAA Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 00:22:28 -0000 On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote: > On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang wrote: > > > Hi Ekr > > > > Please read my answers below to your original questions. > > > > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla wrote: > > > > > > This document seems generally sound. There are some things about this > > > API that confused/surprised me and seem perhaps unwise, but given that > > > this is a bis, I will mostly confine my review to mostly calling them > > > out and asking you to make sure I understand and that the document is > > > clear. > > > > > > OVERALL > > > 1. What is a fatal error? > > > The document describes exceptions as indicating "fatal errors". > > > What does this mean for the state of the context. For instance, > > > if I receive an exception from initSecContext(), does that mean > > > that it is no longer possible to initiate it? Your example code > > > seems to treat them as fatal for the context. What happens > > > if I try to use a context after such an event? > > > > I’ll add a paragraph in "5.12. Error Reporting” explaining whether the > > context is useable after an exception is thrown, for context establishment > > and per-message calls, respectively. Something like > > > > +If an exception is thrown during context establishment, the context > > +negotiation has failed and the GSSContext object must be abandoned. > > +If it is thrown in a per-message call, the context can remain useful. > > > > > > > > > > > 2. How do I enforce properties for received messages? > > > I see that I can request services for context initialization > > > (requestConf), and that I can check whether a given message > > > was encrypted (getPrivacy) but it's not clear to me if this > > > causes the API to enforce these rules for tokens that I > > > receive. Is that possible or do I just need to check? > > > > You would have to check. Even if an established security context already > > has its getConfState() being true, one can still wrap a message with > > privacy state set to false and the peer will unwrap it with success. If the > > peer insists only encrypted messages are allowed, she should always check. > > > > This is already documented in 6.4.10. > > > > > > > > 3. Are the request* flags() hard limits? E.g., if I do > > > requestMutualAuth() do I get it or fail? > > > > The method does not fail itself (i.e. does not throws an exception) and > > you need to check the result with those getXyzState() methods after the > > context is established. > > > > I can add a paragraph in S 5.9, something like: > > > > +If any retrieved attribute does not match the desired value > > +but it is necessary for the application protocol, the application should > > +destroy the security context and not use it for application traffic. > > +Otherwise, at this point, the context can be used by the application to > > +apply cryptographic services to its data. > > > > Sorry, I mean does the handshake fail? Or do you just hace to check. You have to check. The GSS-API has always been a request-and-check type of API. > > > 4. It's a little unusual to have a structure where you keep > > > calling initSecContext or acceptContext() repeatedly. In > > > most APIs you would do like "setRole(Server)" or > > > "setRoleClient(), and then "Handshake(). > > > > Sorry but this is how GSS-API works now. > > > > > > > > DETAIL > > > S 6.1.16. > > > Can addProviderAtFront() be used to add new providers which > > > the API would not normally use at all? > > > > No, 6.1.16 already had > > > > Only when the indicated provider does not support > > the needed mechanism should the GSSManager move on to a different > > provider. > > > > I think this implies that a new provider added might be used at all. > > > > That doesn't seem very clear to me. My point is you might have defaults and > then add new omnes. I think you could use this to slot in your custom provider that was not part of the system Java implementation, yes. But I don't interact with the Java GSS stuff very much. > > > EDITORIAL > > > S 3.3. > > > Please do not use the phrase "cryptographic checksum", I recognize > > > that the terminology in this document is idiosyncratic because of > > > age, but this isn't really a modern term. Typically > > > we would now use "authentication tag" or "integrity tag” > > > > GSS-API is still using the Checksum word everywhere (RFC 3961’s title is > > “Encryption and Checksum Specifications for Kerberos 5"). I think the > > cryptographic word is added like we used in cryptographic random number > > generator, which means it’s stronger than CRC etc. I would like to continue > > using this word. > > > > At least add a parenthetical, or som other note, because this is not a term > others can understand. I agree; it's probably worth putting in a "(authentication tag)" parenthetical. (The parallel to a Kerberos Checksum remains only a parallel, as Kerberos is only one of many GSS mechanisms.) > > > S 5.3. > > > gss_release_cred() is just eager, right? In any case the data will > > > be cleaned up on GC? In any case you should make this clear. > > > > gss_release_cred() is eager, and there is no other guarantee the data can > > be automatically cleaned up. Even if GC cleaned up the GSSCredential > > object, there might be unreleased handles underneath. > > > > S 6.3 already has > > > > When the credential is no longer needed, the application should call > > the dispose (equivalent to gss_release_cred) method to release any > > resources held by the credential object and to destroy any > > cryptographically sensitive information. > > > > Do you think it’s necessary to append something like “An implementation > > should not rely on garbage control or a finalize() method to dispose a > > credential”? > > > > Yes. > > > > > > > > S 6.1.15. > > > I wouldn't say you are "creating a previously exported context". You > > > are either importing it or creating a new context from a previously > > > exported one. > > > > Accepted. > > > > > > > > S 6.2.1. > > > > > > // export and re-import the name > > > byte[] exportName = mechName.export(); > > > > > > // create a new name object from the exported buffer > > > GSSName newName = mgr.createName(exportName, > > > GSSName.NT_EXPORT_NAME); > > > > > > This comment structure is confusing, because the first is just > > > the export. I would change that. > > > > Accepted. > > > > > > > > > > > S 6.2.6. > > > It's a bit unclear to me under what circumstances you can compare GSS > > > names. I see you can do .equals() and export/memcmp, but can you > > > compare strings? Perhaps after you canonicalize them? > > > > As Ben and I explained this is quite complicated. Can we not touch it in > > this bis? > > > The fact that it's complicated seems like more reason to explain it. In some sense, you can always compare GSS names (in that the compare-name function will not throw an exception), but the results may not always match the expected behavior. (It's too bad that RFC 6680 didn't take the time to summarize the state of affairs when adding naming extensions.) I don't think we should try to provide a comprehensive review of the state of affairs in this document, nor any normative statements (that would only apply to implementations of the Java bindings whereas the issues apply to all GSS-API implementations). But perhaps something like the following would be reasonable: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% A full treatment of the behavior of GSS name comparison is outside the scope of this work. However, applications should note that to avoid surpising behavior, it is best to ensure that the names being compared are either both mechanism names for the same mechanism, or both internal names that are not mechanism names. This holds whether the .equals() method is used directly, or the .export() method is used to generate byte strings that are then compared byte-by-byte. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I considered adding a note that using .toString() and strcmp is not recommended, but I do not think there is a non-normative statement to be made that still provides value, and the lack of mention in the text supplys a small disincentive to do so. -Ben From nobody Mon Jul 24 22:04:54 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5AA126BF3 for ; Mon, 24 Jul 2017 22:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 9nilkgkf3N0b for ; Mon, 24 Jul 2017 22:04:50 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92628126B7E for ; Mon, 24 Jul 2017 22:04:50 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l82so4056093ywc.2 for ; Mon, 24 Jul 2017 22:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rZxfidnbI0jXrVBFfzevqLbiua9uSnBR4cecLxZIqHQ=; b=d7+4lQbbOqIn6mkm3XVw1iH4FCNE5cvbabO8hGC73RGGF4Rpn8PkuSiZxZ7ltpf++w RnSYo5AM6SMjNz0YdQxBczu36q5Bsr1b+lC9sGlerPIE/ofzAfCFoiw98W+VVYwVG4Sp MarK6MS+v4BAu4KRZVS+h4UoxvIGhqnn6BkHNEyWRhk2VcCGRfwgxAxNbuEgF+9sqXvl y/dAhV7HBdx1kfLTp3nVlFJ9mhIFd+uYo/qo040YyPkw2lJxzNTIw1Oy8KNlVIUveRqD rX2O/8IxYTBwpAQiwYxJau6rU+Sb5FfWr/nl4nwS7UcZOKPuDdPhUHUnnCfuQXh4L8dM ISJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rZxfidnbI0jXrVBFfzevqLbiua9uSnBR4cecLxZIqHQ=; b=d80SEItXb+5Nh5IOrFLgFsGgwzP5GKXa7zsQXBWV2URh7on+84vmrX5lPCVWsFxR5R 7Cm6MRgSqnOrX7d6jMclbi971NY6u8Bn3Q733T9bt6AdjKI+uVr1TgJYjtrPTKMQokSe V0+HLcxbO+FyOhoHuXv4gF7xxlhn1F/O+JroMSeYj9tm91u8qruwG5R0wpN1eFhyao04 kWFPdfXCYSvRh/2RT+EGZKcRndElV861ukmEnFIdA6jpOTT3wf9YdjofOasZuDhhe3Md gQyHhaPMBjk54udaYWjYb7BBlDwh3jFPg/O6VO9AmHQzxIjE+mnGO44PP99INjlFwvmp rv6A== X-Gm-Message-State: AIVw110FoSkMdi4T9he6BfM8Y9C1UPwpq+2yKPdCfEKs0ixypEk9+KZ2 oifqY78RoUUFWGIIzrYxdkEAuKv4LKu/ X-Received: by 10.129.70.132 with SMTP id t126mr14973411ywa.270.1500959089837; Mon, 24 Jul 2017 22:04:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Mon, 24 Jul 2017 22:04:09 -0700 (PDT) In-Reply-To: <20170718002217.GL75962@kduck.kaduk.org> References: <20170718002217.GL75962@kduck.kaduk.org> From: Eric Rescorla Date: Mon, 24 Jul 2017 22:04:09 -0700 Message-ID: To: Benjamin Kaduk Cc: Weijun Wang , kitten Content-Type: multipart/alternative; boundary="001a11484e9e5f87e105551d4500" Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 05:04:53 -0000 --001a11484e9e5f87e105551d4500 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2017 at 5:22 PM, Benjamin Kaduk wrote: > On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote: > > On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang > wrote: > > > > > Hi Ekr > > > > > > Please read my answers below to your original questions. > > > > > > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla wrote: > > > > > > > > This document seems generally sound. There are some things about th= is > > > > API that confused/surprised me and seem perhaps unwise, but given > that > > > > this is a bis, I will mostly confine my review to mostly calling th= em > > > > out and asking you to make sure I understand and that the document = is > > > > clear. > > > > > > > > OVERALL > > > > 1. What is a fatal error? > > > > The document describes exceptions as indicating "fatal errors". > > > > What does this mean for the state of the context. For instance, > > > > if I receive an exception from initSecContext(), does that mean > > > > that it is no longer possible to initiate it? Your example code > > > > seems to treat them as fatal for the context. What happens > > > > if I try to use a context after such an event? > > > > > > I=E2=80=99ll add a paragraph in "5.12. Error Reporting=E2=80=9D expl= aining whether the > > > context is useable after an exception is thrown, for context > establishment > > > and per-message calls, respectively. Something like > > > > > > +If an exception is thrown during context establishment, the context > > > +negotiation has failed and the GSSContext object must be abandoned. > > > +If it is thrown in a per-message call, the context can remain useful= . > > > > > > > > > > > > > > > 2. How do I enforce properties for received messages? > > > > I see that I can request services for context initialization > > > > (requestConf), and that I can check whether a given message > > > > was encrypted (getPrivacy) but it's not clear to me if this > > > > causes the API to enforce these rules for tokens that I > > > > receive. Is that possible or do I just need to check? > > > > > > You would have to check. Even if an established security context > already > > > has its getConfState() being true, one can still wrap a message with > > > privacy state set to false and the peer will unwrap it with success. > If the > > > peer insists only encrypted messages are allowed, she should always > check. > > > > > > This is already documented in 6.4.10. > > > > > > > > > > > 3. Are the request* flags() hard limits? E.g., if I do > > > > requestMutualAuth() do I get it or fail? > > > > > > The method does not fail itself (i.e. does not throws an exception) a= nd > > > you need to check the result with those getXyzState() methods after t= he > > > context is established. > > > > > > I can add a paragraph in S 5.9, something like: > > > > > > +If any retrieved attribute does not match the desired value > > > +but it is necessary for the application protocol, the application > should > > > +destroy the security context and not use it for application traffic. > > > +Otherwise, at this point, the context can be used by the application > to > > > +apply cryptographic services to its data. > > > > > > > Sorry, I mean does the handshake fail? Or do you just hace to check. > > You have to check. The GSS-API has always been a request-and-check > type of API. > OK. I think that should be explicitly stated. > > > > > > 4. It's a little unusual to have a structure where you keep > > > > calling initSecContext or acceptContext() repeatedly. In > > > > most APIs you would do like "setRole(Server)" or > > > > "setRoleClient(), and then "Handshake(). > > > > > > Sorry but this is how GSS-API works now. > > > > > > > > > > > DETAIL > > > > S 6.1.16. > > > > Can addProviderAtFront() be used to add new providers which > > > > the API would not normally use at all? > > > > > > No, 6.1.16 already had > > > > > > Only when the indicated provider does not support > > > the needed mechanism should the GSSManager move on to a different > > > provider. > > > > > > I think this implies that a new provider added might be used at all. > > > > > > > That doesn't seem very clear to me. My point is you might have defaults > and > > then add new omnes. > > I think you could use this to slot in your custom provider that was not > part of the system Java implementation, yes. > But I don't interact with the Java GSS stuff very much. > OK. This also needs to be explicit. > > > S 5.3. > > > > gss_release_cred() is just eager, right? In any case the data will > > > > be cleaned up on GC? In any case you should make this clear. > > > > > > gss_release_cred() is eager, and there is no other guarantee the data > can > > > be automatically cleaned up. Even if GC cleaned up the GSSCredential > > > object, there might be unreleased handles underneath. > > > > > > S 6.3 already has > > > > > > When the credential is no longer needed, the application should ca= ll > > > the dispose (equivalent to gss_release_cred) method to release any > > > resources held by the credential object and to destroy any > > > cryptographically sensitive information. > > > > > > Do you think it=E2=80=99s necessary to append something like =E2=80= =9CAn implementation > > > should not rely on garbage control or a finalize() method to dispose = a > > > credential=E2=80=9D? > > > > > > > Yes. > > > > > > > > > > > > > S 6.1.15. > > > > I wouldn't say you are "creating a previously exported context". Yo= u > > > > are either importing it or creating a new context from a previously > > > > exported one. > > > > > > Accepted. > > > > > > > > > > > S 6.2.1. > > > > > > > > // export and re-import the name > > > > byte[] exportName =3D mechName.export(); > > > > > > > > // create a new name object from the exported buffer > > > > GSSName newName =3D mgr.createName(exportName, > > > > GSSName.NT_EXPORT_NAME); > > > > > > > > This comment structure is confusing, because the first is just > > > > the export. I would change that. > > > > > > Accepted. > > > > > > > > > > > > > > > S 6.2.6. > > > > It's a bit unclear to me under what circumstances you can compare G= SS > > > > names. I see you can do .equals() and export/memcmp, but can you > > > > compare strings? Perhaps after you canonicalize them? > > > > > > As Ben and I explained this is quite complicated. Can we not touch it > in > > > this bis? > > > > > > The fact that it's complicated seems like more reason to explain it. > > In some sense, you can always compare GSS names (in that the compare-name > function will not throw an exception), but the results may not always > match the expected behavior. (It's too bad that RFC 6680 didn't take the > time to summarize the state of affairs when adding naming extensions.) > I don't think we should try to provide a comprehensive review of the > state of affairs in this document, nor any normative statements (that wou= ld > only apply to implementations of the Java bindings whereas the issues > apply to all GSS-API implementations). But perhaps something like the > following would be reasonable: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > A full treatment of the behavior of GSS name comparison is outside the > scope of this work. However, applications should note that to avoid > surpising behavior, it is best to ensure that the names being compared > are either both mechanism names for the same mechanism, or both internal > names that are not mechanism names. This holds whether the .equals() > method is used directly, or the .export() method is used to generate byte > strings that are then compared byte-by-byte. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Yes, this seems fine. -Ekr --001a11484e9e5f87e105551d4500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 17, 2017 at 5:22 PM, Benjamin Kaduk <<= a href=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu> wrote:
On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote: > On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <weijun.wang@oracle.com> wrote:
>
> > Hi Ekr
> >
> > Please read my answers below to your original questions.
> >
> > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > This document seems generally sound. There are some things a= bout this
> > > API that confused/surprised me and seem perhaps unwise, but = given that
> > > this is a bis, I will mostly confine my review to mostly cal= ling them
> > > out and asking you to make sure I understand and that the do= cument is
> > > clear.
> > >
> > > OVERALL
> > > 1. What is a fatal error?
> > > The document describes exceptions as indicating "fatal = errors".
> > > What does this mean for the state of the context. For instan= ce,
> > > if I receive an exception from initSecContext(), does that m= ean
> > > that it is no longer possible to initiate it? Your example c= ode
> > > seems to treat them as fatal for the context. What happens > > > if I try to use a context after such an event?
> >
> > I=E2=80=99ll add a paragraph in "5.12.=C2=A0 Error Reporting= =E2=80=9D explaining whether the
> > context is useable after an exception is thrown, for context esta= blishment
> > and per-message calls, respectively. Something like
> >
> > +If an exception is thrown during context establishment, the cont= ext
> > +negotiation has failed and the GSSContext object must be abandon= ed.
> > +If it is thrown in a per-message call, the context can remain us= eful.
> >
> > >
> > >
> > > 2. How do I enforce properties for received messages?
> > > I see that I can request services for context initialization=
> > > (requestConf), and that I can check whether a given message<= br> > > > was encrypted (getPrivacy) but it's not clear to me if t= his
> > > causes the API to enforce these rules for tokens that I
> > > receive. Is that possible or do I just need to check?
> >
> > You would have to check. Even if an established security context = already
> > has its getConfState() being true, one can still wrap a message w= ith
> > privacy state set to false and the peer will unwrap it with succe= ss. If the
> > peer insists only encrypted messages are allowed, she should alwa= ys check.
> >
> > This is already documented in 6.4.10.
> >
> > >
> > > 3. Are the request* flags() hard limits? E.g., if I do
> > > requestMutualAuth() do I get it or fail?
> >
> > The method does not fail itself (i.e. does not throws an exceptio= n) and
> > you need to check the result with those getXyzState() methods aft= er the
> > context is established.
> >
> > I can add a paragraph in S 5.9, something like:
> >
> > +If any retrieved attribute does not match the desired value
> > +but it is necessary for the application protocol, the applicatio= n should
> > +destroy the security context and not use it for application traf= fic.
> > +Otherwise, at this point, the context can be used by the applica= tion to
> > +apply cryptographic services to its data.
> >
>
> Sorry, I mean does the handshake fail? Or do you just hace to check.
You have to check.=C2=A0 The GSS-API has always been a request-= and-check
type of API.

OK. I think that should be= explicitly stated.
=C2=A0

>
> > 4. It's a little unusual to have a structure where you keep > > > calling initSecContext or acceptContext() repeatedly. In
> > > most APIs you would do like "setRole(Server)" or > > > "setRoleClient(), and then "Handshake().
> >
> > Sorry but this is how GSS-API works now.
> >
> > >
> > > DETAIL
> > > S 6.1.16.
> > > Can addProviderAtFront() be used to add new providers which<= br> > > > the API would not normally use at all?
> >
> > No, 6.1.16 already had
> >
> >=C2=A0 =C2=A0 Only when the indicated provider does not support > >=C2=A0 =C2=A0 the needed mechanism should the GSSManager move on t= o a different
> >=C2=A0 =C2=A0 provider.
> >
> > I think this implies that a new provider added might be used at a= ll.
> >
>
> That doesn't seem very clear to me. My point is you might have def= aults and
> then add new omnes.

I think you could use this to slot in your custom provider that was = not
part of the system Java implementation, yes.
But I don't interact with the Java GSS stuff very much.

OK. This also needs to be explicit.=C2=A0

> > > S 5.3.
> > > gss_release_cred() is just eager, right? In any case the dat= a will
> > > be cleaned up on GC? In any case you should make this clear.=
> >
> > gss_release_cred() is eager, and there is no other guarantee the = data can
> > be automatically cleaned up. Even if GC cleaned up the GSSCredent= ial
> > object, there might be unreleased handles underneath.
> >
> > S 6.3 already has
> >
> >=C2=A0 =C2=A0 When the credential is no longer needed, the applica= tion should call
> > the dispose (equivalent to gss_release_cred) method to release an= y
> > resources held by the credential object and to destroy any
> > cryptographically sensitive information.
> >
> > Do you think it=E2=80=99s necessary to append something like =E2= =80=9CAn implementation
> > should not rely on garbage control or a finalize() method to disp= ose a
> > credential=E2=80=9D?
> >
>
> Yes.
>
>
>
> >
> > > S 6.1.15.
> > > I wouldn't say you are "creating a previously expor= ted context". You
> > > are either importing it or creating a new context from a pre= viously
> > > exported one.
> >
> > Accepted.
> >
> > >
> > > S 6.2.1.
> > >
> > >=C2=A0 =C2=A0 // export and re-import the name
> > >=C2=A0 =C2=A0 byte[] exportName =3D mechName.export();
> > >
> > >=C2=A0 =C2=A0 // create a new name object from the exported b= uffer
> > >=C2=A0 =C2=A0 GSSName newName =3D mgr.createName(exportName,<= br> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 GSSName.NT_EXPORT_NAME);
> > >
> > > This comment structure is confusing, because the first is ju= st
> > > the export. I would change that.
> >
> > Accepted.
> >
> > >
> > >
> > > S 6.2.6.
> > > It's a bit unclear to me under what circumstances you ca= n compare GSS
> > > names. I see you can do .equals() and export/memcmp, but can= you
> > > compare strings? Perhaps after you canonicalize them?
> >
> > As Ben and I explained this is quite complicated. Can we not touc= h it in
> > this bis?
>
>
> The fact that it's complicated seems like more reason to explain i= t.

In some sense, you can always compare GSS names (in that the co= mpare-name
function will not throw an exception), but the results may not always
match the expected behavior.=C2=A0 (It's too bad that RFC 6680 didn'= ;t take the
time to summarize the state of affairs when adding naming extensions.)
I don't think we should try to provide a comprehensive review of the state of affairs in this document, nor any normative statements (that would=
only apply to implementations of the Java bindings whereas the issues
apply to all GSS-API implementations).=C2=A0 But perhaps something like the=
following would be reasonable:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%

A full treatment of the behavior of GSS name comparison is outside the
scope of this work.=C2=A0 However, applications should note that to avoid surpising behavior, it is best to ensure that the names being compared
are either both mechanism names for the same mechanism, or both internal names that are not mechanism names.=C2=A0 This holds whether the .equals()<= br> method is used directly, or the .export() method is used to generate byte strings that are then compared byte-by-byte.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%

Yes, this seems fine.

-Ekr

--001a11484e9e5f87e105551d4500-- From nobody Tue Jul 25 18:11:52 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757F3132199 for ; Tue, 25 Jul 2017 18:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 H9yXEBe2kcwc for ; Tue, 25 Jul 2017 18:11:49 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 34D71124B0A for ; Tue, 25 Jul 2017 18:11:49 -0700 (PDT) X-AuditID: 1209190c-259ff70000006c08-e5-5977ec51559b 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 A4.54.27656.15CE7795; Tue, 25 Jul 2017 21:11:48 -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 v6Q1BiK2019588; Tue, 25 Jul 2017 21:11:44 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6Q1BeCP026888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jul 2017 21:11:43 -0400 Date: Tue, 25 Jul 2017 20:11:40 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: Weijun Wang , kitten Message-ID: <20170726011140.GD58771@kduck.kaduk.org> References: <20170718002217.GL75962@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT1w15Ux5p8L+b02LF63PsFkc3r2Kx +Lp0A7MDs8eSJT+ZPD4+vcXiMflxG3MAcxSXTUpqTmZZapG+XQJXxtyfc9kLAirmNv1naWC0 7WLk5JAQMJFYfuYDexcjF4eQwGImicbF31ghnI2MEpf7zrNBOFeZJG5MWssG0sIioCpx99EP VhCbTUBFoqH7MjOILSKgIPHrzwkWEJtZwEli1awrjCC2sICDxPZlq8FqeIHWPd+2iBli6F4m iQ+zLjJBJAQlTs58AtWsJXHj30ugOAeQLS2x/B8HSJhTIFBi8v42sJmiAsoS8/atYpvAKDAL SfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECApcTkmeHYxn 3ngdYhTgYFTi4b3hXh4pxJpYVlyZe4hRkoNJSZTX/ChQiC8pP6UyI7E4I76oNCe1+BCjBAez kghvz2mgHG9KYmVValE+TEqag0VJnFdCozFCSCA9sSQ1OzW1ILUIJivDwaEkwTvxNVCjYFFq empFWmZOCUKaiYMTZDgP0HA9kBre4oLE3OLMdIj8KUZLjnn/1nxh4vjwH0Q2fdjyhUmIJS8/ L1VKnHcCSIMASENGaR7cTFAiksjeX/OKURzoRWHeF6+AqniASQxu6iughUxAC+fMKAVZWJKI kJJqYGSsYvqwv+qyvMZF7qu/zu+9ZnHSMWGXFIPB99+VfUsNf5jtYJpb4V3D+/DxxXCR7RuT jxfM+bTPd9HO3Sv8ld9oXbxdGhmvvfDemd6D248IFLuFbFlyueTdo+9lnyw3KSxOLOmW3MLl OblwkumMnKIz012ae95MqS91bbkfuMHz8pXF1VLCrrZKLMUZiYZazEXFiQD6ZHWiHwMAAA== Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 01:11:50 -0000 I set a calendar reminder to ping Max when he gets back from vacation. -Ben From nobody Wed Jul 26 14:41:20 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976DF131CFF for ; Wed, 26 Jul 2017 14:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 X8o9eQ2wU6lY for ; Wed, 26 Jul 2017 14:41:18 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 5664A131D06 for ; Wed, 26 Jul 2017 14:41:16 -0700 (PDT) X-AuditID: 12074423-bafff70000001f67-1b-59790c7a19b2 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 03.B3.08039.A7C09795; Wed, 26 Jul 2017 17:41:15 -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 v6QLfDGx019697 for ; Wed, 26 Jul 2017 17:41:14 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6QLfAdL022228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Jul 2017 17:41:13 -0400 Date: Wed, 26 Jul 2017 16:41:10 -0500 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170726214110.GF58771@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixCmqrVvNUxlpcGGysMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbXvGnNBG0vF7lNL2RoY1zB3MXJySAiYSByfc52li5GLQ0hg MZPEjFXzmSGc44wS27b8Y4dwXjNJtB+8wAbSwiKgKtE+dwUTiM0moCLR0H0ZbJSIgLDE7q3v wGxhAWmJt6u2M4LYvEArLn46zwRhC0qcnPmEBcRmFtCSuPHvJVCcA8iWllj+jwMkLCqgLDFv 3yq2CYy8s5B0zELSMQuhYwEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdM73czBK91JTSTYyg UGJ3Ud7B+LLP+xCjAAejEg/viikVkUKsiWXFlbmHGCU5mJREeSeZAoX4kvJTKjMSizPii0pz UosPMUpwMCuJ8OazV0YK8aYkVlalFuXDpKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoS vN+5gBoFi1LTUyvSMnNKENJMHJwgw3mAhveC1PAWFyTmFmemQ+RPMepyNH3Y8oVJiCUvPy9V Spz3FkiRAEhRRmke3BxQCpDI3l/zilEc6C1h3jRuoCoeYPqAm/QKaAkT0JI5M0pBlpQkIqSk GhiLn18r5J4gsiEtpclIeOfeRSuYVNa82PbGjIvJaeZWj7i9+Zpfz+75sLXnucCHtSf3flPJ 8jn36L/vpwjrP8zdvt39PYJm2iKlfav8bpWutly08crkkPVPuetYfmx8nPznacOHqQt0brEp nH55cf2d4xZlC2LdXvmWdmyJWCS61IRno/D1/uxQJZbijERDLeai4kQA2H53O9wCAAA= Archived-At: Subject: [kitten] current work items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 21:41:20 -0000 Hi all, While we're waiting for an updated version of draft-ietf-kitten-channel-bound-flag, I'd like to remind people that we're also trying to finish up draft-ietf-kitten-krb-spake-preauth. Though the individual version of that draft received a substantial amount of interest and review, draft-ietf-kitten-krb-spake-preauth-00 has not gotten any comments. We need to get a few explicti reviews in before we can start making claims about WG consensus and moving the document to the IESG. Thanks, Ben From nobody Wed Jul 26 20:58:06 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE65E129ADA for ; Wed, 26 Jul 2017 20:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OZz7p-DSx4O2 for ; Wed, 26 Jul 2017 20:58:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 C39FB128B8D for ; Wed, 26 Jul 2017 20:58:03 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6R3w2iU007150 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jul 2017 03:58:03 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6R3w2KV008321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jul 2017 03:58:02 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6R3w2Jq028583; Thu, 27 Jul 2017 03:58:02 GMT Received: from [192.168.1.77] (/50.92.225.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Jul 2017 20:58:01 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Wang Weijun X-Mailer: iPad Mail (14F89) In-Reply-To: <20170726011140.GD58771@kduck.kaduk.org> Date: Wed, 26 Jul 2017 20:58:00 -0700 Cc: Eric Rescorla , kitten Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170718002217.GL75962@kduck.kaduk.org> <20170726011140.GD58771@kduck.kaduk.org> To: Benjamin Kaduk X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 03:58:05 -0000 Hi Ben That's very kind of you. I'm still on vacation but I've flagged this mail th= read and will work on it as soon as I'm back. Thanks Max > On Jul 25, 2017, at 18:11, Benjamin Kaduk wrote: >=20 > I set a calendar reminder to ping Max when he gets back from vacation. >=20 > -Ben