From kaduk@mit.edu Fri Nov 1 08:35:31 2013 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 BB05821E8279 for ; Fri, 1 Nov 2013 08:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDPXZ277hBAl for ; Fri, 1 Nov 2013 08:35:25 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFB821E821A for ; Fri, 1 Nov 2013 08:35:21 -0700 (PDT) X-AuditID: 12074422-b7f5a8e000000a34-bf-5273ca38cc2b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 93.8B.02612.83AC3725; Fri, 1 Nov 2013 11:35:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id rA1FZJ3t014022; Fri, 1 Nov 2013 11:35:19 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA1FZHBo024680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Nov 2013 11:35:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rA1FZGqU025904; Fri, 1 Nov 2013 11:35:16 -0400 (EDT) Date: Fri, 1 Nov 2013 11:35:16 -0400 (EDT) From: Benjamin Kaduk To: Michiko Short In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-2052780066-1383319024=:4934" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsUixG6nrmtxqjjI4OkLJYu5W3vYLY5uXsVi 8a+bz+L0refMDiweS5b8ZPJo3fGX3eNtw1X2AOYoLpuU1JzMstQifbsEroy+a9tZC67oVXTe 6mVrYHyj2sXIySEhYCLxf+IOFghbTOLCvfVsXYxcHEIC+xgl/ux4wgLhbGCUmNE6jx3COcgk sfDxEaAyDiCnXqJzUhVIN4uAlsSjjaeYQGw2ARWJmW82soHYIkDxDxdOg21gFqiTaF42lRHE FhaIlGia+IgdxOYU0JF4O/88WD2vgIPEos6VYPVCAtoSq2btBouLAtWs3j+FBaJGUOLkzCdQ MwMkVi79wwxhO0is+DKNaQKj0CwkZbOQlM1CUgZhW0vsu/WKEcLWlrh/s40NpmbH1DeMCxjZ VjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRuYgRHj4vSDsafB5UOMQpwMCrx8DpM LAoSYk0sK67MPcQoycGkJMp79khxkBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3pbNQDnelMTK qtSifJiUNAeLkjjvLQ77ICGB9MSS1OzU1ILUIpisDAeHkgSv50mgRsGi1PTUirTMnBKENBMH J8hwHqDhsiA1vMUFibnFmekQ+VOMilLivNIgCQGQREZpHlwvLLm9YhQHekWYNxKkigeYGOG6 XwENZgIazCpXBDK4JBEhJdXAKNCjPcUvONCF1/bK3+O59jelzQPaD1QY8qv7fWHofFkma1e0 XdVm0QqP25aH/fXce1O9d8ponO3feZG1XvT3hqSVdQaNkz+845qQff7qh186xYUcget3arn+ 4l0662lz8HUNY62tB55PqjscOE9DbVlvYsPcx3cfdC6+P8v3h9mv6qmqac6TlViKMxINtZiL ihMBZdo2H0kDAAA= Cc: "kitten@ietf.org" , Anoosh Saboori Subject: Re: [kitten] Request for summary of issues with existing AES-CTS with new SHA2 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:35:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-2052780066-1383319024=:4934 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Michiko, On Wed, 30 Oct 2013, Peck, Michael A wrote: > Michiko, > > First, regarding the CTS vs. CBC with PKCS#7 padding question, we the doc= ument editors are of course happy to go along with whatever consensus the w= orking group comes to. > Our latest CTS-based draft is at: http://tools.ietf.org/html/draft-ietf-k= itten-aes-cts-hmac-sha2-01 > Our latest CBC with PKCS#7 padding draft is at: http://tools.ietf.org/htm= l/draft-ietf-kitten-aes-cbc-hmac-sha2-00 > > In the Introduction of both drafts we have a section describing the diffe= rences between them and the existing Kerberos AES specification (RFC 3961/3= 962). > Our goal was to update to SHA2 and also follow current best cryptographic= practices. > For example, unlike RFC3961 we follow the current best practice of Encryp= t-then-MAC. > For CTS, we use the definition in the NIST Special Publication 800-38A Ad= dendum, which uses an explicit IV instead of a confounder. > Unfortunately the NIST definition doesn=A2t deal with plaintext lengths e= qual to or less than the AES block size, so we added text in Section 5 to c= over that situation for completeness, even if it might never happen in real= ity. > > The CTS draft states: > > * The pseudorandom function used by PBKDF2 is HMAC-SHA-256 or HMAC- > SHA-384. > > * A key derivation function from [SP800-108] which uses the SHA-= 256 > or SHA-384 hash algorithm is used to produce keys for encryption, > integrity protection, and checksum operations. > > * The IV used during content encryption is sent as part of the > ciphertext, instead of using a confounder. This saves one > encryption and decryption operation per message. > > * The HMAC is calculated over the AES output, instead of being > calculated over the plaintext. This allows the message receiver > to verify the integrity of the message before decrypting the > message. > > * The HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm for > integrity protection and checksum operations. As Michael notes, a goal for the new enctypes was to bring us into line=20 with current cryptographic best practices, with the two most relevant=20 practices being CBC mode and the use of an explicit initialization vector= =20 (instead of the random confounder used in the previous kerberos encryption= =20 types). I believe that Paul's clarifications about the potential issues have=20 brought about a general sentiment in the working group that the CBC mode=20 (with explicit padding) is too risky to introduce at present. That leaves= =20 only the IV versus confounder question, which is the source of the issues= =20 with CTS mode. With CTS mode such as in NIST SP-800-38A (2010 appendum), the input=20 plaintext is required to be at least a complete block long. This is the=20 source of our long discussions and the reason why many people were pushing= =20 for CBC mode -- we would need to specify some one-off solution for what to= =20 do with short plaintexts (as an RFC 3961 enctype does not place=20 restrictions on the length of the plaintext input to the encryption=20 operation), and the solutions being propsed were getting rather=20 complicated. Having two completely different algorithms for the=20 encryption procedure, only one of which is commonly used, seems to be=20 asking for trouble. The draft-ietf-kitten-aes-cts-hmac-sha2-01 linked=20 above has a conditional on (L(P) > c) in the encryption function, for=20 an example of the "completely different algorithms". There has also been the question raised of whether sending an explicit IV= =20 has risks of its own (namely, exposing state of the random number=20 generator) and should actually be best current practice. I don't believe= =20 that there is consensus on the list on this question, and speaking for=20 myself, I'm not convinced that this list is the right place to settle such= =20 a question. If we did abandon the idea of sending an explicit IV and go=20 back to the existing practice of using a random confounder, then the=20 plaintext input to the cipher mode will always have a confounder and thus= =20 always be at least a block in length, eliminating the need for a separate= =20 "short plaintext" case in the encryption/decryption routines. We as a group must weigh the tradeoff between following cryptographic=20 best practice and ease of implementation, taking into account the other=20 issues that have been raised. Speaking just for myself, while Paul's description of why padded ciphers=20 might cause trouble for applications is convincing enough that I agree we= =20 should not intorduce new enctypes with padding now, I do feel that we=20 should try to give ourselves the option of adding it at some future time.= =20 It would really be a shame if we found ourselves locked into some practice= =20 from N years ago and could never migrate to best practices as a result. I= =20 know that all applications have a depreciation cycle and will eventually=20 stop working as OSes advance, and I would hope that we could use this=20 (slow-paced) cycle to winnow out applications which are unprepared for the= =20 possibility of padding, so that maybe in 10 years we could revisit the=20 question. Alternately, NIST could have a competition for a stream cipher, that would= =20 be good, too. -Ben ---559023410-2052780066-1383319024=:4934-- From kaduk@mit.edu Tue Nov 5 08:29:49 2013 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 5479821F9C68 for ; Tue, 5 Nov 2013 08:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPs764bRHDKS for ; Tue, 5 Nov 2013 08:29:43 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id EF99711E8188 for ; Tue, 5 Nov 2013 08:29:36 -0800 (PST) X-AuditID: 12074425-b7f1c8e0000009c7-a0-52791cf0eff4 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.7F.02503.0FC19725; Tue, 5 Nov 2013 11:29:36 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rA5GTZkJ018865 for ; Tue, 5 Nov 2013 11:29:35 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA5GTXd2022229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 5 Nov 2013 11:29:34 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rA5GTXR7022890; Tue, 5 Nov 2013 11:29:33 -0500 (EST) Date: Tue, 5 Nov 2013 11:29:33 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20131021190003.32574.46426.idtracker@ietfa.amsl.com> Message-ID: References: <20131021190003.32574.46426.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6novtBpjLI4NgsLoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/nSpIJWnYp5EzsZGxhnKncxcnJICJhInF13hh3CFpO4cG89 WxcjF4eQwD5GifXbGqCcY4wSvZPvs0I415kkHn5ezwTSIiRQL7Hu/ww2EJtFQEuia8c1RhCb TUBFYuabjWBxEQFhid1b3zGD2MICjhIrb50B6+UUcJK4sH4WmM0r4CCx6eJqVoiZjhJrW36A zREV0JFYvX8KC0SNoMTJmU/AbGYBS4l/a3+xTmAUmIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk 3eLkxLy81CJdC73czBK91JTSTYzg4HNR3cE44ZDSIUYBDkYlHt4HZ8uDhFgTy4orcw8xSnIw KYnyKklXBgnxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4T32vyJIiDclsbIqtSgfJiXNwaIkznuL wz5ISCA9sSQ1OzW1ILUIJivDwaEkwbsQZKhgUWp6akVaZk4JQpqJgxNkOA/Q8O0gNbzFBYm5 xZnpEPlTjIpS4rxrQRICIImM0jy4XlhyeMUoDvSKMO8ekCoeYGKB634FNJgJaHDCkjKQwSWJ CCmpBkZGB+vlk7vffa+u5t0SOvvKluZfJWtXFaz50XqrKVfwgpVd/qyvjjxv9/xfEWvYIZQk dkK5nm3TtXrbQlYbdzlro8eLI6OrFHsDg7wjFCy3c/dwSSw4LaF/1jiw9ufEP/uXpdyfkj9H u3wto2SG+vNdDBOYnvx5zTbt14EH0495Ke7rmp7lXKPEUpyRaKjFXFScCABHbe+46QIAAA== Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:29:49 -0000 On Mon, 21 Oct 2013, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Kerberos Authorization Data Container Authenticated by Multiple MACs > Author(s) : Simo Sorce > Tom Yu > Thomas Hardjono > Filename : draft-ietf-krb-wg-cammac-06.txt > Pages : 9 > Date : 2013-10-21 > > Abstract: > Abstract: This document specifies a Kerberos Authorization Data > container that supersedes AD-KDC-ISSUED. It allows for multiple > Message Authentication Codes (MACs) or signatures to authenticate the > contained Authorization Data elements. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-06 I think the new text in "Motivations" covers a lot of things that should be covered, but unfortunately it doesn't seem very well structured as a piece of prose. I might propose the following reordering/rewording: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% A Kerberos ticket may frequently contain some extra authorization data in addition to just the client identity and similar necessities. A client may request that certain authorization data be included in its tickets, but sometimes a service may want to verify that the authorization data has been vetted in some way by (or generated by!) the KDC. The existing AD-KDC-ISSUED container suits this purpose well, allowing a service to verify that the KDC had issued the contained authorization data. This is allowed by virtue of the shared symmetric key between the KDC and the service, which is used to copute the MAC for the AD-KDC-ISSUED container. This existing setup works well when the flow of authorization data is always from the KDC to the application service. However, there are extensions to the Kerberos protocol such as Constrianed Delegation (S4U2Proxy [MS-SFU]) which involve having an application service send a ticket (and its concordant authorization data) to the KDC as part of receiving a new ticket for a different service on behalf of the client. The service takes an existing ticket to itself and presents it to the KDC as evidence that it received a user request, and consequently asks the KDC to issue a new ticket on behalf of the same user to perform operations against a different service. This is, in effect, a flow of authorization data from the application service to the KDC, and for this purpose the AD-KDC-ISSUED container is insufficient. This deficiency is precisely due to the fact that the symmetric key used for the MAC is shared between the KDC and the application service -- the application service could use the key to generate a forged MAC on an AD-KDC-ISSUED container which was in fact not issued by the KDC. The new AD-CAMMAC authorization data container specified in this document improves upon the situation by introducing a MAC using a symmetric key known only to the KDC (in the form of the kdc-verifier MAC), in addition to a MAC in a key shared between the KDC and the application service (in the form of the svc-verifier MAC, analogous to the MAC for the AD-KDC-ISSUED container). When an application service presents data in an AD-CAMMAC container to the KDC, the KDC can use the kdc-verifier to validate that the authorization data was in fact issued by the KDC. (Note, however, that just the MAC is insufficient to confirm that the CAMMAC was issued along with the ticket it is attached to, see [Security Considerations].) In this way the KDC can verify that the service named in the ticket did not tamper with the contained authorization data without having to (re)compute all of the contained authorization data, an operation which might not always be possible when the data contains ephemeral information such as the strength or type of authentication method used to obtain the original ticket. In addition to the kdc-verifier and svc-verifier, the AD-CAMMAC also includes a provision for additional other-verifiers. These allow the CAMMAC to be validated by a separate, trusted, service other than the KDC. An example of such a case would be when a lesser-privileged service on a host may receive an authentication from a client, and might then ask a higher-privileged service (the "trusted service") on the same host to act on behalf of the client. To demonstrate that the client has authenticated to it, the lesser-privileged service can extract the AD-CAMMAC container from the ticket and submit it to the trusted service. The trusted service can either ask a specialized service (not yet specified) on the KDC to validate the AD-CAMMAC container, or use verify the optional additional verifiers (the other-verifiers field) that are part of the AD-CAMMAC. The presence of the new kdc-verifier and other-verifier fields in the CAMMAC enable several new use cases for the Kerberos protocol which the AD-KDC-ISSUED container does not accomodate. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I also don't see any text to address my request for more guidance about what the AD_CAMMAC_BINDING element would contain -- was this an oversight or a deliberate choice? Thanks, Ben From kaduk@mit.edu Tue Nov 5 09:14:02 2013 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 DAFEF11E80D9 for ; Tue, 5 Nov 2013 09:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPs0xLLn4cc6 for ; Tue, 5 Nov 2013 09:13:55 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 12CDC21E8089 for ; Tue, 5 Nov 2013 09:13:52 -0800 (PST) X-AuditID: 1209190f-b7fa08e0000009c6-c1-52792750ffe8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 41.50.02502.05729725; Tue, 5 Nov 2013 12:13:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rA5HDpH8030680; Tue, 5 Nov 2013 12:13:51 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA5HDn2g007896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Nov 2013 12:13:50 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rA5HDmfM028504; Tue, 5 Nov 2013 12:13:48 -0500 (EST) Date: Tue, 5 Nov 2013 12:13:48 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nohugXhlk8PS+kMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGWcXvCYueCVXMXRW1uYGhgPS3QxcnJICJhI zFu7ihHCFpO4cG89WxcjF4eQwD5GiZ4DX6GcDYwS1y69ZoZwDjJJfDq7nRWkRUigXmLau93M IDaLgJbEw8b3YHE2ARWJmW82soHYIgLCEru3vgOrYRbwkFj0YBlYXFggUOLupk9MIDangJFE w/V1YDW8Ag4Sq681skDMT5e4cuIkmC0qoCOxev8UFogaQYmTM5+wQMy0lPi39hfrBEbBWUhS s5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10cvNLNFLTSndxAgKVU5J/h2M3w4qHWIU 4GBU4uFNkK8MEmJNLCuuzD3EKMnBpCTK264CFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCe+x/ RZAQb0piZVVqUT5MSpqDRUmc9yaHfRDQN4klqdmpqQWpRTBZGQ4OJQnetWpAQwWLUtNTK9Iy c0oQ0kwcnCDDeYCGd4DU8BYXJOYWZ6ZD5E8xKkqJ824BSQiAJDJK8+B6YankFaM40CvCvH0g VTzANATX/QpoMBPQ4IQlZSCDSxIRUlINjG7ahqcecU11WZ4uNPcRX2uY6eaMIzPf21YozY6d 81FZ46NGefbFtezrmoPfndbSNPQv0kyd92vXpjN9+YF3Qy6W2e3ffsd7zQt+vRNHflSnJeo/ 27r3DYfp8sXljX/F7lx6sMJ0rXntdTUDi3//grtLGCc9X7t+29em925Jy245mb3KFMy8m6bE UpyRaKjFXFScCADb+8I1AAMAAA== Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:14:02 -0000 On Mon, 28 Oct 2013, Greg Hudson wrote: > Here are a couple of issues Ben and I discussed before the draft was > submitted, which Ben thought we could use list input on: > > 1. Overlap with 2743 > > It wasn't immediately clear to me whether this draft is a distillation > of RFC 2743 or whether it imposes new requirements. I think there might > be some new requirements (like "The initiator MUST NOT change any of the > input parameters to GSS_Init_sec_context() between calls", while 2743 > only mentions the claimant_cred_handle parameter), but they aren't > differentiated from repeated requirements. This is probably closely related to whether the new document ends up being standards-track or just informational. If there are no new actual requirements, it probably makes sense to have it just be informational. On the other hand, maybe we do want requirements like the constancy of init/accept_sec_context arguments through the loop (per (2)) to be added, in which case it would need to go on the standards track. I will try to make time to do a close read of 2743 side-by-side with this draft, but it would be helpful to have input from other reviewers, too. > 2. Handling of impossible situations > > Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI > returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty > output token. This is a nonsense answer from the GSS implementation, > indicative of a serious bug, and I don't think a spec like this needs to > describe what applications should do in the face of bugs. I think most > applications I have seen will just send an empty token to the other > side, which will reject it, and that's not a problem. The thread seems to have mostly diverged into considering whether or not an empty token would be appropriate. The volume of discussion makes me suspect that mentioning it in some form is appropriate, though it's unclear that the text in my -00 is correct. > 3. Example code > > The draft is written completely at the RFC 2743 level, independent of > language bindings. I was sort of expecting a draft like this to have > example code using the C bindings. There is already example code for > gss_init_sec_context and gss_accept_sec_context in RFC 2744, but it > could perhaps be improved to cover some of the statements in the draft, > like checking ret_flags after the context is established. I agree that there would be value in example code, I was just not convinced that it was necessary for the -00. It sounds like there is some WG interest in the document; if we decide to adopt it, I'm happy to add example code. Looking at the charter, this work seems to fall under "develop extensions and/or updates to the GSS-API", but not any more specific items. On Mon, 28 Oct 2013, Nico Williams wrote: > I'll review later today in detail. I think pseudo-code would be nice to Hmm, maybe I should have sent a reminder sooner. > have. I don't mind if it's synchronous-looking pesudo-code: between > threadlets (the JavaScript literature is filled to the brim, and long > ago spilled, with libraries along these lines) and such, and programmers > who know how to turn synchronous code into async code, I don't think > that's a problem. I realize that normative text is also desirable, but > we already have it: in RFC2743. So for an informative I-D I think > pseudo-code would be very good to have, and since we have C code in I don't think the normative/informative question is fully settled yet, actually. > RFC2744, it shouldn't be difficult to adapt. I agree that the 2744 example code should be easy to adopt. > Also, given that we have consensus for the channel-bound flag extension > that introduces a stepper model, I think we'll need to do this again... Probably. But, one thing at a time, I suppose. -Ben From kaduk@mit.edu Wed Nov 6 12:44:29 2013 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 6F27221E80C3 for ; Wed, 6 Nov 2013 12:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvL2tBtBlGns for ; Wed, 6 Nov 2013 12:44:24 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id CD58111E812B for ; Wed, 6 Nov 2013 12:44:23 -0800 (PST) X-AuditID: 12074425-b7f1c8e0000009c7-95-527aaa27d186 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C8.DA.02503.72AAA725; Wed, 6 Nov 2013 15:44:23 -0500 (EST) 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 rA6KiMFt000908; Wed, 6 Nov 2013 15:44:23 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA6KiKgL000512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Nov 2013 15:44:21 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rA6KiKm2029946; Wed, 6 Nov 2013 15:44:20 -0500 (EST) Date: Wed, 6 Nov 2013 15:44:20 -0500 (EST) From: Benjamin Kaduk To: Nathan Kinder In-Reply-To: <526EB4F9.9000007@redhat.com> Message-ID: References: <526EB4F9.9000007@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrau+qirI4EGnlMXRzatYLCa8uc3q wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGXc3LGXqWAhd8Xf6UsZGxh/cXQxcnJICJhI rJ28mw3CFpO4cG89kM3FISSwj1Hi9cUvTBDOBkaJl3MWskA4B5kkJtx6wwTSIiRQL/H+zQew dhYBLYmnn9Yzg9hsAioSM99sBIuLCKhJvN20lxHEZhYQllh/bgZYjbBAnMTRRZuAajg4OIF6 t33gBgnzCjhIrG/oZYUYrykx48deFhBbVEBHYvX+KSwQNYISJ2c+YYEYaSnxb+0v1gmMgrOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokRFKjsLqo7GCccUjrE KMDBqMTDO6OmKkiINbGsuDL3EKMkB5OSKO/s5UAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwC oUA53pTEyqrUonyYlDQHi5I47y0O+yAhgfTEktTs1NSC1CKYrAwHh5IEr+hKoEbBotT01Iq0 zJwShDQTByfIcB6g4bIgNbzFBYm5xZnpEPlTjIpS4rwKIAkBkERGaR5cLyyRvGIUB3pFmFcL pIoHmITgul8BDWYCGhzyqxJkcEkiQkqqgXF71bFJFnUTnLumLrX+a/DWnO/jZeUM7Ybm6K0r /3TYTLsytX9h4YOFd/QF35pfEdtqEjnpdXYMz7YUJ8tF86bs+JoXW9d3o5B58aS1kd0TI6Pr mw6d/3n2cO+K6de31CWkLDv0JN1NNDVnfR/b/BOKGaxz9i1fcO9s8pSD7MG6sTuTHvv/2vlM iaU4I9FQi7moOBEAxTykwf8CAAA= Cc: kitten@ietf.org Subject: Re: [kitten] New draft submitted for "Authentication Indicator in Kerberos tickets" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:44:29 -0000 On Mon, 28 Oct 2013, Nathan Kinder wrote: > Hi, > > I submitted a new draft to IETF last week that seems to fit into the charter > for this working group. The draft is for adding an indicator of the > authentication used into Kerberos tickets. The draft is available here: > > http://tools.ietf.org/html/draft-jain-kitten-krb-auth-indicator-00 > > Please take a look at it and let me know if you have any feedback. Hi Nathan, I read through the draft, and it seems to be a useful feature to have -- right now at MIT, we have two-factor authentication enabled for some principals but not all of them, and applications wishing to ensure that only two-factor auth is used for access must use out-of-band methods to ensure that only two-factor-enabled (enabled == required, here) principals are on the ACL for the service. Having a trusted piece of data from the KDC about how the initial authentication was performed seems like it would be helpful for services that want to ensure two-factor auth was used. One minor note -- in the security considerations section, the element used to bind the contents of the CAMMAC to the enclosing ticket does have a name (AD-CAMMAC-BINDING), which should be used to concretely indicate what is being referred to. The document could also benefit from a bit of editorial attention, but I did not note down the details (it is still a -00, after all). -Ben From tlyu@mit.edu Thu Nov 7 07:57:11 2013 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 4B97621E809B for ; Thu, 7 Nov 2013 07:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xywf4i4A55S7 for ; Thu, 7 Nov 2013 07:57:03 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 468BB11E810F for ; Thu, 7 Nov 2013 07:57:02 -0800 (PST) X-AuditID: 1209190c-b7f058e000005fd9-65-527bb84d5aba Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CD.ED.24537.D48BB725; Thu, 7 Nov 2013 10:57:02 -0500 (EST) 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 rA7Fv14j018541 for ; Thu, 7 Nov 2013 10:57:01 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA7FuxhP032431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Nov 2013 10:57:01 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rA7Fuxmn029108; Thu, 7 Nov 2013 10:56:59 -0500 (EST) To: kitten@ietf.org From: Tom Yu Date: Thu, 07 Nov 2013 10:56:59 -0500 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixG6nruu3ozrIYOUpRoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/GdDWwFf9kqFq3za2C8xtrFyMkhIWAi0fGgixHCFpO4cG89 WxcjF4eQwGwmiekHz7CDJIQEjjFKLLxnBpF4zCSx+PwSFgink1Fi1e+zYO0iAsISu7e+Ywax hQWkJWacOAC0goODDcg+urgMJMwioCqxuGMyE4jNK2Ah8eLvQbAreAQ4JV6e3MgIEReUODnz CQuIzSygJXHj30umCYx8s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKX mlK6iREUSpySPDsY3xxUOsQowMGoxMM7o6YqSIg1say4MvcQoyQHk5Io7/Ft1UFCfEn5KZUZ icUZ8UWlOanFhxglOJiVRHiPLATK8aYkVlalFuXDpKQ5WJTEeW9y2AcJCaQnlqRmp6YWpBbB ZGU4OJQkeHm2AzUKFqWmp1akZeaUIKSZODhBhvMADX8Nspi3uCAxtzgzHSJ/ilFRSpz3C0hC ACSRUZoH1wuL9VeM4kCvCPO+B6niAaYJuO5XQIOZgAaH/KoEGVySiJCSamC0n/L50uS2Wu6K Y7faX50M7tfpX3j43NprH+ccPjL71L9w3/ea06fdqD4g7fZ5u52cWttnt9ULjmo66by5l81w vsAwOSPv52b19IQdyws+bH/lN3N7/qO3b9YIC2Sa88gVG829+Hn+xqLVDppaDFHPDtr9cFC7 cbjq0xvemcJKK59o/D9kPXkDvxJLcUaioRZzUXEiACLcBuPQAgAA Subject: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:57:11 -0000 Here are what I think are the remaining open issues for CAMMAC. Wrapping of CAMMAC: Do we recommend enclosing a CAMMAC inside an AD-IF-RELEVANT? RFC 4120 says that authorization data are critical, i.e., an implementaiton must reject unrecognized authorization data. Alternatively, we could require that CAMMAC be enclosed in an AD-KDCIssued, and drop the consequently redundant "svc-verifier" from CAMMAC. Minor encoding change: Do we change "other-verifiers" from "[3] SEQUENCE OF Verifier" to "[3] SEQUENCE (SIZE (1..MAX)) OF Verifier OPTIONAL"? I think we should do this because it would reduce the encoding size in what I believe will be the common case of no additional verifiers. Motivations text: I'm still looking over Ben's suggestions for the rewording of the "Motivations" section. CAMMAC-BINDING: I think I'll cover this in a separate message. From tlyu@mit.edu Thu Nov 7 11:47:32 2013 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 BB47B11E822F for ; Thu, 7 Nov 2013 11:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5shgm1PWi6n4 for ; Thu, 7 Nov 2013 11:47:20 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB2C11E8188 for ; Thu, 7 Nov 2013 11:47:15 -0800 (PST) X-AuditID: 1209190c-b7f058e000005fd9-61-527bee42f47d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 4B.84.24537.24EEB725; Thu, 7 Nov 2013 14:47:14 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rA7JlDlS002145; Thu, 7 Nov 2013 14:47:13 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA7JlBU4011235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Nov 2013 14:47:13 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rA7JlBJN029734; Thu, 7 Nov 2013 14:47:11 -0500 (EST) To: Sam Hartman References: From: Tom Yu Date: Thu, 07 Nov 2013 14:47:11 -0500 In-Reply-To: (Sam Hartman's message of "Fri, 04 Oct 2013 09:48:21 -0400") Message-ID: Lines: 37 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nouv0rjrI4NQjDYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGUseBJX0MBTcWTvK5YGxoucXYycHBICJhKn ju5igbDFJC7cW8/WxcjFISQwm0ni7f8r7BDOBkaJE+uWMkI4Z5kkdq2+zwbSIiTQyShx53QZ iC0ioC6x+tIkdhCbWUBYYvmas2A1wgI2Er+vLGGFqFeVWP39NNA6Dg42AWmJo4vBWlmAwjcO rmQGCXMKJEvs77QGCfMKWEg8mbgXrJNHgFPi++cZLBBxQYmTM5+wQGzSkrjx7yXTBEbBWUhS s5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11MvNLNFLTSndxAgKUk5Jnh2Mbw4qHWIU 4GBU4uEtuFAdJMSaWFZcmXuIUZKDSUmUV+kNUIgvKT+lMiOxOCO+qDQntfgQowQHs5II75GF QDnelMTKqtSifJiUNAeLkjjvTQ77ICGB9MSS1OzU1ILUIpisDAeHkgTv2bdAjYJFqempFWmZ OSUIaSYOTpDhPEDDn4DU8BYXJOYWZ6ZD5E8xKkqJ8z4ASQiAJDJK8+B6YUnkFaM40CvCvOtA qniACQiu+xXQYCagwSG/KkEGlyQipKQaGOvfzLRM1XsktL1J/O/3BTl3/P3mrKrjz1G28Lwp dEk+famw8KH5jQpWbEvcV+w48yToPXOGfuNXj48Jc2d7MTqdjzI/PuP3vpred10tOfFHPt82 SmHtipx9VezSwX/BG5QnKG8yfrVg2Yx3ElM23S2eY6ge1cEr9Ewn5KmX1MOJZ7+4eXBulVJi Kc5INNRiLipOBACJHuwp/QIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:47:32 -0000 Sam Hartman writes: > Folks, I'd really appreciate input from those who responded to the AES > CBC consensus call. > > 1) Do you need any additional information to evaluate Paul's message? I would like more information on whethere there is likely to be any way forward to make applications using the Windows encryption APIs more capable of supporting padded CBC modes. (This might include improving the documentation of these APIs.) I will need to review some more MSDN documentation before I can ask the right questions though. I'm also fully willing to believe that encryption APIs providing padded CBC modes are too difficult for application developers to consistently write correct code for. > 2) Has Paul's message caused you to revise your opinions in any way? I think at this point we're best off standardizing something that satisfies as many Suite B criteria as we can get consensus on, while meeting the constraints of Windows applications that might not be aware of a need to do padding. To me, this means some variant of the AES CTS mode that we described in RFC 3962. I think the Suite B criteria that we might be able to satisfy include: * Encrypt-then-MAC * Full-length MAC using appropriate SHA-2 hashes * Maybe explicit IV (though I prefer to continue using confounders for reasons I've already mentioned) I think we can consider counter modes, but we should figure out how to manage the nonce reuse/collision risks if we're going to do that. From tlyu@mit.edu Thu Nov 7 14:56:04 2013 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 133CD11E8235 for ; Thu, 7 Nov 2013 14:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcUgX0P4OuLU for ; Thu, 7 Nov 2013 14:55:35 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id CC81D11E815B for ; Thu, 7 Nov 2013 14:55:34 -0800 (PST) X-AuditID: 12074422-b7f028e000003e57-11-527c1a667918 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 89.10.15959.66A1C725; Thu, 7 Nov 2013 17:55:34 -0500 (EST) 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 rA7MtXbv025189 for ; Thu, 7 Nov 2013 17:55:33 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA7MtWD3025106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Nov 2013 17:55:33 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rA7MtVAj000233; Thu, 7 Nov 2013 17:55:31 -0500 (EST) To: kitten@ietf.org From: Tom Yu Date: Thu, 07 Nov 2013 17:55:31 -0500 Message-ID: Lines: 30 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixG6nrpsmVRNk0DKXy+Lo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWPh4PVtBP0fF0Wv72BoYp7J1MXJySAiYSCzv2ccEYYtJXLi3 HijOxSEkMJtJ4v6M2+wQzjFGiZ4rZ1kgnMdMEr/m7wVrFxLoZJRYeFAJxBYREJbYvfUdM4gt LGArMfHnTtYuRg4ONgFpiaOLy0DCLAKqEhenX2UDCfMKWEisvKADEuYR4JR4dPYy2BG8AoIS J2c+YQGxmQW0JG78e8k0gZFvFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9XIz S/RSU0o3MYJDyUVpB+PPg0qHGAU4GJV4eAsuVAcJsSaWFVfmHmKU5GBSEuWtkawJEuJLyk+p zEgszogvKs1JLT7EKMHBrCTCu/c7UDlvSmJlVWpRPkxKmoNFSZz3Fod9kJBAemJJanZqakFq EUxWhoNDSYLXG2SoYFFqempFWmZOCUKaiYMTZDgP0PB+kBre4oLE3OLMdIj8KUZFKXHeNJCE AEgiozQPrhcW668YxYFeEeaNBKniAaYJuO5XQIOZgAaH/KoEGVySiJCSamBM6rgms5n3XJFl Rvu8JD13hiaWRfYbovj/KE1rWnp7p6i73zJN51YHUfbT889M3nqBZ01XgpWm8PPpFy/s2PvU xvfVrgL5b88Orxe/8zZ4ilbp7w25tjf1JybFBvffevOovvzb3L3WAlvN1z5w9OTd99jLetr2 h1vNE86E2llk7Z/1lcNBanGBEktxRqKhFnNRcSIA61+VUtACAAA= Subject: [kitten] status of draft-ietf-kitten-kerberos-iana-registries X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:56:04 -0000 I recently finished cleaning up after an accident in my Kerberos numbers database that partially overwrote symbolic name information. I think the text is mostly ready. I am thinking of adding guidance about ticket flags and KDC options to recommend that future assignments should reflect the existing practice where a KDC option requests a ticket flag, the bit numbers should be the same in the KDC option and the ticket flag. I would like volunteers to help check the list of existing assignments, possibly dividing the work by number type. My rough counts are: addrtype 11 nametype 14 adtype 23 errcode 128 keyusage 47 apoption 3 kdcoption 22 ticketflag 16 This checking would involve looking through RFCs, Internet Drafts, and implementation source code to make sure that nothing that is worth registering is missed, and that there are no number conflicts. We can work out timelines among the volunteers, with the help of the chairs. Thanks. From kaduk@mit.edu Thu Nov 7 15:13:53 2013 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 D593A11E8264 for ; Thu, 7 Nov 2013 15:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL4lqQ1HwiOx for ; Thu, 7 Nov 2013 15:13:47 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2656511E8197 for ; Thu, 7 Nov 2013 15:13:47 -0800 (PST) X-AuditID: 12074422-b7f028e000003e57-a2-527c1eaa19f0 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 13.E0.15959.AAE1C725; Thu, 7 Nov 2013 18:13:46 -0500 (EST) 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 rA7NDjv5015083; Thu, 7 Nov 2013 18:13:46 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA7NDhJr031504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Nov 2013 18:13:45 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rA7NDhVP024062; Thu, 7 Nov 2013 18:13:43 -0500 (EST) Date: Thu, 7 Nov 2013 18:13:42 -0500 (EST) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrbtKribI4MJ9NYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGX8mFVWcJS/4lbfd+YGxpk8XYycHBICJhLn r7QxQdhiEhfurWfrYuTiEBKYzSTx5MAzFghnA6PE9I397BDOQSaJrh0PmUFahATqJRrfLWPt YuTgYBHQkri5qAgkzCagIjHzzUY2EFtEQFLi2JPzYOXMAhYSHUcnsoDYwgI2Er+vLGEFsTkF LCU6n+8Bs3kFHCQ+vzvKBDE+SOLWm+1gvaICOhKr909hgagRlDg58wkLxExLiXN/rrNNYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzMEr3UlNJNjKAwZXdR2sH486DS IUYBDkYlHt6CC9VBQqyJZcWVuYcYJTmYlER5FaVrgoT4kvJTKjMSizPii0pzUosPMUpwMCuJ 8O79DlTOm5JYWZValA+TkuZgURLnvcVhHyQkkJ5YkpqdmlqQWgSTleHgUJLg/SMLNFSwKDU9 tSItM6cEIc3EwQkynAdo+C0ZoBre4oLE3OLMdIj8KUZFKXHe9SDNAiCJjNI8uF5YGnnFKA70 ijAvPzCpCPEAUxBc9yugwUxAg0N+VYIMLklESEk1MC7WcFNfu2FfTc/2MrMl6QKfDe+2bV0Z 9D9br+RnBqOcCssFi4fTffZP+FTjVCByuPFUakjz5ifrwvbz3K9Z/WkB19ykiu+xs3vMW1wV E8+c+Jfan1eVxNKg+SPske/MqNnfViwUYNeK9lT+zlBQpvFp9pYWr5VWmfee/H2deswjOUPl lr7NCiWW4oxEQy3mouJEAHtatwr+AgAA Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:13:53 -0000 On Thu, 7 Nov 2013, Tom Yu wrote: > Sam Hartman writes: > >> Folks, I'd really appreciate input from those who responded to the AES >> CBC consensus call. >> >> 1) Do you need any additional information to evaluate Paul's message? > > I would like more information on whethere there is likely to be any > way forward to make applications using the Windows encryption APIs > more capable of supporting padded CBC modes. (This might include > improving the documentation of these APIs.) I will need to review > some more MSDN documentation before I can ask the right questions > though. I agree (this is what I was trying to say in a previous message; I'm not sure how well it came through). >> 2) Has Paul's message caused you to revise your opinions in any way? > > I think at this point we're best off standardizing something that > satisfies as many Suite B criteria as we can get consensus on, while > meeting the constraints of Windows applications that might not be > aware of a need to do padding. To me, this means some variant of the I agree. > AES CTS mode that we described in RFC 3962. > > I think the Suite B criteria that we might be able to satisfy include: > > * Encrypt-then-MAC > > * Full-length MAC using appropriate SHA-2 hashes > > * Maybe explicit IV (though I prefer to continue using confounders for > reasons I've already mentioned) I agree that we are likely to be able to satisfy these three. I think Greg mentioned some key derivation functions at some point, which we can probably also do. (I don't have the details handy just at the moment.) I'm still undecided on the confounder vs. IV question and sort of think we should seek external input. > I think we can consider counter modes, but we should figure out how to > manage the nonce reuse/collision risks if we're going to do that. I'm not sure who is prepared to put time into researching counter modes. -Ben From jhutz@cmu.edu Mon Nov 11 13:51:39 2013 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 C00C811E80F9 for ; Mon, 11 Nov 2013 13:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LtgtyBNzFrB for ; Mon, 11 Nov 2013 13:51:34 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id CAFEC11E8114 for ; Mon, 11 Nov 2013 13:51:33 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rABLpWgC000198 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 16:51:32 -0500 (EST) Message-ID: <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Mon, 11 Nov 2013 16:51:32 -0500 In-Reply-To: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:51:39 -0000 On Thu, 2013-11-07 at 10:56 -0500, Tom Yu wrote: > Here are what I think are the remaining open issues for CAMMAC. > > Wrapping of CAMMAC: > > Do we recommend enclosing a CAMMAC inside an AD-IF-RELEVANT? RFC 4120 > says that authorization data are critical, i.e., an implementaiton > must reject unrecognized authorization data. Alternatively, we could > require that CAMMAC be enclosed in an AD-KDCIssued, and drop the > consequently redundant "svc-verifier" from CAMMAC. I fail to see how these are alternatives. As a wrapper, AD-IF-RELEVANT has special semantics which nullify the criticality of the element it wraps. AD-KDCIssued does not have this property. -- Jeff From ghudson@mit.edu Mon Nov 11 14:46:45 2013 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 5BAE421E809D for ; Mon, 11 Nov 2013 14:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHIbeuIVFM06 for ; Mon, 11 Nov 2013 14:46:23 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 84A6621E8092 for ; Mon, 11 Nov 2013 14:46:22 -0800 (PST) X-AuditID: 1209190e-b7efb6d000000bb9-a1-52815e3d2df2 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F0.FA.03001.D3E51825; Mon, 11 Nov 2013 17:46:21 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rABMkKvn008584; Mon, 11 Nov 2013 17:46:21 -0500 Received: from [18.101.8.171] (vpn-18-101-8-171.mit.edu [18.101.8.171]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rABMkFPg022486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Nov 2013 17:46:19 -0500 Message-ID: <52815E37.9020109@mit.edu> Date: Mon, 11 Nov 2013 17:46:15 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jeffrey Hutzelman , kitten@ietf.org References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6nomsb1xhksH6tgcX19+fYLY5uXsXi wOSxv/UYq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ6dl9gK1jMWXFlyxy2Bsbj7F2MnBwSAiYS rT3tTBC2mMSFe+vZuhi5OIQEZjNJdHz7zwzhbGSUWHH7GzuEc4RJYvGCPawgLbwCahIPtu0C G8UioCpx6MIeNhCbTUBZ4uDZbywgtqhAkMTxrROYIOoFJU7OfAIWFxEwk/i1+CEziC0soCGx 6e0BqNUdjBLPFt8HW8ApYCuxpeMAC8R9khLbFh0DW8YsoCPxru8BM4QtL7H97RzmCYyCs5Ds mIWkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzGCgphTkm8H49eD SocYBTgYlXh4d3A1BgmxJpYVV+YeYpTkYFIS5Z0TBRTiS8pPqcxILM6ILyrNSS0+xCjBwawk wvvWAyjHm5JYWZValA+TkuZgURLnvclhHyQkkJ5YkpqdmlqQWgSTleHgUJLgvRgD1ChYlJqe WpGWmVOCkGbi4AQZzgM0/DlIDW9xQWJucWY6RP4Uo6KUOK8TSEIAJJFRmgfXC0syrxjFgV4R 5t0MUsUDTFBw3a+ABjMBDXZ4VQsyuCQRISXVwJgtrLG8QLd6k285//bjeatXue3+fMpCOaRj /elPYVU97InxoUqS7E+LrP/oqZ3oPq/29IBN3xdtu/YjxQV7eqfUzE0+mBy0998S8zNz5Lly j3euNHvgqjqJI2GfcY3n/tNtKRNKsu7J3lqXnzJZ4n6Y9a0bTFfjXY+9+rZ02kKNqntlYiaJ CkosxRmJhlrMRcWJAGKIsnMNAwAA Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:46:46 -0000 On 11/11/2013 04:51 PM, Jeffrey Hutzelman wrote: > I fail to see how these are alternatives. As a wrapper, AD-IF-RELEVANT > has special semantics which nullify the criticality of the element it > wraps. AD-KDCIssued does not have this property. My reading of RFC 4120 section 5.2.6.2 is that AD-KDCIssued authdata are implicitly non-critical. The text isn't as precise as I would like, but: * "The KDC-issued ad-data field is intended to provide a means for... positive authorization...". * "Elements encapsulated with in the KDC-issued element MUST be ignored by the application server if this 'signature' is not present." * "This element and the elements it encapsulates MAY safely be ignored by applications, application servers, and KDCs that do not implement this element." * Earlier in section 5.2.6, "If an unknown authorization data element type is received by a server either in an AP-REQ or in a ticket contained in an AP-REQ, then, unless it is encapsulated in a known authorization data element amending the criticality of the elements it contains, authentication MUST fail. Authorization data is intended to restrict the use of a ticket." From tlyu@mit.edu Mon Nov 11 14:51:25 2013 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 C39E211E80DC for ; Mon, 11 Nov 2013 14:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm6l0uzPo8Xv for ; Mon, 11 Nov 2013 14:51:19 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id DB46721E80B7 for ; Mon, 11 Nov 2013 14:51:18 -0800 (PST) X-AuditID: 12074422-b7f9d6d000000bc0-5c-52815f65df4a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E7.AE.03008.66F51825; Mon, 11 Nov 2013 17:51:18 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rABMpHC4009101; Mon, 11 Nov 2013 17:51:17 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rABMpFUD024248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Nov 2013 17:51:17 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rABMpFJr013462; Mon, 11 Nov 2013 17:51:15 -0500 (EST) To: Jeffrey Hutzelman References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> From: Tom Yu Date: Mon, 11 Nov 2013 17:51:15 -0500 In-Reply-To: <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 11 Nov 2013 16:51:32 -0500") Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nopsW3xhk0LacxeL6+3PsFkc3r2Jx YPLY33qM1WPJkp9MAUxRXDYpqTmZZalF+nYJXBnv5u9nKvjKXHFr/U22BsZJzF2MHBwSAiYS B2frdDFyApliEhfurWfrYuTiEBKYzSTRtbyBBcLZyCixb/NxdgjnHJPEgyvtjBBOF6PEjobH 7CD9IgKqEvfmzGIBsZkFhCWWrznLBmILC2hIbHp7gA2u4c/MV4wgu9kEpCWOLi4DqWEB6t15 ZjfYUE6BBkaJlf0fWEFqeAUsJO7c5AWp4RHglNg9aSvYLl4BQYmTM59A7dKSuPHvJdMERsFZ SFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3ECA5VF6UdjD8PKh1i FOBgVOLh3cHVGCTEmlhWXJl7iFGSg0lJlDcpDijEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPet B1CONyWxsiq1KB8mJc3BoiTOe4vDPkhIID2xJDU7NbUgtQgmK8PBoSTBmw8yVLAoNT21Ii0z pwQhzcTBCTKcB2h4G0gNb3FBYm5xZjpE/hSjopQ475pYoIQASCKjNA+uF5ZKXjGKA70izBsG 0s4DTENw3a+ABjMBDXZ4VQsyuCQRISXVwBj+/Z/E3X9fbmZG7dny7+4xj0PmCe9jJQ+Fb3sS /HP+ojTT5KZf1jNkwqsmVh6Yli6islF6R9QMzfSKVWbh+eG9VfJiKS+XLrd26ZFilrHqPrtZ isfh5dIvm17FluULdFoUMbK2tLMbpnTvd5w8+/XcewtPGRXcmldreFZNYfJRpzLjpCPBh5RY ijMSDbWYi4oTAT3cmesAAwAA Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:51:25 -0000 Jeffrey Hutzelman writes: > I fail to see how these are alternatives. As a wrapper, AD-IF-RELEVANT > has special semantics which nullify the criticality of the element it > wraps. AD-KDCIssued does not have this property. I think there is implied non-criticality of the enclosed elements (RFC 4120 5.2.6.2): This element and the elements it encapsulates MAY safely be ignored by applications, application servers, and KDCs that do not implement this element. From jhutz@cmu.edu Mon Nov 11 15:21:05 2013 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 5C59C21E80AE for ; Mon, 11 Nov 2013 15:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA7nUI+nssYU for ; Mon, 11 Nov 2013 15:20:59 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 6700B21E80B5 for ; Mon, 11 Nov 2013 15:20:59 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rABNKwIS002990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 18:20:58 -0500 (EST) Message-ID: <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Greg Hudson Date: Mon, 11 Nov 2013 18:20:58 -0500 In-Reply-To: <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu> References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 23:21:05 -0000 On Mon, 2013-11-11 at 17:46 -0500, Greg Hudson wrote: > On 11/11/2013 04:51 PM, Jeffrey Hutzelman wrote: > > I fail to see how these are alternatives. As a wrapper, AD-IF-RELEVANT > > has special semantics which nullify the criticality of the element it > > wraps. AD-KDCIssued does not have this property. > > My reading of RFC 4120 section 5.2.6.2 is that AD-KDCIssued authdata are > implicitly non-critical. The text isn't as precise as I would like, but: > > * "The KDC-issued ad-data field is intended to provide a means for... > positive authorization...". Not relevant. > * "Elements encapsulated with in the KDC-issued element MUST be ignored > by the application server if this 'signature' is not present." I'm not even sure what this means, since the 'signature' is contained in a non-optional field; if it's not present, the AD won't parse. > * "This element and the elements it encapsulates MAY safely be ignored > by applications, application servers, and KDCs that do not implement > this element." I somehow missed this. In which case, yes, wrapping in AD-KDCIssued would indeed obviate the need to wrap in AD-IF-RELEVANT. However, that means that wrapping in AD-KDCissued is not a substitute for using the svc-verifier, since the former carries semantics affecting criticality. If we drop svc-verifier, then there is no way to issue credentials containing AD that is both authenticated and critical! IMHO, we should simply note that most already-deployed services will not understand AD-CAMMAC, and specify that it SHOULD be enclosed in AD-IF-RELEVANT unless it contains authorization data which is critical with respect to the service or some principal named in other-verifiers. Probably we should also indicate that AD-CAMMAC-BINDING SHOULD be enclosed in AD-IF-RELEVANT unless the containing AD-CAMMAC is already so wrapped, and modify the text so that an AD-CAMMAC whose first element is an AD-IF-RELEVANT wrapping AD-CAMMAC-BINDING is permissible. Incidentally, it's not clear that wrapping AD-CAMMAC in AD-IF-RELEVANT automatically confers full non-criticality on all of the wrapped elements! The definition of AD-IF-RELEVANT in RFC4120 5.2.6.1 is ambiguous in this respect. It may be desirable to clarify that if a particular AD-CAMMAC is wrapped in AD-IF-RELEVANT, the non-criticality applies to all of its elements. -- Jeff From kaduk@mit.edu Mon Nov 11 20:11:29 2013 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 C228511E814B for ; Mon, 11 Nov 2013 20:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+hIQpIKZtam for ; Mon, 11 Nov 2013 20:11:19 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2204311E81A5 for ; Mon, 11 Nov 2013 20:11:17 -0800 (PST) X-AuditID: 12074424-b7fa56d000000be4-c2-5281aa64692c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 59.93.03044.46AA1825; Mon, 11 Nov 2013 23:11:16 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rAC4BFIA015666; Mon, 11 Nov 2013 23:11:16 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAC4BDK2026971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Nov 2013 23:11:15 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAC4BDZO002003; Mon, 11 Nov 2013 23:11:13 -0500 (EST) Date: Mon, 11 Nov 2013 23:11:13 -0500 (EST) From: Benjamin Kaduk To: Jeffrey Hutzelman In-Reply-To: <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu> Message-ID: References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu> <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrJuyqjHI4MpMA4vr78+xWxzdvIrF gcljf+sxVo8lS34yBTBFcdmkpOZklqUW6dslcGXcv9zOVDBJpOL5tfwGxjUCXYycHBICJhLP /s1nhLDFJC7cW8/WxcjFISQwm0nizOFVrBDORkaJ16tWMkM4h5gkWr/uhXIaGCXm/jnICtLP IqAt8WPSD3YQm01ARWLmm41sILaIgKrEvTmzWLoYOTiYBYwkLvzKAAkLC2hIbHp7AKyEU8BO YtWvdhYQm1fAQeJ0Sz/UGV8ZJR70TAFLiAroSKzePwWqSFDi5MwnYDazgKXEuT/X2SYwCs5C kpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGUKiyu6jsYGw+pHSI UYCDUYmHdwdXY5AQa2JZcWXuIUZJDiYlUV6zFUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzh i4FyvCmJlVWpRfkwKWkOFiVx3lsc9kFCAumJJanZqakFqUUwWRkODiUJ3sKVQI2CRanpqRVp mTklCGkmDk6Q4TxAw01AaniLCxJzizPTIfKnGBWlxHkzQRICIImM0jy4XlgqecUoDvSKMK8t SBUPMA3Bdb8CGswENNjhVS3I4JJEhJRUA+PqEs7Khf4Nu69E8/3XYJm1Y06K/6FpJyQl4qu+ 7Rfr/HS7eXvuptnNb41ldlznWNRyQO3TJ++pKSdC2U933b/xUX7TWiaeTXOOLiybUzXtzWXp R3dvquUaH/9VJ/+Ua714fLG78FXVicnX5xt78UivP+S/Kf+8a7wD93GxLYvCX5TnMkhKnNZU YinOSDTUYi4qTgQA96KxhgADAAA= Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 04:11:29 -0000 On Mon, 11 Nov 2013, Jeffrey Hutzelman wrote: > On Mon, 2013-11-11 at 17:46 -0500, Greg Hudson wrote: >> On 11/11/2013 04:51 PM, Jeffrey Hutzelman wrote: >>> I fail to see how these are alternatives. As a wrapper, AD-IF-RELEVANT >>> has special semantics which nullify the criticality of the element it >>> wraps. AD-KDCIssued does not have this property. >> >> My reading of RFC 4120 section 5.2.6.2 is that AD-KDCIssued authdata are >> implicitly non-critical. The text isn't as precise as I would like, but: >> >> * "The KDC-issued ad-data field is intended to provide a means for... >> positive authorization...". > > Not relevant. It seems relevant in a circumstantial way, in that there is not a security risk from ignoring unknown positive authorization data in the way that there is for ignoring unknown negative authorization data. >> * "This element and the elements it encapsulates MAY safely be ignored >> by applications, application servers, and KDCs that do not implement >> this element." > > I somehow missed this. In which case, yes, wrapping in AD-KDCIssued > would indeed obviate the need to wrap in AD-IF-RELEVANT. However, that > means that wrapping in AD-KDCissued is not a substitute for using the > svc-verifier, since the former carries semantics affecting criticality. > If we drop svc-verifier, then there is no way to issue credentials > containing AD that is both authenticated and critical! > > IMHO, we should simply note that most already-deployed services will not > understand AD-CAMMAC, and specify that it SHOULD be enclosed in > AD-IF-RELEVANT unless it contains authorization data which is critical > with respect to the service or some principal named in other-verifiers. Do we anticipate there ever being such critical data? It seems like it would be simpler if we could specify that it is always AD-IF-RELEVANT. > Probably we should also indicate that AD-CAMMAC-BINDING SHOULD be > enclosed in AD-IF-RELEVANT unless the containing AD-CAMMAC is already so > wrapped, and modify the text so that an AD-CAMMAC whose first element is > an AD-IF-RELEVANT wrapping AD-CAMMAC-BINDING is permissible. It's not immediately clear to me why, if the contents are just an OCTET STRING. > Incidentally, it's not clear that wrapping AD-CAMMAC in AD-IF-RELEVANT > automatically confers full non-criticality on all of the wrapped > elements! The definition of AD-IF-RELEVANT in RFC4120 5.2.6.1 is > ambiguous in this respect. It may be desirable to clarify that if a Ugh. -Ben From jhutz@cmu.edu Mon Nov 11 22:06:09 2013 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 B555011E8189 for ; Mon, 11 Nov 2013 22:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ-pIb6rE8gh for ; Mon, 11 Nov 2013 22:06:02 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86621E8088 for ; Mon, 11 Nov 2013 22:05:29 -0800 (PST) Received: from [192.168.202.142] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rAC65Ocg015784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Nov 2013 01:05:26 -0500 (EST) Message-ID: <1384236324.3011.26.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Benjamin Kaduk Date: Tue, 12 Nov 2013 01:05:24 -0500 In-Reply-To: <31380_1384229493_rAC4BWR9031659_alpine.GSO.1.10.1311112304380.4934@multics.mit.edu> References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu> <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu> <31380_1384229493_rAC4BWR9031659_alpine.GSO.1.10.1311112304380.4934@multics.mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 06:06:10 -0000 On Mon, 2013-11-11 at 23:11 -0500, Benjamin Kaduk wrote: > > IMHO, we should simply note that most already-deployed services will not > > understand AD-CAMMAC, and specify that it SHOULD be enclosed in > > AD-IF-RELEVANT unless it contains authorization data which is critical > > with respect to the service or some principal named in other-verifiers. > > Do we anticipate there ever being such critical data? It seems like it > would be simpler if we could specify that it is always AD-IF-RELEVANT. We're designing a generic container that allows the KDC to send authenticated authorization data. It seems to me that limiting that container to supporting only non-critical authorization data is both short-sighted and unnecessary. As I recall, we got here because AD-KDCissued turned out to not be sufficient for our needs, and we decided to build a generic signed-AD container rather than another narrowly-scoped hard-to-reuse one. > > Probably we should also indicate that AD-CAMMAC-BINDING SHOULD be > > enclosed in AD-IF-RELEVANT unless the containing AD-CAMMAC is already so > > wrapped, and modify the text so that an AD-CAMMAC whose first element is > > an AD-IF-RELEVANT wrapping AD-CAMMAC-BINDING is permissible. > > It's not immediately clear to me why, if the contents are just an OCTET > STRING. The current definition of AD-CAMMAC-BINDING requires that it be the first element of an AD-CAMMAC, if it is present at all. Wrapping it in an AD-IF-RELEVANT violates that. However, this is moot -- on further reflection, I realize there is no reason for AD-CAMMAC(AD-IF-RELEVANT(AD-CAMMAC-BINDING)), since any implementation that understands AD-CAMMAC must necessarily also recognize AD-CAMMAC-BINDING, even though non-KDCs will never make use of it. So, I withdraw this comment. From ghudson@mit.edu Tue Nov 12 05:28:10 2013 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 D60DE21F9D34 for ; Tue, 12 Nov 2013 05:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckJyFwZjOpiA for ; Tue, 12 Nov 2013 05:28:04 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2244111E813D for ; Tue, 12 Nov 2013 05:28:04 -0800 (PST) X-AuditID: 1209190f-b7fb86d000000c36-6a-52822ce3f968 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B2.D7.03126.3EC22825; Tue, 12 Nov 2013 08:28:03 -0500 (EST) 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 rACDS2jb018284; Tue, 12 Nov 2013 08:28:03 -0500 Received: from [18.101.8.80] (vpn-18-101-8-80.mit.edu [18.101.8.80]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rACDS0qw025211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Nov 2013 08:28:01 -0500 Message-ID: <52822CE0.4000105@mit.edu> Date: Tue, 12 Nov 2013 08:28:00 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu> <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu> <31380_1384229493_rAC4BWR9031659_alpine.GSO.1.10.1311112304380.4934@multics.mit.edu> <1384236324.3011.26.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1384236324.3011.26.camel@destiny.pc.cs.cmu.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT132s0xRkcOq2msX19+fYLY5uXsXi wOSxv/UYq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJuPZ7AXPCZvWLJlq3MDYwn2boYOTkkBEwk PkxZyAphi0lcuLceLC4kMJtJYvKT5C5GLiB7I6PE/YZ9rBDOQSaJ+09/gHXwCqhJfF3xlR3E ZhFQlZh9bAEjiM0moCxx8Ow3FhBbVCBI4vjWCUwQ9YISJ2c+AYuLANXfmzMLzGYWEJa4sH0v 2ExhAQ2JTW8PsEEs+80k8WL/QqAiDg5OAVuJ54c5IC6VlNi26Bg7RK+OxLu+B8wQtrzE9rdz mCcwCs1Csm4WkrJZSMoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECAps Tkn+HYzfDiodYhTgYFTi4d3B1RgkxJpYVlyZe4hRkoNJSZR3n3ZTkBBfUn5KZUZicUZ8UWlO avEhRgkOZiUR3mh5oBxvSmJlVWpRPkxKmoNFSZz3Jod9kJBAemJJanZqakFqEUxWhoNDSYKX HxjBQoJFqempFWmZOSUIaSYOTpDhPEDDbUBqeIsLEnOLM9Mh8qcYFaXEeWNBEgIgiYzSPLhe WOJ5xSgO9IowrydIFQ8wacF1vwIazAQ0eMndRpDBJYkIKakGRl438/3u6j+tDq961vicd1uG Z/NXQYUcXvFaDfO4IJkDC6Pa7+46lei3VtFp25e63fd/3VVomeIt0+WUGNSdYpYiH7ztzpGt v16z59ybbnP/e1TXX/H7mftl3274MmmSW/Xn8qfbZ0w9OS9gxTv2O3UiJ0R7PJrm1K19KDdt Y6x7jqJrosyRHiWW4oxEQy3mouJEAL7cYfUXAwAA Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC open issues X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 13:28:10 -0000 On 11/12/2013 01:05 AM, Jeffrey Hutzelman wrote: > We're designing a generic container that allows the KDC to send > authenticated authorization data. It seems to me that limiting that > container to supporting only non-critical authorization data is both > short-sighted and unnecessary. In reality, we cannot create critical authdata because some (all?) implementations ignore unrecognized authdata in violation of RFC 4120, so the concept of critical authdata more of a standards-process nuisance than anything else. We could treat CAMMAC as an opportunity to change this, but it's only a weak opportunity. We could trust that implementors of CAMMAC will treat CAMMAC-wrapped authdata as critical if the CAMMAC is not itself wrapped in an AD-IF-RELEVANT. But unless (1) everyone implements CAMMAC, and (2) enough time has passed that everyone has upgraded to versions implementing CAMMAC, some implementations would still ignore CAMMAC-wrapped supposedly-critical authdata elements. From nico@cryptonector.com Tue Nov 12 13:17:37 2013 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 39F1C11E810C for ; Tue, 12 Nov 2013 13:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE30woidZ19x for ; Tue, 12 Nov 2013 13:17:31 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5701B11E8128 for ; Tue, 12 Nov 2013 13:16:50 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 9305E67C074 for ; Tue, 12 Nov 2013 13:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=cRuyX3kya2kKsqZAAYQ3PfhL1qU=; b=F+2SbwD5XQi E21KkjwQec30MVHjrP6hDp6N90z9rs0cIC2Gg8Zc09okdoLa/3vqZBRoWClg50ve tnf1ba6seUFSqSCvtnVFhejdbzOrHwUaQNgyaoY5SyE6YXerzckaY/1M/UlXlL62 +7Af9k2rCUonu18BE9rDUvavlxLFdLeo= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id EF9ED67C07B for ; Tue, 12 Nov 2013 13:16:32 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id ey11so4405881wid.13 for ; Tue, 12 Nov 2013 13:16:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=izOSsGTs22Kbsmc580nDucdczAQQiw0m5uu+8MDtQHU=; b=WHwY1fUnZBvVma5Mn9kyVxi7PuvZ8L0SMkTpaJhfpOcvB21vbfq82gbCUlDVRqIDy8 P+vq0PGGo6jMfAibF2So2+KNyt3WyVuPYJ9ABinlxVqkFWaiwbdAqXe48d/LvrnbSdnI 7qdbmjbOT3YntS6ta3eIUoj2YQjk1oBPQkFP/pxDeLL6RINn1XxJcI/ms19bYldSnjF4 y/RR5tTb3pn4YY2DTje4ibSmhwjQtHH8JWk2xBe4HLphGFLl9mZAUhNOIcxMViODGoUc /LVMV4DjS1g6DaWZXO6OuX9EACIRvlMmfwfTPiIBcRXmAmFEqMyss9AFhEnbNH6uMKUi 1i4g== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr18020259wik.13.1384290989104; Tue, 12 Nov 2013 13:16:29 -0800 (PST) Received: by 10.216.151.136 with HTTP; Tue, 12 Nov 2013 13:16:29 -0800 (PST) Date: Tue, 12 Nov 2013 15:16:29 -0600 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2b01cabed2c04eb015c57 Subject: [kitten] Possible example where variable padding enctypes can break SSPI apps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:17:37 -0000 --001a11c2b01cabed2c04eb015c57 Content-Type: text/plain; charset=UTF-8 See below. Viktor and i conjecture that this is an example of an SSPI app that breaks because of variable padding in 3DES-CBC TLS ciphersuites, and that that applies to Kerberos SSPI apps as well. ---------- Forwarded message ---------- From: *Nico Williams* Date: Thursday, November 7, 2013 Subject: Windows 2003 TLS 64 ciphersuite limit To: tls@ietf.org A non-subscriber (who doesn't want to subscribe just to send this) has asked me to forward this to the TLS WG list. Without further ado: From: Viktor Dukhovni > Subject: Windows 2003 TLS 64 ciphersuite limit Date: Thu, 7 Nov 2013 19:40:16 +0000 [ Please forward to TLS list ] While we're removing interoperability obstacles with TLSv1.2, ... There is another problem with expanded client HELLO messages. The Windows 2003 TLS stack (still used by a non-trivial number of Microsoft Exchange SMTP servers) only looks at the first 64 elements of the cipherlist. If neither RC4-SHA nor RC4-MD5 are among these, it sometimes chooses 3DES (for which it misimplements CBC padding) and fails during data transfer, or if that is suppressed or also too far down the list, just fails the handshake. With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4 at position: $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-' 93:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4-' 111:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 so TLS handshakes with these servers fail! It is not clear what should be done here, the most practical reordering and trimming that comes to mind is: $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA' 51:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Which does not leave much room for more ciphers. I've never seen DSS or DH certificates in the wild, but presumably they are needed in some quarters, so this is likely not a generally applicable solution. I don't know how much longer such servers are likely to remain active. Postfix users are working around this with custom cipher exclusions in the per-destination TLS policy table on a case-by-case basis. :-( The best outcome would be if they all got upgraded! This will take some time I imagine. -- Viktor. --001a11c2b01cabed2c04eb015c57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See below. =C2=A0Viktor and i conjecture that this is an example of an SSPI= app that breaks because of variable padding in 3DES-CBC TLS ciphersuites, = and that that applies to Kerberos SSPI apps as well.

---------- Forw= arded message ----------
From: Nico Williams
Date: Thursday, November 7, 2013
Subject:= Windows 2003 TLS 64 ciphersuite limit
To: tls@ietf.org


A non-subscriber (who doesn't want to su= bscribe just to send this) has
asked me to forward this to the TLS WG list. =C2=A0Without further ado:

From: Viktor Dukhovni <postfix-users@dukhovni.= org>
Subject: Windows 2003 TLS 64 ciphersuite limit
Date: Thu, 7 Nov 2013 19:40:16 +0000

[ Please forward to TLS list ]

While we're removing interoperability obstacles with TLSv1.2, ...
There is another problem with expanded client HELLO messages.

The Windows 2003 TLS stack (still used by a non-trivial number of
Microsoft Exchange SMTP servers) only looks at the first 64 elements
of the cipherlist. =C2=A0If neither RC4-SHA nor RC4-MD5 are among these, it sometimes chooses 3DES (for which it misimplements CBC padding)
and fails during data transfer, or if that is suppressed or also
too far down the list, just fails the handshake.

With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4
at position:

=C2=A0 =C2=A0 $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-&#= 39;
=C2=A0 =C2=A0 93:RC4-SHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 SSLv3 Kx=3DRSA =C2=A0 =C2=A0 =C2=A0Au=3DRSA =C2=A0Enc=3DRC4(128) =C2= =A0Mac=3DSHA1

=C2=A0 =C2=A0 $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4= -'
=C2=A0 =C2=A0 111:RC4-SHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 SSLv3 Kx=3DRSA =C2=A0 =C2=A0 =C2=A0Au=3DRSA =C2=A0Enc=3DRC4(128) =C2= =A0Mac=3DSHA1

so TLS handshakes with these servers fail!

It is not clear what should be done here, the most practical
reordering and trimming that comes to mind is:

=C2=A0 =C2=A0 $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!= IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA= '
=C2=A0 =C2=A0 51:RC4-SHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 SSLv3 Kx=3DRSA =C2=A0 =C2=A0 =C2=A0Au=3DRSA =C2=A0Enc=3DRC4(128) =C2= =A0Mac=3DSHA1

Which does not leave much room for more ciphers. =C2=A0I've never seen<= br> DSS or DH certificates in the wild, but presumably they are needed
in some quarters, so this is likely not a generally applicable
solution.

I don't know how much longer such servers are likely to remain
active. =C2=A0Postfix users are working around this with custom cipher
exclusions in the per-destination TLS policy table on a case-by-case
basis. :-(

The best outcome would be if they all got upgraded! =C2=A0This will take some time I imagine.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

--001a11c2b01cabed2c04eb015c57-- From nico@cryptonector.com Tue Nov 12 14:07:41 2013 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 32D3011E8128 for ; Tue, 12 Nov 2013 14:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzEe4RuwF+Bc for ; Tue, 12 Nov 2013 14:07:34 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 81AC921E80E4 for ; Tue, 12 Nov 2013 14:07:33 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id EDC112005D112 for ; Tue, 12 Nov 2013 14:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=2FHOFnBEkHmX5Rlqh7wKLIIs0DM=; b=cayXkOBTgnF fM3ZchGEtXEy5VTj6yKH8Ewf6RfRDISeWJk+T0b1ywcRP+bSKgP4n2RL0Kpcy4Pg 3MDbOh/EoZas4Hz8FmB29UctPmXaKmvrUifhrfNt6qpXVt864AZszL3MkY26YBJu jWHUPdy+Cwelv/4e+9DlCxrkMdCSipVU= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 7AD842005D10B for ; Tue, 12 Nov 2013 14:07:32 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so2196886wgg.13 for ; Tue, 12 Nov 2013 14:07:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=Q6MS4Mpg++rGYlqXvrpH3jlk340FkA9YL8OGV83Oe9c=; b=KYTdqXcy6/Jrn7v39CR1oZga0Kd+ANU7pFvaNTXuNo0DB5qWi+CaE5nW4eWOsJTrB4 wnpWYlTN6GK2F9PHHh2GdkeAJJSse7xSTL83Pjrya6FANnp2xvjhPoAjXbPdpffvk//W xASAxeGOzhV5mu9QyOmdE6x66KMsiE5B6sIckx4+E7aYFUDJwuUcySSC4q2v5SHzBYgP nF8ByZctpaU25uzR6QlGPUMyvGQCnpApF89FYrUBESEhpk2lNc5Jf+rwQMNhyyA5hmpG ajncVW9oaNyBpNxyIArRtAnb8xng/kVJjoNQyTJF1NvOs1k+xmaaAiBTKgNreoZCWnrJ Ocjw== MIME-Version: 1.0 X-Received: by 10.180.184.112 with SMTP id et16mr18402350wic.4.1384294050865; Tue, 12 Nov 2013 14:07:30 -0800 (PST) Received: by 10.216.151.136 with HTTP; Tue, 12 Nov 2013 14:07:30 -0800 (PST) Date: Tue, 12 Nov 2013 16:07:30 -0600 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2269a2aac8a04eb0213e6 Subject: [kitten] Possible example where variable padding enctypes can break SSPI apps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:07:42 -0000 --001a11c2269a2aac8a04eb0213e6 Content-Type: text/plain; charset=UTF-8 See below. Viktor and i conjecture that this is an example of an SSPI app that breaks because of variable padding in 3DES-CBC TLS ciphersuites, and that that applies to Kerberos SSPI apps as well. ---------- Forwarded message ---------- From: *Nico Williams* Date: Thursday, November 7, 2013 Subject: Windows 2003 TLS 64 ciphersuite limit To: tls@ietf.org A non-subscriber (who doesn't want to subscribe just to send this) has asked me to forward this to the TLS WG list. Without further ado: From: Viktor Dukhovni > Subject: Windows 2003 TLS 64 ciphersuite limit Date: Thu, 7 Nov 2013 19:40:16 +0000 [ Please forward to TLS list ] While we're removing interoperability obstacles with TLSv1.2, ... There is another problem with expanded client HELLO messages. The Windows 2003 TLS stack (still used by a non-trivial number of Microsoft Exchange SMTP servers) only looks at the first 64 elements of the cipherlist. If neither RC4-SHA nor RC4-MD5 are among these, it sometimes chooses 3DES (for which it misimplements CBC padding) and fails during data transfer, or if that is suppressed or also too far down the list, just fails the handshake. With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4 at position: $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-' 93:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4-' 111:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 so TLS handshakes with these servers fail! It is not clear what should be done here, the most practical reordering and trimming that comes to mind is: $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA' 51:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Which does not leave much room for more ciphers. I've never seen DSS or DH certificates in the wild, but presumably they are needed in some quarters, so this is likely not a generally applicable solution. I don't know how much longer such servers are likely to remain active. Postfix users are working around this with custom cipher exclusions in the per-destination TLS policy table on a case-by-case basis. :-( The best outcome would be if they all got upgraded! This will take some time I imagine. -- Viktor. --001a11c2269a2aac8a04eb0213e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See below. =C2=A0Viktor and i conjecture that this is an example of an SSPI= app that breaks because of variable padding in 3DES-CBC TLS ciphersuites, = and that that applies to Kerberos SSPI apps as well.

---------- Forw= arded message ----------
From: Nico Williams
Date: Thursday, November 7, 2013
Subject:= Windows 2003 TLS 64 ciphersuite limit
To: tls@ietf.org


A non-subscriber (who doesn't want to su= bscribe just to send this) has
asked me to forward this to the TLS WG list. =C2=A0Without further ado:

From: Viktor Dukhovni <postfix-users@dukhovni.= org>
Subject: Windows 2003 TLS 64 ciphersuite limit
Date: Thu, 7 Nov 2013 19:40:16 +0000

[ Please forward to TLS list ]

While we're removing interoperability obstacles with TLSv1.2, ...
There is another problem with expanded client HELLO messages.

The Windows 2003 TLS stack (still used by a non-trivial number of
Microsoft Exchange SMTP servers) only looks at the first 64 elements
of the cipherlist. =C2=A0If neither RC4-SHA nor RC4-MD5 are among these, it sometimes chooses 3DES (for which it misimplements CBC padding)
and fails during data transfer, or if that is suppressed or also
too far down the list, just fails the handshake.

With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4
at position:

=C2=A0 =C2=A0 $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-&#= 39;
=C2=A0 =C2=A0 93:RC4-SHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 SSLv3 Kx=3DRSA =C2=A0 =C2=A0 =C2=A0Au=3DRSA =C2=A0Enc=3DRC4(128) =C2= =A0Mac=3DSHA1

=C2=A0 =C2=A0 $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4= -'
=C2=A0 =C2=A0 111:RC4-SHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 SSLv3 Kx=3DRSA =C2=A0 =C2=A0 =C2=A0Au=3DRSA =C2=A0Enc=3DRC4(128) =C2= =A0Mac=3DSHA1

so TLS handshakes with these servers fail!

It is not clear what should be done here, the most practical
reordering and trimming that comes to mind is:

=C2=A0 =C2=A0 $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!= IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA= '
=C2=A0 =C2=A0 51:RC4-SHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 SSLv3 Kx=3DRSA =C2=A0 =C2=A0 =C2=A0Au=3DRSA =C2=A0Enc=3DRC4(128) =C2= =A0Mac=3DSHA1

Which does not leave much room for more ciphers. =C2=A0I've never seen<= br> DSS or DH certificates in the wild, but presumably they are needed
in some quarters, so this is likely not a generally applicable
solution.

I don't know how much longer such servers are likely to remain
active. =C2=A0Postfix users are working around this with custom cipher
exclusions in the per-destination TLS policy table on a case-by-case
basis. :-(

The best outcome would be if they all got upgraded! =C2=A0This will take some time I imagine.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

--001a11c2269a2aac8a04eb0213e6-- From stephen.farrell@cs.tcd.ie Tue Nov 12 14:30:48 2013 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 F22F911E812B for ; Tue, 12 Nov 2013 14:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51VOuGbX8XJG for ; Tue, 12 Nov 2013 14:30:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CBB4311E810B for ; Tue, 12 Nov 2013 14:30:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D1CA4BE73 for ; Tue, 12 Nov 2013 22:30:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqzrHslJ2WWp for ; Tue, 12 Nov 2013 22:30:39 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.75.204]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB762BE6F for ; Tue, 12 Nov 2013 22:30:38 +0000 (GMT) Message-ID: <5282AC0E.80606@cs.tcd.ie> Date: Tue, 12 Nov 2013 22:30:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20131112203118.60E7A75E016@rfc-editor.org> In-Reply-To: <20131112203118.60E7A75E016@rfc-editor.org> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131112203118.60E7A75E016@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: [Editorial Errata Reported] RFC2743 (3797) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:30:48 -0000 FYI, comments welcome, if any. I assume this should be approved. S -------- Original Message -------- Subject: [Editorial Errata Reported] RFC2743 (3797) Date: Tue, 12 Nov 2013 12:31:18 -0800 (PST) From: RFC Errata System To: stephen.farrell@cs.tcd.ie, turners@ieca.com, jlinn@rsasecurity.com CC: kaduk@mit.edu, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC2743, "Generic Security Service Application Program Interface Version 2, Update 1". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2743&eid=3797 -------------------------------------- Type: Editorial Reported by: Benjamin Kaduk Section: 2.4.5 Original Text ------------- Outputs: o major_status INTEGER, o minor_status INTEGER, o output_name INTERNAL NAME -- caller must release with -- GSS_Release_name() Return major_status codes: o GSS_S_COMPLETE indicates that a valid name representation is output in output_name and described by the type value in output_name_type. Corrected Text -------------- Outputs: o major_status INTEGER, o minor_status INTEGER, o output_name INTERNAL NAME -- caller must release with -- GSS_Release_name() Return major_status codes: o GSS_S_COMPLETE indicates that a valid name representation is output in output_name. Notes ----- The description of the GSS_S_COMPLETE return value from GSS_Import_name() indicates that the contents of the output_name field are "described by the type value in output_name_type". There is no such output_name_type parameter. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2743 (draft-ietf-cat-rfc2078bis-08) -------------------------------------- Title : Generic Security Service Application Program Interface Version 2, Update 1 Publication Date : January 2000 Author(s) : J. Linn Category : PROPOSED STANDARD Source : Common Authentication Technology Area : Security Stream : IETF Verifying Party : IESG From kaduk@mit.edu Tue Nov 12 14:34:37 2013 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 4E70621F9C6A for ; Tue, 12 Nov 2013 14:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssdx56qTrg6j for ; Tue, 12 Nov 2013 14:34:31 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9246421E8090 for ; Tue, 12 Nov 2013 14:34:31 -0800 (PST) X-AuditID: 12074425-b7fd96d000000c39-d3-5282acf62876 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 2E.81.03129.6FCA2825; Tue, 12 Nov 2013 17:34:30 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rACMYUQX007673; Tue, 12 Nov 2013 17:34:30 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rACMYRim017727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Nov 2013 17:34:29 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rACMYRdX023693; Tue, 12 Nov 2013 17:34:27 -0500 (EST) Date: Tue, 12 Nov 2013 17:34:27 -0500 (EST) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <5282AC0E.80606@cs.tcd.ie> Message-ID: References: <20131112203118.60E7A75E016@rfc-editor.org> <5282AC0E.80606@cs.tcd.ie> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrPttTVOQQUejhcXRzatYLKbvvcbu wOSxtvsqm8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK2tcxhLJgvXtF0/TtjA+MsoS5GTg4JAROJ /Vses0PYYhIX7q1n62Lk4hASmM0ksa5vASuEs5FRYsuOdhaQKiGBQ0wSW/t4IRINjBKPJx0F a2cR0JZ4PGsuI4jNJqAiMfPNRjYQW0RAX2Lv5nNgNcwC6hLfzrwBqxEWcJX4NPsnK4jNCRT/ 3LuRCcTmFXCU2Ph8C9SyIInW14+ZQWxRAR2J1funsEDUCEqcnPmEBWKmpcS5P9fZJjAKzkKS moUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuhV5uZoleakrpJkZQqLK7qO5gnHBI6RCj AAejEg+vRUxTkBBrYllxZe4hRkkOJiVRXt0VQCG+pPyUyozE4oz4otKc1OJDjBIczEoivNLA CBHiTUmsrEotyodJSXOwKInz3uKwDxISSE8sSc1OTS1ILYLJynBwKEnwVoA0ChalpqdWpGXm lCCkmTg4QYbzAA1PABteXJCYW5yZDpE/xagoJc57bjVQQgAkkVGaB9cLSyWvGMWBXhHmTQZp 5wGmIbjuV0CDmYAGWxSDDS5JREhJNTAu+df9K6z8/NktvAomx5ielOfcXyP999na7pUbSi9c P943N+eX/ZfjWoz//9plfIm4n/Hk02OLtEV7nt49I5F5znjjhPmLPj2MY3h/flb0WdZcvWkm V9UffSjZ9zctdMbb0yo/PqW8n2gidW82g4m+u+6iqNIrSs/91ATcswJXTWB0+uf8o0tnkRJL cUaioRZzUXEiAIiU1zMAAwAA Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: [Editorial Errata Reported] RFC2743 (3797) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:34:37 -0000 The bogus text appears to be there from square 1 (draft-ietf-cat-genericsec-00), for what it's worth. -Ben On Tue, 12 Nov 2013, Stephen Farrell wrote: > > FYI, comments welcome, if any. I assume this should > be approved. > > S > > > -------- Original Message -------- > Subject: [Editorial Errata Reported] RFC2743 (3797) > Date: Tue, 12 Nov 2013 12:31:18 -0800 (PST) > From: RFC Errata System > To: stephen.farrell@cs.tcd.ie, turners@ieca.com, jlinn@rsasecurity.com > CC: kaduk@mit.edu, rfc-editor@rfc-editor.org > > The following errata report has been submitted for RFC2743, > "Generic Security Service Application Program Interface Version 2, > Update 1". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=2743&eid=3797 > > -------------------------------------- > Type: Editorial > Reported by: Benjamin Kaduk > > Section: 2.4.5 > > Original Text > ------------- > Outputs: > > o major_status INTEGER, > > o minor_status INTEGER, > > o output_name INTERNAL NAME -- caller must release with > -- GSS_Release_name() > > Return major_status codes: > > o GSS_S_COMPLETE indicates that a valid name representation is > output in output_name and described by the type value in > output_name_type. > > > Corrected Text > -------------- > Outputs: > > o major_status INTEGER, > > o minor_status INTEGER, > > o output_name INTERNAL NAME -- caller must release with > -- GSS_Release_name() > > Return major_status codes: > > o GSS_S_COMPLETE indicates that a valid name representation is > output in output_name. > > > Notes > ----- > The description of the GSS_S_COMPLETE return value from > GSS_Import_name() indicates that the contents of the output_name field > are "described by the type value in output_name_type". There is no such > output_name_type parameter. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2743 (draft-ietf-cat-rfc2078bis-08) > -------------------------------------- > Title : Generic Security Service Application Program > Interface Version 2, Update 1 > Publication Date : January 2000 > Author(s) : J. Linn > Category : PROPOSED STANDARD > Source : Common Authentication Technology > Area : Security > Stream : IETF > Verifying Party : IESG > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From mrex@sap.com Tue Nov 12 15:52:03 2013 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 1F96C21E80D5 for ; Tue, 12 Nov 2013 15:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEuC-FfQP9Bs for ; Tue, 12 Nov 2013 15:51:58 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8807321E8089 for ; Tue, 12 Nov 2013 15:51:58 -0800 (PST) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rACNprli002348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Nov 2013 00:51:53 +0100 (MET) In-Reply-To: <5282AC0E.80606@cs.tcd.ie> To: Stephen Farrell Date: Wed, 13 Nov 2013 00:51:53 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131112235153.73B531AA82@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: [Editorial Errata Reported] RFC2743 (3797) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 23:52:03 -0000 Stephen Farrell wrote: > > FYI, comments welcome, if any. I assume this should > be approved. > http://www.rfc-editor.org/errata_search.php?rfc=2743&eid=3797 > Type: Editorial > Reported by: Benjamin Kaduk > > Section: 2.4.5 GSS_Import_name > > [compressed summary of the change] > > - o GSS_S_COMPLETE indicates that a valid name representation is > - output in output_name and described by the type value in > - output_name_type. > > + o GSS_S_COMPLETE indicates that a valid name representation is > + output in output_name. I agree that the reference to the non-existing parameter output_name_type is a defect in the description for the GSS_S_COMPLETE result of GSS_Import_name. I'm slighlty confused by the expression "valid name representation is output". Admittedly, the descriptions of GSS_S_COMPLETE for the two calls GSS_Inquire_cred and GSS_Inquire_cred_by_mech also employ "represents": "the output cred_name .. represents .. the credentials's associated principal name" whereas other calls (GSS_Accept_sec_context, GSS_Inquire_context, GSS_Canonicalize_name, GSS_Duplicate_name) use expressions like "returns src_name", "src_name is valid" or "returns another reference (dest_name)" How about: o GSS_S_COMPLETE indicates that input_name_string was converted to an internal name and returned as output_name -Martin From kaduk@mit.edu Wed Nov 13 08:59:27 2013 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 48D5811E8119 for ; Wed, 13 Nov 2013 08:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5fqt2GpCNfR for ; Wed, 13 Nov 2013 08:59:21 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9F21F9FBC for ; Wed, 13 Nov 2013 08:59:21 -0800 (PST) X-AuditID: 1209190f-b7fb86d000000c36-ad-5283afe8785b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 06.C3.03126.8EFA3825; Wed, 13 Nov 2013 11:59:20 -0500 (EST) 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 rADGxIoI029864; Wed, 13 Nov 2013 11:59:19 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rADGxGua007516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Nov 2013 11:59:18 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rADGxGQr020533; Wed, 13 Nov 2013 11:59:16 -0500 (EST) Date: Wed, 13 Nov 2013 11:59:16 -0500 (EST) From: Benjamin Kaduk To: Martin Rex In-Reply-To: <20131112235153.73B531AA82@ld9781.wdf.sap.corp> Message-ID: References: <20131112235153.73B531AA82@ld9781.wdf.sap.corp> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixCmqrftifXOQwfZmW4ujm1exWPT+3sFs MX3vNXYHZo+13VfZPJYs+cnkMeXzVsYA5igum5TUnMyy1CJ9uwSujG8r5jAWLBCuuHz1FGsD 40X+LkZODgkBE4kZDUeYIWwxiQv31rN1MXJxCAnMZpL4N/MkC4SzkVHi8K3fjBDOISaJR81P mCCcBkaJKftfgvWzCGhL9N+Yxw5iswmoSMx8s5ENxBYRkJWYdu0NUDcHB7NArMSeZ4kgYWEB V4lPs3+ygoQ5BWwkLh4xAAnzCjhKfF+7CKxaSMBa4lG7MkhYVEBHYvX+KSwQJYISJ2c+AbOZ BSwlzv25zjaBUXAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcx gkNXkn8H47eDSocYBTgYlXh4H0Q2BQmxJpYVV+YeYpTkYFIS5a1Z1xwkxJeUn1KZkVicEV9U mpNafIhRgoNZSYS3dCFQjjclsbIqtSgfJiXNwaIkznuTwz5ISCA9sSQ1OzW1ILUIJivDwaEk wdsCMlSwKDU9tSItM6cEIc3EwQkynAdo+HWQGt7igsTc4sx0iPwpRkUpcd51IAkBkERGaR5c Lyy1vGIUB3pFmHcJSBUPMC3Bdb8CGswENNjFA2xwSSJCSqqBMf+izPaTljkPtoTcOvjKxt4g be805b/b/518NJdPb3q4zcm1eUkM2x6tvFGcvcGRM9ZE/N+6dMOYVz5vugNdF3Ge2v1zye7p R+6sib7TUfy4y8L84JEdfXxZOv8XFbU1zpe35fls//f60yJTnQSpva9P60yOkwngVJ7oPSmk 6WkFk45ntMP1RiWW4oxEQy3mouJEAMoKwsoIAwAA Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: [Editorial Errata Reported] RFC2743 (3797) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:59:27 -0000 On Wed, 13 Nov 2013, Martin Rex wrote: > Stephen Farrell wrote: >> >> FYI, comments welcome, if any. I assume this should >> be approved. > >> http://www.rfc-editor.org/errata_search.php?rfc=2743&eid=3797 >> Type: Editorial >> Reported by: Benjamin Kaduk >> >> Section: 2.4.5 GSS_Import_name >> >> [compressed summary of the change] >> >> - o GSS_S_COMPLETE indicates that a valid name representation is >> - output in output_name and described by the type value in >> - output_name_type. >> >> + o GSS_S_COMPLETE indicates that a valid name representation is >> + output in output_name. > > I agree that the reference to the non-existing parameter output_name_type > is a defect in the description for the GSS_S_COMPLETE result of > GSS_Import_name. > > > I'm slighlty confused by the expression "valid name representation is output". > Admittedly, the descriptions of GSS_S_COMPLETE for the two calls > GSS_Inquire_cred and GSS_Inquire_cred_by_mech also employ "represents": > "the output cred_name .. represents .. the credentials's associated principal > name" > whereas other calls (GSS_Accept_sec_context, GSS_Inquire_context, > GSS_Canonicalize_name, GSS_Duplicate_name) use expressions like > "returns src_name", "src_name is valid" or > "returns another reference (dest_name)" Phrasing like "valid [type] representation is available" is also used for GSS_S_COMPLETE returns from GSS_Display_status, GSS_Display_name, and GSS_Export_name. Admittedly, "available" and "output" are not the same word, but there seems to be some precedent in the document for the use of "representation" in this situation. > How about: > > o GSS_S_COMPLETE indicates that input_name_string was converted > to an internal name and returned as output_name I agree that this is a valid description of what a successful GSS_Import_name call should do, and I do prefer this style of writing. However, I don't know that the errata process is the right place for us to be enforcing our current ideas of writing style on a document that has already been edited and published. We seem to have found evidence that the writing style of RFC 2743 is internally inconsistent, so my preference is to stick with my original proposal, the smallest change to bring about correctness, which is internally consistent with at least some of the document's existing style. -Ben From kaduk@mit.edu Wed Nov 13 10:09:17 2013 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 38BDC21E80BE for ; Wed, 13 Nov 2013 10:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wKcP09uXU6n for ; Wed, 13 Nov 2013 10:09:10 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1611E8159 for ; Wed, 13 Nov 2013 10:09:04 -0800 (PST) X-AuditID: 1209190c-b7f7f6d000000bbd-84-5283c03eb416 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 45.B3.03005.E30C3825; Wed, 13 Nov 2013 13:09:02 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rADI91hh021932; Wed, 13 Nov 2013 13:09:02 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rADI8xPf003177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Nov 2013 13:09:01 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rADI8xVq029451; Wed, 13 Nov 2013 13:08:59 -0500 (EST) Date: Wed, 13 Nov 2013 13:08:59 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrGt3oDnIoPWfocXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGVcWJZccFKj4sj+iWwNjDsUuhg5OSQETCRW PljGBGGLSVy4t56ti5GLQ0hgNpPEg4V/oZyNjBJvHu5khnAOMUnM+fGGBcJpYJSYfOspI0g/ i4C2xPK+62Cz2ARUJGa+2cgGYosICEvs3vqOGcRmFtCU2NjVDmYLCwRK3N30CayeU8BRYunM Z+wgNi+QPfnEQqgFcxgldm98BJYQFdCRWL1/CgtEkaDEyZlPWCCGWkr8W/uLdQKj4CwkqVlI UgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaUbmIEB6skzw7GNweVDjEKcDAq 8fAW7mwOEmJNLCuuzD3EKMnBpCTKe2kPUIgvKT+lMiOxOCO+qDQntfgQowQHs5II7wKQHG9K YmVValE+TEqag0VJnPcmh32QkEB6YklqdmpqQWoRTFaGg0NJgvfnPqBGwaLU9NSKtMycEoQ0 EwcnyHAeoOFfQGp4iwsSc4sz0yHypxgVpcR5S0ASAiCJjNI8uF5YMnnFKA70ijCv2H6gKh5g IoLrfgU0mAlosIsH2OCSRISUVAOj3cWD735ceVWlF8tzSFr04In6rReFSn5umvzFdursbfN0 ymN3PFoUlb6hV/Rw5ZT5VyYvEPt/471F3W+p7e0ZGZ4bSv+5JJkcfuumEbVq0a+Fe22u/eis czn57ZhYu4S6VvynvVY891J+itg81+S9yHRZcE1uXCq796G8z83OTpyH9fPdbn/6r8RSnJFo qMVcVJwIAH6VhAEBAwAA Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:09:17 -0000 On Tue, 5 Nov 2013, Benjamin Kaduk wrote: > On Mon, 28 Oct 2013, Greg Hudson wrote: > >> Here are a couple of issues Ben and I discussed before the draft was >> submitted, which Ben thought we could use list input on: >> >> 1. Overlap with 2743 >> >> It wasn't immediately clear to me whether this draft is a distillation >> of RFC 2743 or whether it imposes new requirements. I think there might >> be some new requirements (like "The initiator MUST NOT change any of the >> input parameters to GSS_Init_sec_context() between calls", while 2743 >> only mentions the claimant_cred_handle parameter), but they aren't >> differentiated from repeated requirements. > > This is probably closely related to whether the new document ends up being > standards-track or just informational. If there are no new actual > requirements, it probably makes sense to have it just be informational. On > the other hand, maybe we do want requirements like the constancy of > init/accept_sec_context arguments through the loop (per (2)) to be added, in > which case it would need to go on the standards track. > > I will try to make time to do a close read of 2743 side-by-side with this > draft, but it would be helpful to have input from other reviewers, too. Having finished a 2743 re-read, it looks like the only "real" new requirement in the -00 of my draft is the one Greg quoted above, "the initiator MUST NOT change any of the input parameters to GSS_Init_sec_context() between calls" -- 2743 only requires that the claimant_cred_handle remain unchanged between calls. That seems like a bug in 2743 (what behavior would one want to get by changing things?), but I'll accept that my gss-loop document is not the right place to fix it. I haven't finished a 2744 re-read yet, but it seems to only note that "a typical portable caller should always invoke gss_init_sec_context within a loop", with pseudocode that shows all the input arguments to gss_init_sec_context() remaining unchanged between calls. It would be a stretch to interpret that as a normative requirement, though. I use 2119 langauge elsewhere in my document,for things like "MUST transmit the context token to the peer", "SHOULD send error tokens", and "MUST verify the returned flags", but I think that these can be read as reflecting existing requirements in 2743. (Since 2743 doesn't use 2119 language, judging what exactly the normative requirements are is a matter of interpretation, unfortunately.) Maybe I don't need to use 2119 language at all in a document like this. >> 2. Handling of impossible situations >> >> Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI >> returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty >> output token. This is a nonsense answer from the GSS implementation, >> indicative of a serious bug, and I don't think a spec like this needs to >> describe what applications should do in the face of bugs. I think most >> applications I have seen will just send an empty token to the other >> side, which will reject it, and that's not a problem. > > The thread seems to have mostly diverged into considering whether or not an > empty token would be appropriate. The volume of discussion makes me suspect > that mentioning it in some form is appropriate, though it's unclear that the > text in my -00 is correct. I also used 2119 language for "SHOULD indicate failure to the [peer]" when GSS_S_CONTINUE_NEEDED produces an empty token. The discussions we've had have convinced me that I should instead note that 2743 prohibits this behavior, but for compatibility with existing deployments, applications should [lowercase] transmit such an empty token and/or be prepared to accept one. >> 3. Example code >> >> The draft is written completely at the RFC 2743 level, independent of >> language bindings. I was sort of expecting a draft like this to have >> example code using the C bindings. There is already example code for >> gss_init_sec_context and gss_accept_sec_context in RFC 2744, but it >> could perhaps be improved to cover some of the statements in the draft, >> like checking ret_flags after the context is established. > > I agree that there would be value in example code, I was just not convinced > that it was necessary for the -00. It sounds like there is some WG interest > in the document; if we decide to adopt it, I'm happy to add example code. > Looking at the charter, this work seems to fall under "develop extensions > and/or updates to the GSS-API", but not any more specific items. -01 will include sample code, probably bits from 2744 with modification/correction. Greg noted in person that a separate sample code for the anonymous case would probably be useful, too; I'll try to do that. > On Mon, 28 Oct 2013, Nico Williams wrote: > >> I'll review later today in detail. I think pseudo-code would be nice to > > Hmm, maybe I should have sent a reminder sooner. I don't think we saw anything more from Nico on-list. Even a "looks okay" would be good, I think... -Ben From hartmans@painless-security.com Fri Nov 15 10:25:12 2013 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 AA46711E81F3; Fri, 15 Nov 2013 10:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI0uy-NhYJo3; Fri, 15 Nov 2013 10:25:05 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D07B811E8225; Fri, 15 Nov 2013 10:25:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9DEFF20540; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_kKLii6DRh1; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D20E0819E7; Fri, 15 Nov 2013 13:25:01 -0500 (EST) From: Sam Hartman To: kitten@ietf.org,emu@ietf.org, abfab@ietf.org Date: Fri, 15 Nov 2013 13:25:01 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Right place for ABFAB ephemeral keying X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 18:25:12 -0000 Hi. At the most recent ABFAB meeting I brought up the idea of adding ephemeral keying to ABFAB. This would provide the following: * Protect the EAP conversation between the peer and NAS (initiator and acceptor in GSS terms) * Provide a key to protect ABFAB negotiations * Prevent the EAP server or proxies between the EAP server and NAS from observing the resulting session This would help defeat fingerprinting by passive observers as well as minimize the damage that a passive server could do cooperating with the home EAP server. This is more valuable for ABFAB used in protocols like NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used within an TLS session for IMAP, XMPP or SMTP. Stephen thought the general idea of protecting ABFAB sounded good but would prefer that we get better protocol re-use and suggested we look into protecting EAP in general. I was dubious of that but suggested protecting Kerberos GSS in general as an option. After trying to work through how to protect either EAP or Kerberos, I've mostly concluded that I don't know how to get significant protocol re-use. However I do agree with Stephen that it would be better that get protocol re-use if we can still implement relatively quickly and meet all of the above protection goals for ABFAB. So, here are my thoughts on EAP and Kerberos: EAP. Ephemeral keying doesn't belong in an EAP method. EAP methods run between the peer and EAP server. We want PFS between the peer and NAS. The endpoints are wrong. We could insert a layer similar to ERP (the hokey produced EAP Reauthentication Protocol) between the peer and NAS. It's been a while since I've looked at ERP, but I seem to recall that ERP runs between the peer and an entity in the visited domain although it does have specific NAS support. That approach would be OK for ABFAB assuming it could be implemented efficiently. It would be a bit ugly because you want to start using the ephemeral key well before EAP has concluded. However, for lower layers that do complex keying after EAP concludes, it's probably the wrong approach. Also, ERP took a long time to specify. I don't want to commit to astandardization effort that complex. Kerberos. I was considering trying to share some tokens for ephemeral keying with Kerberos. keying wants ephemeral keing within a GSS mechanism. You could do that for Kerberos, although you'd need to take advantage of the not-widely-implemented extension to the magic checksum used by GSS for channel binding and (in that magic extension) other extensions. In ABFAb the framing would be different because our context tokens have subtokens. However we could use the same PDU. Except for two things. First, Kerberos probably would be happier with an ap-req and ap-rep extension than a GSS mechanism level extension. Secondly, Kerberos might well want to use pkinit data structures and possibly even run a stripped down client-server version of pkinit for the ephemeral keying. That's way too expensive in terms of implementation complexity if you don't already have a pkinit implementation sitting around. my conclusion from all this is that the right place to do ephemeral keying for an EAP protocol is in the lower layer and that unless I got something wrong or missed an alternative, ABFAb should do its own mechanism. Can anyone see a good way to get protocol re-use here? From jhutz@cmu.edu Fri Nov 15 11:01:22 2013 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 BB6E621F9F19 for ; Fri, 15 Nov 2013 11:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIbcP4NIPx6y for ; Fri, 15 Nov 2013 11:01:17 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id D234C21F9D2E for ; Fri, 15 Nov 2013 11:01:16 -0800 (PST) Received: from [192.168.202.142] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rAFJ1D9j017453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Nov 2013 14:01:14 -0500 (EST) Message-ID: <1384542073.3011.64.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Fri, 15 Nov 2013 14:01:13 -0500 In-Reply-To: <2946_1384539916_rAFIPEih012136_tsly54pjzeq.fsf@mit.edu> References: <2946_1384539916_rAFIPEih012136_tsly54pjzeq.fsf@mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [kitten] Right place for ABFAB ephemeral keying X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 19:01:22 -0000 On Fri, 2013-11-15 at 13:25 -0500, Sam Hartman wrote: > my conclusion from all this is that the right place to do ephemeral > keying for an EAP protocol is in the lower layer and that unless I got > something wrong or missed an alternative, ABFAb should do its own > mechanism. > > Can anyone see a good way to get protocol re-use here? I'm a little confused at this point about what the protocol stack looks like and where you want ephemeral keying. However, we've certainly had conversations in the past about adding wrap/MIC support and/or PFS to GSS mechanisms by using a stackable wrapper mech that does a DH exchange, authenticates it using the wrapped mech, and then uses the shared secret to provide per-message services. It seems like you could go a step further and also protect the wrapped mech's context establishment tokens. Of course, that would not hide the context establishment from an active MitM, but if done correctly, it would allow you to discover the MitM's presence before you use the resulting context for anything. -- Jeff From hartmans@painless-security.com Mon Nov 18 05:47:44 2013 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 711B711E8196; Mon, 18 Nov 2013 05:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG+TKseDHdUA; Mon, 18 Nov 2013 05:47:15 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8001911E81A6; Mon, 18 Nov 2013 05:47:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 7694E20548; Mon, 18 Nov 2013 08:46:35 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCmhVGWMmn0m; Mon, 18 Nov 2013 08:46:35 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 18 Nov 2013 08:46:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 44B9981BF1; Mon, 18 Nov 2013 08:46:51 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Mon, 18 Nov 2013 08:46:51 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: [kitten] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 13:47:44 -0000 We use token types 06 01 and 06 02 for initial context tokens. However, RFC 4121 section 4.4 reserves token ID 06 01 through 06 ff in order that you can unambiguously distinguish ASN.1 wrapped framing from other framing. Luke, was this an oops or was something more clever going on. In the specific case of draft-ietf-abfab-gss-eap, section 5 requires all our context tokens have the ASN.1 framing. So, testing the first octet for 06 to determine if ASN.1 framing is present is still a fine test so long as you don't do it recursively. I think we have a couple options: 1) Change the token types we use. I don't know if this is a viable option: I need to contact the moonshot community and figure out if people are willing to invalidate all existing deployments. My suspicion is There would be moderate to infinite push back on this. 2) Register 06 01 and 06 02, reserve 06 00 and 06 03 through 06 ff. I think option 2 is acceptable because our mechanism always happens to use ASN.1 framing. From tlyu@mit.edu Mon Nov 18 13:44:05 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE091AE598; Mon, 18 Nov 2013 13:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xeDcjUT15jj; Mon, 18 Nov 2013 13:44:04 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id EA6251AE597; Mon, 18 Nov 2013 13:44:03 -0800 (PST) X-AuditID: 12074424-b7fa56d000000be4-5c-528a8a1dc2f7 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 86.D8.03044.D1A8A825; Mon, 18 Nov 2013 16:43:57 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rAILhu0o008061; Mon, 18 Nov 2013 16:43:56 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAILhsNg020852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Nov 2013 16:43:55 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rAILhsx5006729; Mon, 18 Nov 2013 16:43:54 -0500 (EST) To: Sam Hartman References: From: Tom Yu Date: Mon, 18 Nov 2013 16:43:54 -0500 In-Reply-To: (Sam Hartman's message of "Mon, 18 Nov 2013 08:46:51 -0500") Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrCvb1RVk0LRE0OLj9TeMFjM9LY5u XsXiwOyxZMlPJo/Z31oZA5iiuGxSUnMyy1KL9O0SuDJu3L7JVtDMUvH85Bb2BsYFzF2MnBwS AiYS50+eYISwxSQu3FvP1sXIxSEkMJtJ4vSLq1DORkaJD3svglUJCZxjkjhySBMi0cUoMeHK DrBRIgIGEvNeHWMDsZkFlCUm/XrOAmILC3hK9B79zgLRrCqxdcJvpi5GDg42AWmJo4vLQMIs QOH/S86CtXIKJEt8WL4KzOYVsJCY8bYbbC+PAKfE7klb2SHighInZz5hgVilJXHj30umCYyC s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrpebWaKXmlK6iREUruwuKjsYmw8p HWIU4GBU4uGd4N4VJMSaWFZcmXuIUZKDSUmUV7IVKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE 93cpUI43JbGyKrUoHyYlzcGiJM57i8M+SEggPbEkNTs1tSC1CCYrw8GhJMG7oQOoUbAoNT21 Ii0zpwQhzcTBCTKcB2j4CZAa3uKCxNzizHSI/ClGRSlx3oMgCQGQREZpHlwvLJ28YhQHekWY 9zxIFQ8wFcF1vwIazAQ0+PjzNpDBJYkIKakGxvBpIax1KXOeRC5devN7spX+VaWPKxTCePM+ 1roqXXYTFiy3e2hz31XKuzaq6OMa9gA2yxvPFlb4nryeZvxCvfX2PYUj6/9w3uJ3WrhM7t+1 s6WaNuseieVr5xe9c6tj5cydonPmj038A4MTW5zWPG22WvXxwMdd/xYXW4pemFLHn6Cz5cRj DSWW4oxEQy3mouJEAHzszdQCAwAA Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:44:05 -0000 Sam Hartman writes: > We use token types 06 01 and 06 02 for initial context tokens. > > However, RFC 4121 section 4.4 reserves token ID 06 01 through 06 ff in > order that you can unambiguously distinguish ASN.1 wrapped framing from > other framing. RFC 4121 Section 4.4 reserves 60 00 through 60 FF. The BER identifier octet for "Application tag 0 (constructed)" is 0x60, not 0x06. (0x06 would be "Universal tag 6 (primitive)", also known as "OBJECT IDENTIFIER".) From mrex@sap.com Mon Nov 18 13:54:40 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86D21AE5E3; Mon, 18 Nov 2013 13:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alt880AkXjJP; Mon, 18 Nov 2013 13:54:39 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D0D251AE5F8; Mon, 18 Nov 2013 13:54:38 -0800 (PST) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAILsVGt026181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Nov 2013 22:54:31 +0100 (MET) In-Reply-To: To: Tom Yu Date: Mon, 18 Nov 2013 22:54:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131118215431.C9C651AAB2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Sam Hartman , abfab@ietf.org Subject: Re: [kitten] [abfab] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:54:40 -0000 Tom Yu wrote: > Sam Hartman writes: > > > We use token types 06 01 and 06 02 for initial context tokens. > > > > However, RFC 4121 section 4.4 reserves token ID 06 01 through 06 ff in > > order that you can unambiguously distinguish ASN.1 wrapped framing from > > other framing. > > RFC 4121 Section 4.4 reserves 60 00 through 60 FF. The BER identifier > octet for "Application tag 0 (constructed)" is 0x60, not 0x06. (0x06 > would be "Universal tag 6 (primitive)", also known as "OBJECT > IDENTIFIER".) Correct. 0x60 will be the first byte of a "generic framing" as it must be present on the initial context token as described in rfc2743, Section 3.1 Mechanism-independent token format (bottom of page 81) http://tools.ietf.org/html/rfc2743#page-81 1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that -- constructed form, definite length encoding follows. The Kerberos rfc1964 gssapi mechanism decided to (re-)use that generic framing on all context-level tokens, plus on all per-message tokens. rfc4121 dropped the generic framing on the per-message token, and the quoted rule (and exemption for token IDs (60 00 -- 60 ff) is to enable a cheap heuristic to recognize whether a generic framing is present on a Kerberos per-message token. -Martin From shawn.emery@oracle.com Mon Nov 18 22:30:17 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DBB1A1F6F for ; Mon, 18 Nov 2013 22:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8PKHGMyiEeS for ; Mon, 18 Nov 2013 22:30:15 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AD2BA1A1F62 for ; Mon, 18 Nov 2013 22:30:15 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAJ6U97d026442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Nov 2013 06:30:09 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAJ6U8Jl002408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Nov 2013 06:30:08 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAJ6U71N009628 for ; Tue, 19 Nov 2013 06:30:08 GMT Received: from [10.159.66.220] (/10.159.66.220) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Nov 2013 22:30:07 -0800 Message-ID: <528B05AF.1050201@oracle.com> Date: Mon, 18 Nov 2013 23:31:11 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [kitten] IETF 88 - Minutes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 06:30:17 -0000 We've uploaded the draft minutes from the Vancouver session here: http://www.ietf.org/proceedings/88/minutes/minutes-88-kitten Please provide any updates to us no later than December 5th in order to make the proceedings cutoff date. Shawn. -- kitten co-chair From hartmans@painless-security.com Tue Nov 19 07:00:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24161AE000; Tue, 19 Nov 2013 07:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e46CS-I78Nsl; Tue, 19 Nov 2013 07:00:13 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD211ADFE7; Tue, 19 Nov 2013 07:00:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3ECF420397; Tue, 19 Nov 2013 09:59:46 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeW2JukDTnKE; Tue, 19 Nov 2013 09:59:46 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 19 Nov 2013 09:59:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9075780C88; Tue, 19 Nov 2013 10:00:06 -0500 (EST) From: Sam Hartman To: mrex@sap.com References: <20131118215431.C9C651AAB2@ld9781.wdf.sap.corp> Date: Tue, 19 Nov 2013 10:00:06 -0500 In-Reply-To: <20131118215431.C9C651AAB2@ld9781.wdf.sap.corp> (Martin Rex's message of "Mon, 18 Nov 2013 22:54:31 +0100 (CET)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] An oops: we stomped on reserved RFC 4121 token types X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 15:00:15 -0000 Yes. I clearly was not awake yesterday and transposed the digits. Thanks Tom and martin for pointing that out. If only I hadn't also been equally alert while refactoring code yesterday morning. I did eventually get that fixed too:-) From kaduk@mit.edu Wed Nov 20 11:09:12 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845DC1AE43A for ; Wed, 20 Nov 2013 11:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63c0UDV09sgo for ; Wed, 20 Nov 2013 11:09:10 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7001AE403 for ; Wed, 20 Nov 2013 11:09:09 -0800 (PST) X-AuditID: 1209190d-b7ef66d000000c40-11-528d08cf8d9c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D2.A3.03136.FC80D825; Wed, 20 Nov 2013 14:09:03 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rAKJ921S005938 for ; Wed, 20 Nov 2013 14:09:03 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAKJ913e028721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Nov 2013 14:09:02 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAKJ91Hd011606; Wed, 20 Nov 2013 14:09:01 -0500 (EST) Date: Wed, 20 Nov 2013 14:09:00 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixG6nonueozfIYGO/jMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXb7JeaCzzwVa548YW9g3MPVxcjJISFgIvF0z0J2CFtM4sK9 9WxdjFwcQgKzmSQunLoElhASOM4osXZSBUTiBpPE5LXzWSGcBkaJNWd/glWxCGhLbDp2lQ3E ZhNQkZj5ZiOYLSIgLLF76ztmEFtYIEDi18rnYPW8Ao4S6ztfgdmiAjoSq/dPYYGIC0qcnPkE zGYWsJQ49+c62wRGvllIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p 3cQICidOSd4djO8OKh1iFOBgVOLhffC0J0iINbGsuDL3EKMkB5OSKG8JW2+QEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRFe749A5bwpiZVVqUX5MClpDhYlcd6bHPZBQgLpiSWp2ampBalFMFkZ Dg4lCd5oYNwICRalpqdWpGXmlCCkmTg4QYbzAA3PBKnhLS5IzC3OTIfIn2JUlBLnrWAHSgiA JDJK8+B6YfH+ilEc6BVhXneQdh5gqoDrfgU0mAloMLtkN8jgkkSElFQDY/Gmv+5Sj7ee+Sss foDxyWer178F/Oa9NNH079gYLPnJ5IiZzob/4kaZ99SrbfMk2vfpKscv+HdGQfdKcchZhRd6 aVbT+/6xB/9fZb3KacYUvryIJwmyM/fs3Ca5j/31pE8hvPzJHoWsTmxaRuZS///t2Hr7e84c zaMtTP37W8SYth5jXyx6X4mlOCPRUIu5qDgRAGfukr7SAgAA Subject: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:09:12 -0000 I submitted an -01 of the gss-loop document, with sample code. There's a duplicate line of source XML in section 2.5 which causes some duplicate text, it's fixed in my git already. Sorry about that. Comments welcome :) -Ben ---------- Forwarded message ---------- Date: Wed, 20 Nov 2013 11:03:24 -0800 From: internet-drafts@ietf.org To: Benjamin Kaduk Subject: New Version Notification for draft-kaduk-kitten-gss-loop-01.txt A new version of I-D, draft-kaduk-kitten-gss-loop-01.txt has been successfully submitted by Benjamin Kaduk and posted to the IETF repository. Filename: draft-kaduk-kitten-gss-loop Revision: 01 Title: Structure of the GSS Negotiation Loop Creation date: 2013-11-20 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-kaduk-kitten-gss-loop-01.txt Status: http://datatracker.ietf.org/doc/draft-kaduk-kitten-gss-loop Htmlized: http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kaduk-kitten-gss-loop-01 Abstract: This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From kaduk@mit.edu Wed Nov 20 14:45:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEACA1AE4BF for ; Wed, 20 Nov 2013 14:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSCTvel_8ZxH for ; Wed, 20 Nov 2013 14:45:36 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id C893D1AE078 for ; Wed, 20 Nov 2013 14:45:35 -0800 (PST) X-AuditID: 12074423-b7f2b6d000000ce1-12-528d3b896bc2 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 52.6A.03297.98B3D825; Wed, 20 Nov 2013 17:45:29 -0500 (EST) 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 rAKMjSnn030454 for ; Wed, 20 Nov 2013 17:45:28 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAKMjQcN029533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Nov 2013 17:45:28 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAKMjQKF010148; Wed, 20 Nov 2013 17:45:26 -0500 (EST) Date: Wed, 20 Nov 2013 17:45:26 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6nrttp3Rtk0PSP0+Lo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2PpqBXvBY/6KD2cesDcw3uLpYuTkkBAwkVg8+SAjhC0mceHe ejYQW0hgNpPEn9fREPZxRom29QVdjFxA9g0miUNnV7NAOA2MEl8nT2IBqWIR0Jb4ee4eO4jN JqAiMfPNRrBJIgLCEru3vmMGsYUFYiV+9awCq+EUcJJ4fXc2E4jNK+Aose7pRnaIbY4SXw6f AesVFdCRWL1/CgtEjaDEyZlPwGxmAUuJc3+us01gFJiFJDULSWoBI9MqRtmU3Crd3MTMnOLU ZN3i5MS8vNQiXTO93MwSvdSU0k2M4OBzUd7B+Oeg0iFGAQ5GJR7eB097goRYE8uKK3MPMUpy MCmJ8q6x7A0S4kvKT6nMSCzOiC8qzUktPsQowcGsJMJ7ngMox5uSWFmVWpQPk5LmYFES573F YR8kJJCeWJKanZpakFoEk5Xh4FCS4F1hBdQoWJSanlqRlplTgpBm4uAEGc4DNDwPpIa3uCAx tzgzHSJ/ilFRSpxXHCQhAJLIKM2D64Ulh1eM4kCvCPO2gFTxABMLXPcroMFMQIPZJbtBBpck IqSkGhiz2XfNO7LN8oic5kkvIQuWzuj2Pa+k8iJ/tWZsVBfjT7A8VvVkic1DD9fHJjx5T59z qWZH93v/WXDnmrx48M7j1/jKyhI4m/caX1p1v2Cq/bFPzBOCKz7/2Sdp/SRFpz6d25Q18OSr eYGHj1retgxjKm2MbQqYYHr0gQu/jttbuzAlp3lt2UosxRmJhlrMRcWJAJ8T+LvpAgAA Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:45:37 -0000 On Wed, 20 Nov 2013, Benjamin Kaduk wrote: > I submitted an -01 of the gss-loop document, with sample code. > There's a duplicate line of source XML in section 2.5 which causes some > duplicate text, it's fixed in my git already. Sorry about that. > > Comments welcome :) We had some discussion on IRC, with Nico, Simo, Tom, Greg, and me. It's unclear whether the src_name output of gss_accept_sec_context() is only intended to be populated on a GSS_S_COMPLETE return; if not, it is very easy to leak storage from earlier iterations when multiple calls are needed. We discussed whether (either at the abstract level or the C bindings) it is guaranteed to be safe to call gss_release_buffer() twice on the same buffer. It is required to set the length of the buffer to zero (but not to zero the value field), but also "Any buffer object returned by a GSS-API routine may be passed to gss_release_buffer (even if there is no storage associated with the buffer)." What exactly constitutes a "buffer object returned by a GSS-API routine" seems subject to interpretation. (There are many things that could have been done to make this situation better, but we don't hvae a time machine.) Buffers with length zero can be generated in lots of ways other than gss_release_buffer() (gss_init_sec_context(), gss_accept_sec_context(), gss_unwrap()). We're pretty sure that GSS_S_CONTINUE_NEEDED will not be set with any other major status bits (in the C API). Nico wanted sample Java code, too (anything we have bindings for, really). I don't think I can contribute such code, but would probably take it if someone else did. The send_token()/receive_token() routines are not very good examples. It is probably better to rewrite them to use sendmsg/recvmsg with socketpair, which also eliminates the need to add framing with the token length. (Other stuff about the current implenetation is bad, too, but that's not really relevant if it gets rewritten.) -Ben From ghudson@mit.edu Wed Nov 20 15:18:05 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE911AE1B8 for ; Wed, 20 Nov 2013 15:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_4ou_6HFmBe for ; Wed, 20 Nov 2013 15:18:04 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id C8C251AE071 for ; Wed, 20 Nov 2013 15:18:03 -0800 (PST) X-AuditID: 1209190d-b7ef66d000000c40-3b-528d4324f173 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 31.94.03136.4234D825; Wed, 20 Nov 2013 18:17:56 -0500 (EST) 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 rAKNHoD5001340; Wed, 20 Nov 2013 18:17:51 -0500 Received: from [18.101.8.171] (vpn-18-101-8-171.mit.edu [18.101.8.171]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAKNHn7p009496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 18:17:50 -0500 Message-ID: <528D431C.5020803@mit.edu> Date: Wed, 20 Nov 2013 18:17:48 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrqvi3BtkcGC7kcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsepjI3vBA66KCyvUGxgfcnQxcnJICJhIXPh7hQ3CFpO4cG89 kM3FISQwm0liQf9PJpCEkMBGRondU/QgEkeYJG7t2sgOkuAVUJP4NPMOC4jNIqAqMe/EUkYQ m01AWeLg2W9gcVGBIInjWycwQdQLSpyc+QQsLiJgLHH35w0wW1ggVuJXzyp2iGXlEq3vvrKC 2JwCThLnfhxngrhOUmLbomNgNcwCOhLv+h4wQ9jyEtvfzmGewCg4C8mKWUjKZiEpW8DIvIpR NiW3Sjc3MTOnODVZtzg5MS8vtUjXSC83s0QvNaV0EyMoVDkleXcwvjuodIhRgINRiYf3wdOe ICHWxLLiytxDjJIcTEqivApOvUFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhjrIFyvCmJlVWp RfkwKWkOFiVx3psc9kFCAumJJanZqakFqUUwWRkODiUJ3t+OQI2CRanpqRVpmTklCGkmDk6Q 4TxAw3eA1PAWFyTmFmemQ+RPMSpKifPqgFwkAJLIKM2D64WlkleM4kCvCPNygFTxANMQXPcr oMFMQIPZJbtBBpckIqSkGhjVf+yayCE78fbO2DOH21qF5MsilLffupMZu3tdb7N07Fsf1sjm vESHsHeal+0n3wlR/NJpMG1v9HadDOGeuKy//BryofLvPvTu7J1xNWtqwKJpkRe/sE38fPSE wyzlWbK3fOMmGP22M73w1vfBnL+Cpk3L4mfcTrxWcnZlkwUT4xJth+VT8h2UWIozEg21mIuK EwHkCF0vAAMAAA== Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 23:18:06 -0000 On 11/20/2013 05:45 PM, Benjamin Kaduk wrote: > We discussed whether (either at the abstract level or the C bindings) it > is guaranteed to be safe to call gss_release_buffer() twice on the same > buffer. I think that unfortunately it is not safe per the spec, although it is probably safe in every GSSAPI implementation. > The send_token()/receive_token() routines are not very good examples. > It is probably better to rewrite them to use sendmsg/recvmsg with > socketpair, which also eliminates the need to add framing with the token > length. I think the RFC should only include the do_initiator() and do_acceptor() functions. The sample code does not need to compile and run, only demonstrate how the API should be used and be a reasonable starting point for cut and paste. Adding questionable framing code runs the risk of people actually using it, and adding solid framing code would be too much verbiage. release_buffer() is needed, of course, unless we get rid of it somehow (perhaps by assuming that receive_token will free what's already there, and then just calling free() in cleanup). I would rather see anonymous handled as a runtime parameter than an #ifdef, which is distracting. "if ((ret_flags & GSS_C_ANON_FLAG) != GSS_C_ANON_FLAG)" can be simplified to "if (!(ret_flags & GSS_C_ANON_FLAG))", and similarly elsewhere. From mrex@sap.com Wed Nov 20 15:51:40 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92251AE5B1 for ; Wed, 20 Nov 2013 15:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Juv1fnby2GKY for ; Wed, 20 Nov 2013 15:51:37 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0751AE5C1 for ; Wed, 20 Nov 2013 15:51:37 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAKNpT4X007323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Nov 2013 00:51:29 +0100 (MET) In-Reply-To: To: Benjamin Kaduk Date: Thu, 21 Nov 2013 00:51:29 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 23:51:40 -0000 Benjamin Kaduk wrote: > Benjamin Kaduk wrote: >> >> I submitted an -01 of the gss-loop document, with sample code. >> There's a duplicate line of source XML in section 2.5 which causes some >> duplicate text, it's fixed in my git already. Sorry about that. >> >> Comments welcome :) > > We had some discussion on IRC, with Nico, Simo, Tom, Greg, and me. > > It's unclear whether the src_name output of gss_accept_sec_context() is > only intended to be populated on a GSS_S_COMPLETE return; if not, it is > very easy to leak storage from earlier iterations when multiple calls are > needed. It is up to the mechanism implementation at which point during the handshake the src_name output parameter from gss_accept_sec_context() is populated. The application caller MUST provide the exact same parameter as src_name to *ALL* iteration calls of gss_accept_sec_context() of a single handshake, and the gssapi mechanism implementation ought to actually "create" output values at most once during a handshake, independent of when it is returned. I actually had to look at the source to figure out what I had implemented in my gsskrb5.dll wrapper for the Microsoft Kerberos SSP. My implementation clears all output parameters on entry to gss_accept_sec_context(), returns scalars (ints) whenever they become available and memory-managed objects (src_name, delegated_cred) only on the final interation that returns GSS_S_COMPLETE. I believe that to be conservative and simple behaviour with the least potential for problems. An application caller to the context iterator functions ought to allocate the storage for all necessary/desired input and output parameters _before_ the first iterator call, and use that exact same storage for the entire handshake, i.e. until the iterator either completes (GSS_S_COMPLETE) or fails (everything else than COMPLETE and CONTINUE_NEEDED). Creating the storage for input or output parameters only temporarily for a singular invocation of either of the context iterator calls is dangerous, unsafe and will result in undefined behaviour and might result in unexpected handshakes or crashes. > > We discussed whether (either at the abstract level or the C bindings) it > is guaranteed to be safe to call gss_release_buffer() twice on the same > buffer. It is required to set the length of the buffer to zero (but not > to zero the value field), but also "Any buffer object returned by a > GSS-API routine may be passed to gss_release_buffer (even if there is no > storage associated with the buffer)." What exactly constitutes a "buffer > object returned by a GSS-API routine" seems subject to interpretation. What in particular causes your notion "seems subject to interprettion"? IMO, the specifications (rfc2743,rfc2744) are perfectly clear on this point. In the high-level GSS-API spec (rfc2743), output parameters are those parameters listed under "Outputs:", e.g. GSS_Init_sec_context: http://tools.ietf.org/html/rfc2743#page-42 In the GSS-API C-Bindings spec (rfc2744), output parameters are those that are tagged as "modify", whereas input parameters are those tagged as "read" in the first line of each parameter description, e.g. for gss_init_sec_context: http://tools.ietf.org/html/rfc2744#page-60 > > (There are many things that could have been done to make this situation > better, but we don't hvae a time machine.) Buffers with length zero can > be generated in lots of ways other than gss_release_buffer() > (gss_init_sec_context(), gss_accept_sec_context(), gss_unwrap()). Where do you see the problem? An output buffer with a zero length is allowed to have a NULL value pointer, and as an alternative, the gssapi mechanism could use a pointer to one central, static empty string. The one thing that a gssapi mechanism obviously ought to NOT do is invoking the implementation-specific behaviour of malloc(0). When the gssapi mechanism does not allocate memory for zero-length output buffers, then robust gss_release_buffer() is trivial to achieve, if the length is 0, do nothing and return GSS_S_COMPLETE. > > We're pretty sure that GSS_S_CONTINUE_NEEDED will not be set with any > other major status bits (in the C API). This is my understanding as well (Microsoft's SSPI might differ, they have an additional COMPLETE status beyond GSS-API for DCE interop). -Martin From kaduk@mit.edu Wed Nov 20 16:40:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3531ADFED for ; Wed, 20 Nov 2013 16:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OiQtiDqDshR for ; Wed, 20 Nov 2013 16:40:40 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id A78AD1ADFCD for ; Wed, 20 Nov 2013 16:40:39 -0800 (PST) X-AuditID: 12074425-b7fd96d000000c39-c2-528d5680c35b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id DD.34.03129.0865D825; Wed, 20 Nov 2013 19:40:32 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rAL0eVqo014572; Wed, 20 Nov 2013 19:40:32 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAL0eTw3005328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 19:40:30 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAL0eTgn025419; Wed, 20 Nov 2013 19:40:29 -0500 (EST) Date: Wed, 20 Nov 2013 19:40:28 -0500 (EST) From: Benjamin Kaduk To: Martin Rex In-Reply-To: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> Message-ID: References: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6notsQ1htkMOuRhsXRzatYLHp/72B2 YPJYsuQnk8eUz1sZA5iiuGxSUnMyy1KL9O0SuDK2r/3GWPBUp6Lt5yP2BsblKl2MnBwSAiYS q9+cZYGwxSQu3FvP1sXIxSEkMJtJ4t2cC0wQzkZGicZbs1ggnENMEo8mPGaGcBoYJbaf+c0K 0s8ioC2xafV1dhCbTUBFYuabjWwgtoiArMS0a28YQWxmAWGJ9edmMIPYwgKxEr96VoHVcwrY SNyfPB3M5hVwlLj9bRlYjZCAtcSNlT1g80UFdCRW75/CAlEjKHFy5hMWiJmWEv/W/mKdwCg4 C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRboWermZJXqpKaWbGMHB6qK6g3HCIaVD jAIcjEo8vA+e9gQJsSaWFVfmHmKU5GBSEuUtCegNEuJLyk+pzEgszogvKs1JLT7EKMHBrCTC G2MNlONNSaysSi3Kh0lJc7AoifPe4rAPEhJITyxJzU5NLUgtgsnKcHAoSfCuDAVqFCxKTU+t SMvMKUFIM3FwggznARqeDVLDW1yQmFucmQ6RP8WoKCXO+wwkIQCSyCjNg+uFJZNXjOJArwjz toFU8QATEVz3K6DBTECD2SW7QQaXJCKkpBoYLxXl+ijxChp19qn7Sfyb6xi2KuEK+5k7knOu ib5cxMLF6Xk/rcxR5tybcLWTbTf2zp0dpbptv3x2x/LU3a2Kcne2X3187ke7yGZr9T2vU5QX MV8Q63541WCdnOySuTP+OiT8XCj38Wj5lA7/lQ/ZVOZvuxbxRkrl44ybJnvyz+Y0xripP7n9 V4mlOCPRUIu5qDgRAJbSa14BAwAA Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 00:40:42 -0000 On Thu, 21 Nov 2013, Martin Rex wrote: > Benjamin Kaduk wrote: >> >> It's unclear whether the src_name output of gss_accept_sec_context() is >> only intended to be populated on a GSS_S_COMPLETE return; if not, it is >> very easy to leak storage from earlier iterations when multiple calls are >> needed. > > It is up to the mechanism implementation at which point during the > handshake the src_name output parameter from gss_accept_sec_context() > is populated. The application caller MUST provide the exact same > parameter as src_name to *ALL* iteration calls of gss_accept_sec_context() Having recently completed a re-read of RFC 2743 and RFC 2744 (*), I'm sad to say that I do not believe there is a normative reference to support the MUST, there. I really wish there was, but RFC 2743 only calls out the acceptor_cred_handle as being fixed between iterations. Hmm, I guess this is relevant, though: [...] verifies the incoming input_token and (following the successful completion of a context establishment sequence) returns the authenticated src_name and the mech_type used. So, that would indicate that src_name is only valid after successful context establishment. > of a single handshake, and the gssapi mechanism implementation ought > to actually "create" output values at most once during a handshake, > independent of when it is returned. Yes, it really ought to. We'll have to remember that for the next refresh of the spec. > An application caller to the context iterator functions ought to > allocate the storage for all necessary/desired input and output > parameters _before_ the first iterator call, and use that exact > same storage for the entire handshake, i.e. until the iterator > either completes (GSS_S_COMPLETE) > or fails (everything else than COMPLETE and CONTINUE_NEEDED). > > Creating the storage for input or output parameters only temporarily > for a singular invocation of either of the context iterator calls > is dangerous, unsafe and will result in undefined behaviour > and might result in unexpected handshakes or crashes. I agree. I do not think the current document mandates such sane behavior, though. >> We discussed whether (either at the abstract level or the C bindings) it >> is guaranteed to be safe to call gss_release_buffer() twice on the same >> buffer. It is required to set the length of the buffer to zero (but not >> to zero the value field), but also "Any buffer object returned by a >> GSS-API routine may be passed to gss_release_buffer (even if there is no >> storage associated with the buffer)." What exactly constitutes a "buffer >> object returned by a GSS-API routine" seems subject to interpretation. > > > What in particular causes your notion "seems subject to interprettion"? Nico was making arguments about how it is "torturing the language and common sense" to claim that gss_release_buffer() is "notionally output[ting] a buffer". I was claiming that (in the C bindings at least), the buffer parameter is an output parameter of gss_release_buffer(). Apparently this has been discussed previously, before I joined the list. If someone had a pointer to that handy, I would appreciate it > IMO, the specifications (rfc2743,rfc2744) are perfectly clear on this point. > > In the high-level GSS-API spec (rfc2743), output parameters > are those parameters listed under "Outputs:", > e.g. GSS_Init_sec_context: > > http://tools.ietf.org/html/rfc2743#page-42 > > In the GSS-API C-Bindings spec (rfc2744), output parameters > are those that are tagged as "modify", whereas input parameters > are those tagged as "read" in the first line of each parameter description, > e.g. for gss_init_sec_context: > > http://tools.ietf.org/html/rfc2744#page-60 I'm not sure why the particular page numbers linked are relevant. In any case, RFC 2743's description of GSS_Release_buffer() lists the 'buffer' argument as an Input, whereas RFC 2744's description of gss_release_buffer() lists the 'buffer' argument as 'modify' (an output). The matter seemed subject to interpretation because we could not come to an agreement about what the correct interpretation is. >> >> (There are many things that could have been done to make this situation >> better, but we don't hvae a time machine.) Buffers with length zero can >> be generated in lots of ways other than gss_release_buffer() >> (gss_init_sec_context(), gss_accept_sec_context(), gss_unwrap()). > > Where do you see the problem? > An output buffer with a zero length is allowed to have a NULL value pointer, > and as an alternative, the gssapi mechanism could use a pointer to > one central, static empty string. The one thing that a gssapi mechanism > obviously ought to NOT do is invoking the implementation-specific behaviour > of malloc(0). > > When the gssapi mechanism does not allocate memory for zero-length output > buffers, then robust gss_release_buffer() is trivial to achieve, > if the length is 0, do nothing and return GSS_S_COMPLETE. It is trivial to achieve, yes. Would an implementation that failed to do so be non-compliant with the RFC? Not everyone seems to agree. As Greg notes, all known implementations seem to be safe. -Ben (*) I also noticed that ~all of Appendix A of RFC 2744 (the sample gssapi.h header) has incorrect signatures for the listed functions. Basically, any pointer argument which is not in the final position, is not listed as a pointer type. It seems likely that a script to remove argument names was buggy. I'm not sure that I'm up to submitting a full erratum to note all the changes, though. From mrex@sap.com Wed Nov 20 17:14:57 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F571ACCE2 for ; Wed, 20 Nov 2013 17:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg0cnO0ojZGC for ; Wed, 20 Nov 2013 17:14:55 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 344A91ACCE0 for ; Wed, 20 Nov 2013 17:14:55 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAL1ElO7015152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Nov 2013 02:14:47 +0100 (MET) In-Reply-To: To: Benjamin Kaduk Date: Thu, 21 Nov 2013 02:14:47 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131121011447.8BE661AACA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:14:57 -0000 Benjamin Kaduk wrote: > >> It is required to set the length of the buffer to zero (but not > >> to zero the value field), but also "Any buffer object returned by a > >> GSS-API routine may be passed to gss_release_buffer (even if there is no > >> storage associated with the buffer)." What exactly constitutes a "buffer > >> object returned by a GSS-API routine" seems subject to interpretation. > > > > > > What in particular causes your notion "seems subject to interprettion"? > > Nico was making arguments about how it is "torturing the language and > common sense" to claim that gss_release_buffer() is "notionally > output[ting] a buffer". I was claiming that (in the C bindings at least), > the buffer parameter is an output parameter of gss_release_buffer(). The GSS-API C-Bindings decided to design the "gss_buffer_t" in a fashion that the container structure (gss_buffer_desc) is always owned by the application caller (_never_ by the gssapi mechanism). This is something that the high-level GSS-API does not imply, but allows. > > Apparently this has been discussed previously, before I joined the list. > If someone had a pointer to that handy, I would appreciate it I'm sorry, I don't have a pointer handy (and do not not consciously remember such a discussion at the moment). > > > IMO, the specifications (rfc2743,rfc2744) are perfectly clear on this point. > > > > In the high-level GSS-API spec (rfc2743), output parameters > > are those parameters listed under "Outputs:", > > e.g. GSS_Init_sec_context: > > > > http://tools.ietf.org/html/rfc2743#page-42 > > > > In the GSS-API C-Bindings spec (rfc2744), output parameters > > are those that are tagged as "modify", whereas input parameters > > are those tagged as "read" in the first line of each parameter description, > > e.g. for gss_init_sec_context: > > > > http://tools.ietf.org/html/rfc2744#page-60 > > I'm not sure why the particular page numbers linked are relevant. Just an example for comparison. rfc2743 is abstract. rfc2744 is one possible incarnation of a language binding. > > In any case, RFC 2743's description of GSS_Release_buffer() lists the > 'buffer' argument as an Input, whereas RFC 2744's description of > gss_release_buffer() lists the 'buffer' argument as 'modify' (an output). Well, OK, my rule-of-thumb fails in this special case for rfc2744. The abstract semantics of rfc2743 for GSS_Release_buffer() _still_ apply to the rfc2744 gss_release_buffer() language bindings. 'buffer' is an input parameter, and gss_release_buffer() is allowed (and typically will) modify the contents of the caller-owned gss_buffer_desc gss_release_buffer() will NEVER return a buffer. What gss_release_buffer() MUST do on success is zero the length field. What gss_release_buffer() is permitted (but not required) to do, is additionally set the value to NULL when zeroing the length field. > > The matter seemed subject to interpretation because we could not come to > an agreement about what the correct interpretation is. I'm slightly lost here. >> >> When the gssapi mechanism does not allocate memory for zero-length output >> buffers, then robust gss_release_buffer() is trivial to achieve, >> if the length is 0, do nothing and return GSS_S_COMPLETE. > > It is trivial to achieve, yes. Would an implementation that failed to do > so be non-compliant with the RFC? Not everyone seems to agree. As Greg > notes, all known implementations seem to be safe. While I do not remember any problems with gss_release_buffer(), some MIT Kerberos releases, most Solaris kerberos libs and some AIX kerberos libs crash with my gsstest tool, which indicates both, a lack of testing, a lack of robustness and a lack of conformance with rfc2744. 100% RFC-conformaning implementations are pretty rare for non-trivial specifications--and since most specifications do contain defects and/or inappropriate requirements, 100% conformance might not always be desirable. The difficulty is that different implementors typically choose to deliberately ignore different requirements, and the number of differences typically increases with the complexity of features, the number of defects in the spec and the number of invalid requirements that are in clear conflict with rfc2119 Section 6. > > (*) I also noticed that ~all of Appendix A of RFC 2744 (the sample > gssapi.h header) has incorrect signatures for the listed functions. > Basically, any pointer argument which is not in the final position, is not > listed as a pointer type. It seems likely that a script to remove > argument names was buggy. I'm not sure that I'm up to submitting a full > erratum to note all the changes, though. I'm not aware of any problem with that header file (aside from the invalid use of const for custom pointer types). -Martin From mrex@sap.com Wed Nov 20 17:23:51 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6E71AC43E for ; Wed, 20 Nov 2013 17:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVHVpcDjkv3w for ; Wed, 20 Nov 2013 17:23:50 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B10421AC403 for ; Wed, 20 Nov 2013 17:23:49 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAL1NgnA017416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Nov 2013 02:23:42 +0100 (MET) In-Reply-To: <20131121011447.8BE661AACA@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Thu, 21 Nov 2013 02:23:42 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131121012342.29CE81AACA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:23:51 -0000 Martin Rex wrote: > > > > (*) I also noticed that ~all of Appendix A of RFC 2744 (the sample > > gssapi.h header) has incorrect signatures for the listed functions. > > Basically, any pointer argument which is not in the final position, is not > > listed as a pointer type. It seems likely that a script to remove > > argument names was buggy. I'm not sure that I'm up to submitting a full > > erratum to note all the changes, though. > > I'm not aware of any problem with that header file (aside from the > invalid use of const for custom pointer types). Ooops, you're correct. Admittedly, I never tried to extract and use the header from rfc2744, and just looking at it again, I agree, it seems to have a few errors (lacking "*") in many of the output/modify function parameters --seemingly except for the last function parameter, where the "*" is usually present. -Martin From kaduk@mit.edu Wed Nov 20 17:37:59 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9468A1AC441 for ; Wed, 20 Nov 2013 17:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26WWpDQc41pU for ; Wed, 20 Nov 2013 17:37:58 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADD11A802B for ; Wed, 20 Nov 2013 17:37:51 -0800 (PST) X-AuditID: 12074425-b7fd96d000000c39-3a-528d63e8cb51 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.06.03129.8E36D825; Wed, 20 Nov 2013 20:37:44 -0500 (EST) 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 rAL1bh43006797; Wed, 20 Nov 2013 20:37:44 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAL1bfwc023188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 20:37:42 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAL1bfwF002731; Wed, 20 Nov 2013 20:37:41 -0500 (EST) Date: Wed, 20 Nov 2013 20:37:41 -0500 (EST) From: Benjamin Kaduk To: Martin Rex In-Reply-To: <20131121012342.29CE81AACA@ld9781.wdf.sap.corp> Message-ID: References: <20131121012342.29CE81AACA@ld9781.wdf.sap.corp> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrfsiuTfIYPp6TYujm1exWPT+3sHs wOSxZMlPJo8pn7cyBjBFcdmkpOZklqUW6dslcGWc3z+ZpeAqc8WyhTeYGhjfM3UxcnJICJhI 7Lu2jRHCFpO4cG89WxcjF4eQwGwmiXMXn7JDOBsZJZrvvGSGcA4xSbS0/WaBcBoYJRo3LWYF 6WcR0JZ49/IYmM0moCIx881GNhBbREBWYtq1N2A7mAWEJdafm8EMYgsLxEr86lnFDmJzCthI 7OhfCVbDK+Ao0dYwkQXEFhKwlphz8TVYvaiAjsTq/VNYIGoEJU7OfMICMdNS4tyf62wTGAVn IUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyhY2V1UdzBOOKR0 iFGAg1GJh/fB054gIdbEsuLK3EOMkhxMSqK8MxN7g4T4kvJTKjMSizPii0pzUosPMUpwMCuJ 8MZYA+V4UxIrq1KL8mFS0hwsSuK8tzjsg4QE0hNLUrNTUwtSi2CyMhwcShK8csCoFBIsSk1P rUjLzClBSDNxcIIM5wEa7gpSw1tckJhbnJkOkT/FqCglzns3CSghAJLIKM2D64Ulk1eM4kCv CPPqgLTzABMRXPcroMFMQIPZJbtBBpckIqSkGhgzpPr3heTzTCxgndKrvk5kR+uBrtaDouo9 6xjeunk6mrF8lThrNO0dP0+d46HNbgfaj58qSJ2Z5OmbpzeXQeT+x99x4Sw/0tcK/Tab5r8u oiagsvuW1/P+vVrBm5bfEQlQnPtF9Obl/A0Jznsv7Eg2qft86mLBhIxJx36vV9b283EtLXi8 x0OJpTgj0VCLuag4EQB9eODdAQMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:37:59 -0000 On Thu, 21 Nov 2013, Martin Rex wrote: > Admittedly, I never tried to extract and use the header from rfc2744, > and just looking at it again, I agree, it seems to have a few errors > (lacking "*") in many of the output/modify function parameters > --seemingly except for the last function parameter, where the "*" > is usually present. There is no comma following the name of the last parameter. That's the best we came up with on IRC, at least. -Ben From kaduk@mit.edu Wed Nov 20 17:45:23 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCF61ADBCF for ; Wed, 20 Nov 2013 17:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j7dzNUKBUDl for ; Wed, 20 Nov 2013 17:45:22 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 38CE61ADBE8 for ; Wed, 20 Nov 2013 17:45:22 -0800 (PST) X-AuditID: 12074425-b7fd96d000000c39-2a-528d65ab8884 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 36.66.03129.BA56D825; Wed, 20 Nov 2013 20:45:15 -0500 (EST) 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 rAL1jETw007378; Wed, 20 Nov 2013 20:45:15 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAL1jChY025201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Nov 2013 20:45:14 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAL1jAGl003713; Wed, 20 Nov 2013 20:45:10 -0500 (EST) Date: Wed, 20 Nov 2013 20:45:10 -0500 (EST) From: Benjamin Kaduk To: Martin Rex In-Reply-To: <20131121011447.8BE661AACA@ld9781.wdf.sap.corp> Message-ID: References: <20131121011447.8BE661AACA@ld9781.wdf.sap.corp> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrbs6tTfI4NoyWYujm1exWPT+3sHs wOSxZMlPJo8pn7cyBjBFcdmkpOZklqUW6dslcGXc/PmEteAUT8XaAxOZGhg7uboYOTkkBEwk Zpw8wQ5hi0lcuLeeDcQWEpjNJPGxU7CLkQvI3sgosaa1hRHCOcQkcbrvCxOE08AosWz1d5Yu Rg4OFgFtiVV/wkG62QRUJGa+2Qg2SURAVmLatTeMIDazgLDE+nMzmEFsYYFYiV89q8A2cwrY SHzb/ZEFxOYVcJT4uPgVM8QV1hL7V+wC6xUV0JFYvX8KVI2gxMmZT1ggZlpK/Fv7i3UCo+As JKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBAUqu4vqDsYJh5QO MQpwMCrx8D542hMkxJpYVlyZe4hRkoNJSZTXIbk3SIgvKT+lMiOxOCO+qDQntfgQowQHs5II b4w1UI43JbGyKrUoHyYlzcGiJM57i8M+SEggPbEkNTs1tSC1CCYrw8GhJMFblQLUKFiUmp5a kZaZU4KQZuLgBBnOAzR8H8hi3uKCxNzizHSI/ClGRSlxXk+QZgGQREZpHlwvLJG8YhQHekWY dzpIFQ8wCcF1vwIazAQ0mF2yG2RwSSJCSqqBsePm8V3Vb0/tdX3975qgWSqHSK3GmY0f3v3u E79z7+PsZ1ozrLedmM652mP7xNteMm9ariUvrLe9PUEr8ZyV5Cetad//O5nMnZshqZHsOmXm Z3HG6RkFKbd6PbeuaGnaEZq0v+mZjtatWVc6C0Ns5vw31LzwQPTubi2uUxfMmU+Ehfg/Prni l54SS3FGoqEWc1FxIgC1+Do//wIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:45:24 -0000 On Thu, 21 Nov 2013, Martin Rex wrote: > Benjamin Kaduk wrote: >> >> Apparently this has been discussed previously, before I joined the list. >> If someone had a pointer to that handy, I would appreciate it > > I'm sorry, I don't have a pointer handy (and do not not consciously > remember such a discussion at the moment). My summary of the IRC discussion may have been inaccurate, too; the previous discussions may have been about things like using different C types for input and output buffers, or indicating the provenance of a buffer within the structure (or by some other means). >> In any case, RFC 2743's description of GSS_Release_buffer() lists the >> 'buffer' argument as an Input, whereas RFC 2744's description of >> gss_release_buffer() lists the 'buffer' argument as 'modify' (an output). > > Well, OK, my rule-of-thumb fails in this special case for rfc2744. > > The abstract semantics of rfc2743 for GSS_Release_buffer() _still_ > apply to the rfc2744 gss_release_buffer() language bindings. I guess that's compelling, the 2744 text describing gss_release_buffer's applicability notwithstanding. So, we're left with Greg's assessment, "it is not safe per the spec, although it is probably safe in every GSSAPI implementation." Do we want to change the sample code to not rely on this behavior, or just note that it does so rely? > I'm slightly lost here. Tom and I had argued one way, and Nico the other. Neither side won the other over, in the IRC discussion. We've moved on since then, so it's probably not worth dwelling on. -Ben From mrex@sap.com Wed Nov 20 18:35:23 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA5C1ADED9 for ; Wed, 20 Nov 2013 18:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se4H8aN7y1jy for ; Wed, 20 Nov 2013 18:35:20 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA461A1F3F for ; Wed, 20 Nov 2013 18:35:20 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAL2ZCmh023157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Nov 2013 03:35:12 +0100 (MET) In-Reply-To: <20131121012342.29CE81AACA@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Thu, 21 Nov 2013 03:35:12 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131121023512.A7EA11AACA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 02:35:23 -0000 Martin Rex wrote: > Martin Rex wrote: > > > > > > (*) I also noticed that ~all of Appendix A of RFC 2744 (the sample > > > gssapi.h header) has incorrect signatures for the listed functions. > > > Basically, any pointer argument which is not in the final position, is not > > > listed as a pointer type. It seems likely that a script to remove > > > argument names was buggy. I'm not sure that I'm up to submitting a full > > > erratum to note all the changes, though. > > > > I'm not aware of any problem with that header file (aside from the > > invalid use of const for custom pointer types). > > Ooops, you're correct. > > Admittedly, I never tried to extract and use the header from rfc2744, > and just looking at it again, I agree, it seems to have a few errors > (lacking "*") in many of the output/modify function parameters > --seemingly except for the last function parameter, where the "*" > is usually present. The "*" on the output parameters in the Appendix A sample header file seem to have disappeared during I-D revision 05->06 of the C-bindings draft, they were present during -00 through -05: http://tools.ietf.org/rfcdiff?url2=rfc2744.txt&url1=draft-ietf-cat-gssv2-cbind-05.txt#diff0410 I put together my gssapi_2.h header in 1995 (-00) and didn't notice the corruption in Appendix A starting in cbind-06. A "fix" of that size appears somewhat huge for the errata process. Filing an errata that describes the nature of the problem--maybe including a suitable URL to rfcdiff like the one above for visualizing the problem, might be preferable. The formatting of the C-Bindings I-D changed considerably from 05->06, and apparently the gssapi.h sample header file in Appendix A got corrupted. Scanning my archives, the C-Bindings author even indicated that he had changed his I-D tooling. Unfortunately http://tools.ietf.org/rfcdiff didn't exist back then (and previous versions of drafts were also no longer accessible in the download directories (so unless you happened to have a previous copy...). : From: John Wray : Subject: New GSSAPI C-bindings draft : Date: Mon, 13 Jul 1998 10:41:05 -0400 : To: Ietf-cat-wg@lists.Stanford.EDU : : I've just submitted an updated C-bindings document, so expect : draft-ietf-cat-gssv2-cbind-06.txt to show up on the repositories in the : next couple of days. : : Changes from the previous version: : : Reformatting. Changing jobs meant I no longer have all : the nroff macros I used to use, so I took the opportunity : to migrate to a slightly more modern formatting program. : One unfortunate result of this is that diff-ing this version : against the previous one won't give much useful : information. : : Incorporation of the 2078bis alignments posted to the : list by Martin. : : A number of typos and clarification requests received : by e-mail (also from Martin). : : John Btw. there is another problem with the gssapi.h sample header file in rfc2744: for 64-bit, there exists a binary-incompatibility between the X/Open defined GSS-API C-bindings and the IETF-defined rfc2744 C-Bindings for "count" member of the gss_OID_set type: rfc2744: http://tools.ietf.org/html/rfc2744#page-84 typedef struct gss_OID_set_desc_struct { size_t count; gss_OID elements; } gss_OID_set_desc, *gss_OID_set; X/Open: http://archive.opengroup.org/publications/archive/CDROM/c441.pdf Page 45: typedef struct gss_OID_set_desc_struct{ int count; gss_OID elements; } gss_OID_set_desc, *gss_OID_set; -Martin From nico@cryptonector.com Wed Nov 20 21:01:49 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC901AE08C for ; Wed, 20 Nov 2013 21:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6na6m9mu725 for ; Wed, 20 Nov 2013 21:01:47 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE6251ADFE3 for ; Wed, 20 Nov 2013 21:01:47 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 4263526C05E; Wed, 20 Nov 2013 21:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tYhaNJOT8SDLkt Eme5cUzD2w0Ik=; b=qNrDhUFhBXSr/GVjt2Q8YsVa+HeGZqAs0FemHwiQQtT+A3 5QWdG8b9RmdvGT1+dnHx/2OYXx7Ks3OBehZplQnqov4hdHzS6z3IzUk5kP+isSSn N0aXY8hapEzEdzD3FxBh0haVkKL4c0yaT80rTWq8Oqz2NSuMPwO2JRfdHdrHc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id E1C0926C05B; Wed, 20 Nov 2013 21:01:40 -0800 (PST) Date: Wed, 20 Nov 2013 23:01:40 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20131121050138.GB3655@localhost> References: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 05:01:49 -0000 On Wed, Nov 20, 2013 at 07:40:28PM -0500, Benjamin Kaduk wrote: > On Thu, 21 Nov 2013, Martin Rex wrote: > >It is up to the mechanism implementation at which point during the > >handshake the src_name output parameter from gss_accept_sec_context() > >is populated. The application caller MUST provide the exact same > >parameter as src_name to *ALL* iteration calls of gss_accept_sec_context() > > Having recently completed a re-read of RFC 2743 and RFC 2744 (*), > I'm sad to say that I do not believe there is a normative reference > to support the MUST, there. I really wish there was, but RFC 2743 > only calls out the acceptor_cred_handle as being fixed between > iterations. Well, no other interpretation is sensible but the one that Martin gave. Anything else surely would have been mentioned, and, at any rate, would not be sensible. Why would the name of the initiator *as output to the application* vary as the security context token exchange progresses? Clearly allowing that makes no sense. That's not to say that the mechanism might not learn the initiator's name piecemeal, just that it can't output it piecemeal. > Hmm, I guess this is relevant, though: > [...] verifies the incoming input_token and > (following the successful completion of a context establishment > sequence) returns the authenticated src_name and the mech_type used. > So, that would indicate that src_name is only valid after successful > context establishment. Authentication is only complete when security context establishment completes. Until then anything that may be available (e.g., PROT_READY, channel binding state -- any and all ret_flags, src_name) is not authenticated. (The one exception that might make sense might be deleg_cred, but there's no purpose to treating it as an exception.) > >>We discussed whether (either at the abstract level or the C bindings) it > >>is guaranteed to be safe to call gss_release_buffer() twice on the same > >>buffer. It is required to set the length of the buffer to zero (but not > >>to zero the value field), but also "Any buffer object returned by a > >>GSS-API routine may be passed to gss_release_buffer (even if there is no > >>storage associated with the buffer)." What exactly constitutes a "buffer > >>object returned by a GSS-API routine" seems subject to interpretation. > > > >What in particular causes your notion "seems subject to interprettion"? > > Nico was making arguments about how it is "torturing the language > and common sense" to claim that gss_release_buffer() is "notionally > output[ting] a buffer". I was claiming that (in the C bindings at > least), the buffer parameter is an output parameter of > gss_release_buffer(). "Output" is an [notional] attribute of the function argument in the GSS abstract API and in the C bindings, not an attribute of the buffer type (sadly). The buffer is only an output of gss_release_buffer() in that this notionally permits gss_release_buffer() to modify the buffer. IF RFC2744 had specified proper const typedefs then we'd not say that the buffer is an output of that function, just that the input to it is not of a const type. And then the const-/not-const-ness of an argument would not merely be notional; it'd be specified in a way that the C tooling can understand. It is torturing the language to say that gss_release_buffer() outputs a token. It does not. It modifies a buffer structure to mark it as "empty", but that's it. There is a problem in that RFC2744 says that gss_release_buffer() must set the buffer's length to zero but only that it may set the pointer to NULL. This is a problem because malloc(0) may return a non-NULL pointer that must be free()ed, and so gss_release_buffer() called with a zero-length, non-NULL value buffer might well call free() on that value! Now, obviously the foregoing is not a problem because a) apps shouldn't be double-releasing things, and b) because providers shouldn't be idiotic: they must either set the value to NULL on buffer release or not free() it when length is zero (preferably both). Nico -- From nico@cryptonector.com Wed Nov 20 21:08:50 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833F31AE095 for ; Wed, 20 Nov 2013 21:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fliowrQLqwC for ; Wed, 20 Nov 2013 21:08:49 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 34F3C1AE0C4 for ; Wed, 20 Nov 2013 21:08:39 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id A45F42005D909; Wed, 20 Nov 2013 21:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=WJlWRPyKU7zdB8 SNSH9cnCw6qn8=; b=mNCc+JO4cUCkofseMlpZARNY3C97d3df40wQiO6RY6UW7m /8Xvi0tD07CIPkmMYwYCjEG3G/FR58XtuQGN5GggroVx3CMVhLjtY89ocVokmNhh Xa+v7dvEaVZd1q1U17IWLzaYy3scn6ZdOzctULN7m+LgGx8emMWVi8rl/bxcw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id 526A22005D907; Wed, 20 Nov 2013 21:08:32 -0800 (PST) Date: Wed, 20 Nov 2013 23:08:31 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20131121050830.GC3655@localhost> References: <20131121011447.8BE661AACA@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 05:08:50 -0000 On Wed, Nov 20, 2013 at 08:45:10PM -0500, Benjamin Kaduk wrote: > On Thu, 21 Nov 2013, Martin Rex wrote: > >Well, OK, my rule-of-thumb fails in this special case for rfc2744. > > > >The abstract semantics of rfc2743 for GSS_Release_buffer() _still_ > >apply to the rfc2744 gss_release_buffer() language bindings. I agree. Some details might naturally differ from RFC2743 for other language bindings, but at the end of the day they must roughly agree. In particular there are some important aspects: - outputs of security context establishment are only valid or authenticated when the context establishment completes - no language binding can change the synchronous nature of security context token exchanges - all the base features must be there (some mechs/providers might not provide some features, such as, e.g., confidentiality protection, but the programming language bindings of the abstract API must make it possible to provide those) - the providers own output buffers - the app owns input buffers There's probably more. Things are are not obviously required of bindings include things like manual memory management. Indeed, automatic memory management is not incompatible with the abstract API. > I guess that's compelling, the 2744 text describing > gss_release_buffer's applicability notwithstanding. Yes. > So, we're left with Greg's assessment, "it is not safe per the spec, > although it is probably safe in every GSSAPI implementation." And: apps shouldn't be double-releasing anything. > Do we want to change the sample code to not rely on this behavior, > or just note that it does so rely? Either way is fine with me. Nico -- From jhutz@cmu.edu Thu Nov 21 07:45:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF46B1AE217 for ; Thu, 21 Nov 2013 07:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4286j951BtoQ for ; Thu, 21 Nov 2013 07:45:39 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEE21AE168 for ; Thu, 21 Nov 2013 07:45:38 -0800 (PST) Received: from [192.168.202.142] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rALFjTaF025677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 10:45:30 -0500 (EST) Message-ID: <1385048728.6315.4.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Greg Hudson Date: Thu, 21 Nov 2013 10:45:28 -0500 In-Reply-To: <17813_1384989489_rAKNI8L6018086_528D431C.5020803@mit.edu> References: <17813_1384989489_rAKNI8L6018086_528D431C.5020803@mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:45:41 -0000 On Wed, 2013-11-20 at 18:17 -0500, Greg Hudson wrote: > On 11/20/2013 05:45 PM, Benjamin Kaduk wrote: > > We discussed whether (either at the abstract level or the C bindings) it > > is guaranteed to be safe to call gss_release_buffer() twice on the same > > buffer. > > I think that unfortunately it is not safe per the spec, although it is > probably safe in every GSSAPI implementation. > > > The send_token()/receive_token() routines are not very good examples. > > It is probably better to rewrite them to use sendmsg/recvmsg with > > socketpair, which also eliminates the need to add framing with the token > > length. > > I think the RFC should only include the do_initiator() and do_acceptor() > functions. The sample code does not need to compile and run, only > demonstrate how the API should be used and be a reasonable starting > point for cut and paste. Agree. -- Jeff From kaduk@mit.edu Thu Nov 21 08:02:30 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EBA1ADFF7 for ; Thu, 21 Nov 2013 08:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlOa0sX48jUk for ; Thu, 21 Nov 2013 08:02:28 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 33A081ADFF5 for ; Thu, 21 Nov 2013 08:02:28 -0800 (PST) X-AuditID: 12074423-b7f2b6d000000ce1-6f-528e2e8d910b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B6.01.03297.D8E2E825; Thu, 21 Nov 2013 11:02:21 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rALG2KR6026271; Thu, 21 Nov 2013 11:02:20 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rALG2HVw027175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Nov 2013 11:02:19 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rALG2HgA023703; Thu, 21 Nov 2013 11:02:17 -0500 (EST) Date: Thu, 21 Nov 2013 11:02:17 -0500 (EST) From: Benjamin Kaduk To: Martin Rex In-Reply-To: <20131121023512.A7EA11AACA@ld9781.wdf.sap.corp> Message-ID: References: <20131121023512.A7EA11AACA@ld9781.wdf.sap.corp> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrNur1xdk0DGbx+Lo5lUsFr2/dzA7 MHksWfKTyWPK562MAUxRXDYpqTmZZalF+nYJXBk/l05gLFjPV9F54AJbA+Mm7i5GTg4JAROJ LRPXskPYYhIX7q1nA7GFBGYzSay5EtDFyAVkb2SU6N/dygjhHGKSmHewCcppYJTYs+EzK0gL i4C2xKnmLhYQm01ARWLmm41go0QEZCWmXXvDCGIzCwhLrD83gxnEFhYwlJiy4TpYDaeAjcTN rtVMIDavgKPE+ZvvWCHOsJY4eKMHbKaogI7E6v1TWCBqBCVOznzCAjHTUuLcn+tsExgFZyFJ zUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyMoVNldlHcw/jmodIhR gINRiYf3wdOeICHWxLLiytxDjJIcTEqivNN0+4KE+JLyUyozEosz4otKc1KLDzFKcDArifB+ VQfK8aYkVlalFuXDpKQ5WJTEeW9x2AcJCaQnlqRmp6YWpBbBZGU4OJQkeLVAhgoWpaanVqRl 5pQgpJk4OEGG8wANNwap4S0uSMwtzkyHyJ9iVJQS5zUCSQiAJDJK8+B6YankFaM40CvCvN4g VTzANATX/QpoMBPQYHbJbpDBJYkIKakGxthwntINfJUt365r1FXUO0SfebZijy1f/QG2V0su NEh6/Z87nees1aRvC4+cdvno6x6uZWhzyDBQyt1fd5++ZKS5sV3t45lWk7abNGY8E+OTvSj0 ZsGbc4vPzmKI5WhUZfcS6nq79PHTde2Ppp5gsqx/IRZxUWxZUL+s5JUtbbsrPNdJP4zrUGIp zkg01GIuKk4EAKZrDSAAAwAA Cc: kitten@ietf.org Subject: Re: [kitten] RFC 2744 Appendix A erratum X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:02:30 -0000 [changed subject] On Thu, 21 Nov 2013, Martin Rex wrote: > > The "*" on the output parameters in the Appendix A sample header file > seem to have disappeared during I-D revision 05->06 of the C-bindings > draft, they were present during -00 through -05: > > http://tools.ietf.org/rfcdiff?url2=rfc2744.txt&url1=draft-ietf-cat-gssv2-cbind-05.txt#diff0410 Thanks for tracking down the version with the change (and the diff). > A "fix" of that size appears somewhat huge for the errata process. I agree. However, it seems that replacing " ," with " *," (all 68 occurrences) suffices to fix almost all of the problem. gss_export_name()'s minor_status parameter would not be caught by this replacement, but could be mentioned separately. > Filing an errata that describes the nature of the problem--maybe including > a suitable URL to rfcdiff like the one above for visualizing the problem, > might be preferable. I'll probably file an erratum with the old/new text I mentioned above and your rfcdiff URL at some point, maybe later today. > Btw. there is another problem with the gssapi.h sample header file > in rfc2744: for 64-bit, there exists a binary-incompatibility > between the X/Open defined GSS-API C-bindings and the IETF-defined > rfc2744 C-Bindings for "count" member of the gss_OID_set type: > > rfc2744: http://tools.ietf.org/html/rfc2744#page-84 > > typedef struct gss_OID_set_desc_struct { > size_t count; > gss_OID elements; > } gss_OID_set_desc, *gss_OID_set; > > > X/Open: http://archive.opengroup.org/publications/archive/CDROM/c441.pdf > Page 45: > > typedef struct gss_OID_set_desc_struct{ > int count; > gss_OID elements; > } gss_OID_set_desc, *gss_OID_set; Ugh. Thanks for mentioning it. -Ben From mrex@sap.com Thu Nov 21 08:08:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E711AE00A for ; Thu, 21 Nov 2013 08:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMjeGY_sJ38d for ; Thu, 21 Nov 2013 08:08:39 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C93D11ADFF6 for ; Thu, 21 Nov 2013 08:08:38 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rALG8VNR025820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Nov 2013 17:08:31 +0100 (MET) In-Reply-To: To: Benjamin Kaduk Date: Thu, 21 Nov 2013 17:08:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131121160831.13D751AACB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] RFC 2744 Appendix A erratum X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:08:41 -0000 Benjamin Kaduk wrote: > > On Thu, 21 Nov 2013, Martin Rex wrote: > > > > The "*" on the output parameters in the Appendix A sample header file > > seem to have disappeared during I-D revision 05->06 of the C-bindings > > draft, they were present during -00 through -05: > > > > http://tools.ietf.org/rfcdiff?url2=rfc2744.txt&url1=draft-ietf-cat-gssv2-cbind-05.txt#diff0410 > > Thanks for tracking down the version with the change (and the diff). > > > A "fix" of that size appears somewhat huge for the errata process. > > I agree. > However, it seems that replacing " ," with " *," (all 68 occurrences) > suffices to fix almost all of the problem. gss_export_name()'s > minor_status parameter would not be caught by this replacement, but could > be mentioned separately. > > > Filing an errata that describes the nature of the problem--maybe including > > a suitable URL to rfcdiff like the one above for visualizing the problem, > > might be preferable. > > I'll probably file an erratum with the old/new text I mentioned above and > your rfcdiff URL at some point, maybe later today. > > > Btw. there is another problem with the gssapi.h sample header file > > in rfc2744: for 64-bit, there exists a binary-incompatibility > > between the X/Open defined GSS-API C-bindings and the IETF-defined > > rfc2744 C-Bindings for "count" member of the gss_OID_set type: > > > > rfc2744: http://tools.ietf.org/html/rfc2744#page-84 > > > > typedef struct gss_OID_set_desc_struct { > > size_t count; > > gss_OID elements; > > } gss_OID_set_desc, *gss_OID_set; > > > > > > X/Open: http://archive.opengroup.org/publications/archive/CDROM/c441.pdf > > Page 45: > > > > typedef struct gss_OID_set_desc_struct{ > > int count; > > gss_OID elements; > > } gss_OID_set_desc, *gss_OID_set; > > Ugh. Thanks for mentioning it. I forgot: MIT Kerberos, HP-UX Kerberos, Solaris Kerberos, AIX Kerberos and our own ABI uses the gss_OID_set definition from rfc2744 (or the cbind-00 draft). In the /usr/include/xom.h header file on HP-UX 11.31 I no longer see any OID_set definition, and the /usr/include/gssapi/gssapi.h header file contains the rfc2744 variant with "size_t count". -Martin From jhutz@cmu.edu Thu Nov 21 08:10:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E5D1ADFD9 for ; Thu, 21 Nov 2013 08:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcE7KObtjFoT for ; Thu, 21 Nov 2013 08:09:58 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 622331ADFB6 for ; Thu, 21 Nov 2013 08:09:58 -0800 (PST) Received: from [192.168.202.142] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rALG9kdO005278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 11:09:48 -0500 (EST) Message-ID: <1385050186.6315.15.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Thu, 21 Nov 2013 11:09:46 -0500 In-Reply-To: <7346_1385010106_rAL51j7j007404_20131121050138.GB3655@localhost> References: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> <7346_1385010106_rAL51j7j007404_20131121050138.GB3655@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:10:00 -0000 On Wed, 2013-11-20 at 23:01 -0600, Nico Williams wrote: > On Wed, Nov 20, 2013 at 07:40:28PM -0500, Benjamin Kaduk wrote: > > On Thu, 21 Nov 2013, Martin Rex wrote: > > >It is up to the mechanism implementation at which point during the > > >handshake the src_name output parameter from gss_accept_sec_context() > > >is populated. The application caller MUST provide the exact same > > >parameter as src_name to *ALL* iteration calls of gss_accept_sec_context() > > > > Having recently completed a re-read of RFC 2743 and RFC 2744 (*), > > I'm sad to say that I do not believe there is a normative reference > > to support the MUST, there. I really wish there was, but RFC 2743 > > only calls out the acceptor_cred_handle as being fixed between > > iterations. > > Well, no other interpretation is sensible but the one that Martin gave. > Anything else surely would have been mentioned, and, at any rate, would > not be sensible. > > Why would the name of the initiator *as output to the application* vary > as the security context token exchange progresses? Perhaps there's some stackable thing during which the notion of initiator name is refined as control passes from one mech to another? That said, since we are writing advice to application implementors here, and not a mechanism, the question is not the wide range of what applications _might_ be allowed to do, but rather what we tell them they _should_ do. For initiators, the answer is relatively simple: of course you should allocate everything up front, pass the same arguments on every call, and not look at the outputs until context establishment is complete. Of course, there's the exception of prot_ready, which is AFAIK the only output whose semantics are explicitly defined even when the context is incomplete. For acceptors, things get a bit dicier, because you have acceptors like RXGK_GSSNegotiate, which get called once per round trip and want to be completely stateless in between. Fortunately for us, actually achieving that would require the ability to export partially-established contexts, which is already not well-defined. Therefore, we can advise that implementations have little choice but to retain some state, and thus might as well follow the same conservative approach: allocate everything up front, and don't look at anything other than prot_ready until the end. > It is torturing the language to say that gss_release_buffer() outputs a > token. It does not. It modifies a buffer structure to mark it as > "empty", but that's it. Indeed. At the abstract level, the buffer is not an output. In the specific case of the C bindings in RFC2744, the gss_buffer_t is modified, but that's not the same thing as the buffer being an output; it's just an artifact of the language bindings. -- Jeff From nico@cryptonector.com Thu Nov 21 10:31:10 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5252A1AE248 for ; Thu, 21 Nov 2013 10:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt8Sy7cSJtCY for ; Thu, 21 Nov 2013 10:31:09 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3CF1AE23F for ; Thu, 21 Nov 2013 10:31:09 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 60B82598081 for ; Thu, 21 Nov 2013 10:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=7YKK3ITLPa+Zr/klhXsU oPoLDRs=; b=VX3FKT6tXvDt4cSOfI58oaObFgGsGdQVUCcZMh3x+aBWJY7gIIoz +LWdbKndt6rz6qDyWzhRl0BCgk3jvEtenU6hPkRnq+746MZFk+0wjyGWs7my3jf2 AQlQ/+hZ6Y9KqAS+fME6AMPrwhYpXOhiHyEyAi0xNWidpTm2CnDmyDE= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 352AD59807A for ; Thu, 21 Nov 2013 10:30:53 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id cc10so110859wib.10 for ; Thu, 21 Nov 2013 10:30:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tyqeVTsgiWmuUkuMeM20Mf7f789cqZ7QlxHEGsG/Oho=; b=Xigz2tDL+UkIpeLKWLa1lOmGOUWRg33YqwXbF9CxD8/y2W5Opue74yCMaZJuEzTner 9y779sVUK7aYnTjqQUNQ4+t3kUyYry//Bb1CuyD2NnZNovNuP9sTlowtj1f3ID4Hvcio Gq0E0OQOt/c394efBtvQaRzGtn5PacOfvLDS+0e/y9Dr/KxzYQ/MOizfvFrru6G5tnes Td1aGhURV9Ttv1HaI0U8ir/mNIb1q4xY8gk+HiG/R73e7dx2+Yrv4PuxguFvaEuquJzE qQJSuliWCRzWlZws8DejSMsS0QUXIjXMhji3Hoyf9+a7wAkc9YAYCkSxz4Z09dbMETqO dYMQ== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr6991578wic.36.1385058650606; Thu, 21 Nov 2013 10:30:50 -0800 (PST) Received: by 10.216.151.136 with HTTP; Thu, 21 Nov 2013 10:30:50 -0800 (PST) In-Reply-To: <1385050186.6315.15.camel@destiny.pc.cs.cmu.edu> References: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> <7346_1385010106_rAL51j7j007404_20131121050138.GB3655@localhost> <1385050186.6315.15.camel@destiny.pc.cs.cmu.edu> Date: Thu, 21 Nov 2013 12:30:50 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 18:31:10 -0000 On Thu, Nov 21, 2013 at 10:09 AM, Jeffrey Hutzelman wrote: > On Wed, 2013-11-20 at 23:01 -0600, Nico Williams wrote: >> Why would the name of the initiator *as output to the application* vary >> as the security context token exchange progresses? > > Perhaps there's some stackable thing during which the notion of > initiator name is refined as control passes from one mech to another? I addressed that immediately after asking the question :) I believe the correct answer for a mechanism that builds knowledge of the initiator progressively (with each security context token round trip) is to output the name only when that process is complete. As for how to represent all the details learned about the initiator, that's what display syntax and name attributes are for. > That said, since we are writing advice to application implementors here, > and not a mechanism, the question is not the wide range of what > applications _might_ be allowed to do, but rather what we tell them they > _should_ do. Yes, but that requires considering the constraints on the mechglue/provider. In this case they must not output multiple src_names -- that's just not something existing apps are prepared to handle and makes no sense. > For acceptors, things get a bit dicier, because you have acceptors like > RXGK_GSSNegotiate, which get called once per round trip and want to be > completely stateless in between. Fortunately for us, actually achieving The mechglue/provider should either a) not output the src_name (and deleg cred) until complete, or b) once they output either *keep* outputing it until complete. Nothing else is safe w.r.t. existing applications. > that would require the ability to export partially-established contexts, > which is already not well-defined. Therefore, we can advise that > implementations have little choice but to retain some state, and thus > might as well follow the same conservative approach: allocate everything > up front, and don't look at anything other than prot_ready until the > end. No, the mechglue/provider must keep state as described above. Also, src_name can be left NULL -- the application can use gss_inquire_context() instead. So the only real problem here is deleg_cred_handle. Nico -- From kaduk@mit.edu Thu Nov 21 10:34:23 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8391AE1E9 for ; Thu, 21 Nov 2013 10:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8h30UKw4oAX for ; Thu, 21 Nov 2013 10:34:21 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8901AE0A2 for ; Thu, 21 Nov 2013 10:34:21 -0800 (PST) X-AuditID: 1209190e-b7efb6d000000bb9-a8-528e5226b07b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FE.CD.03001.6225E825; Thu, 21 Nov 2013 13:34:14 -0500 (EST) 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 rALIYDq9003905; Thu, 21 Nov 2013 13:34:13 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rALIYABe027975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Nov 2013 13:34:12 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rALIYA9j023164; Thu, 21 Nov 2013 13:34:10 -0500 (EST) Date: Thu, 21 Nov 2013 13:34:10 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> <7346_1385010106_rAL51j7j007404_20131121050138.GB3655@localhost> <1385050186.6315.15.camel@destiny.pc.cs.cmu.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrasW1Bdk8GSSiMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGXM/PKGpWANc8W032fZGxgvMnUxcnJICJhI PP7+hR3CFpO4cG89WxcjF4eQwGwmiQfb7rBCOBsZJb5OPA/lHGKSmHjwJDuE08AoMf37UmaQ fhYBbYnvD9aDzWITUJGY+WYjG4gtIqApcX3eUjCbWUBd4tuZN4wgtrBArMSvnlVA9RwcnAKB Ensep4CEeQUcJXZM6Qc7T0hgFZPEuUNCILaogI7E6v1TWCBqBCVOznzCAjHSUuLcn+tsExgF ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyM4VCX5djB+Pah0 iFGAg1GJh3eHZV+QEGtiWXFl7iFGSQ4mJVHecEegEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe r+pAOd6UxMqq1KJ8mJQ0B4uSOO9NDvsgIYH0xJLU7NTUgtQimKwMB4eSBO/zAKBGwaLU9NSK tMycEoQ0EwcnyHAeoOF3QGp4iwsSc4sz0yHypxgVpcR5t4AkBEASGaV5cL2wVPKKURzoFWHe 4yBVPMA0BNf9CmgwE9BgdslukMEliQgpqQbGvA//f2lsP3rVt2JpCafytukWR355Fm3I4vKY LXX3TVyy21Zbpd59UhvvC4lP/6zuc329hEHAp8otq56WBV5eZJFxcqtzXsB39f0HeVibjO6c NdIMM5nYGcqf08df/j06Tq6iIerWWvOkjskrG++yGyrV6MW5SS6JdNtRkhygaf58At+F/y1K LMUZiYZazEXFiQBL2V/UAAMAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 18:34:23 -0000 On Thu, 21 Nov 2013, Nico Williams wrote: > Also, src_name can be left NULL -- the application can use > gss_inquire_context() instead. So the only real problem here is > deleg_cred_handle. That's a good point. My sample code doesn't even use the returned value, just requested it on the grounds that it is a common thing to want. I'm somewhat inclined to modify the sample code to not request src_name. -Ben From nico@cryptonector.com Thu Nov 21 11:59:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B161AE17E for ; Thu, 21 Nov 2013 11:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-ipGZ0yeCqX for ; Thu, 21 Nov 2013 11:59:54 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 90C641AE14B for ; Thu, 21 Nov 2013 11:59:54 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id EBB22286059 for ; Thu, 21 Nov 2013 11:59:47 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 8073C286058 for ; Thu, 21 Nov 2013 11:59:46 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hm6so631063wib.4 for ; Thu, 21 Nov 2013 11:59:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PMUocsgDCK1jUz8SX1PcQ2Fl6lvuLuxKoL9S+zhKLw8=; b=IKuS659fxU+bliPEmKssiOISGgCQU6R9+sFMOowmTfMLOXJOcDqZiR30otaW9UF+DS gOT7sKtf/Je7wYUVI0GlBPUqly7Z7ppLLSBk57VRIGhwL9L6KixxV+wwxPOcYUyBS/nS Jypjghc4EssolAtI/Bc3SIwFBOOmWjgEkuw6Yy2+VNZL9DMSJBQ2hv8AE7s1lCOicbmb bC3oobfKPYqFcuJ3GQXC8eybI6pOel6nZNELaZqRaJ7Fq7eTzvTPTlAsMwoAiRxEwBED CF8dIOCmnspEIr6WEhziXaY66Q9F8MShHgrqwNKvbaB19UxSzvBrckNtWaapa4H3QLez qfDg== MIME-Version: 1.0 X-Received: by 10.194.123.8 with SMTP id lw8mr7118965wjb.40.1385063985543; Thu, 21 Nov 2013 11:59:45 -0800 (PST) Received: by 10.216.151.136 with HTTP; Thu, 21 Nov 2013 11:59:45 -0800 (PST) In-Reply-To: References: <20131120235129.7E4E71AACA@ld9781.wdf.sap.corp> <7346_1385010106_rAL51j7j007404_20131121050138.GB3655@localhost> <1385050186.6315.15.camel@destiny.pc.cs.cmu.edu> Date: Thu, 21 Nov 2013 13:59:45 -0600 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:59:55 -0000 On Thu, Nov 21, 2013 at 12:34 PM, Benjamin Kaduk wrote: > On Thu, 21 Nov 2013, Nico Williams wrote: >> Also, src_name can be left NULL -- the application can use >> gss_inquire_context() instead. So the only real problem here is >> deleg_cred_handle. > > > That's a good point. My sample code doesn't even use the returned value, > just requested it on the grounds that it is a common thing to want. > > I'm somewhat inclined to modify the sample code to not request src_name. That's fine. But we want devs who look at this code to know that they must provide an authorization function, so a bit of code inquiring the src name and a comment about the required authz check would be nice. Nico -- From ghudson@mit.edu Fri Nov 22 09:10:49 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E45C1AE14D for ; Fri, 22 Nov 2013 09:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jAVXxjwSXAG for ; Fri, 22 Nov 2013 09:10:48 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id EC9531ADFE2 for ; Fri, 22 Nov 2013 09:10:47 -0800 (PST) X-AuditID: 12074423-b7f2b6d000000ce1-48-528f9010cd50 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 84.28.03297.0109F825; Fri, 22 Nov 2013 12:10:40 -0500 (EST) 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 rAMHAdnD005410 for ; Fri, 22 Nov 2013 12:10:40 -0500 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAMHAcT1032735 for ; Fri, 22 Nov 2013 12:10:39 -0500 From: Greg Hudson To: kitten@ietf.org Date: Fri, 22 Nov 2013 12:10:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixCmqrSswoT/IoGWVvMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWriMvaCPq6KriVNrA2Mb9m7GDk5JARMJK5MOskKYYtJXLi3 nq2LkYtDSGA2k8S+3o2sEM5xRomrp+8yQTgdTBJXb65hBGlhE1CWOHj2GwuILSIgLLF76ztm EFtYwFli2YU9QHEODhYBVYnrC9VBwrwChhJ//z9lh7AFJU7OfALWyiygJXHj30umCYw8s5Ck ZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrppebWaKXmlK6iREUHOwuyjsY/xxUOsQo wMGoxMO7w7IvSIg1say4MvcQoyQHk5Io75S+/iAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzJ 9UA53pTEyqrUonyYlDQHi5I47y0O+yAhgfTEktTs1NSC1CKYrAwHh5IE70yQoYJFqempFWmZ OSUIaSYOTpDhPEDDm0FqeIsLEnOLM9Mh8qcYFaXEeYNBEgIgiYzSPLheWPS+YhQHekWYdwVI FQ8w8uG6XwENZgIazC7ZDTK4JBEhJdXAyHzNIObFtbKm1QqXnof/s+yLWxLTKRGQyOvxrDFo T8D9CyflFLbHXVq0c4ek+mdPPc2K93v33lDuyG2bP3Nm6p3nxb8X/Vxk65P0cmd80C4p8epd dTITH903/uL9Z5IlW8RmxR0WK316RVZXOz1T6q86e0+OOzCI6b+3jubT0zqVnf8eHLx5Qoml OCPRUIu5qDgRAG0mZPu5AgAA Subject: [kitten] Proposal to change requirements for anonymous TGS requests X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 17:10:49 -0000 Since I believe we plan to re-issue RFC 6112 to address the KeyExchange vs. KEYEXCHANGE error, I would like to bring up another issue which I noticed today. Section 4.2 says: If the ticket in the PA-TGS-REQ of the TGS request is an anonymous one, the anonymous KDC option MUST be set in the request. Otherwise, the KDC MUST return a KRB-ERROR message with the code KDC_ERR_BADOPTION. MIT krb5 does not comply with this requirement on the client side and does not check it in the KDC. We can change that on the client, but in general this requirement seems totally unnecessary, and the KDC side of it seems to be a clear violation of RFC 2119 section 6. I propose changing this text in the re-issued RFC to: If the ticket in the PA-TGS-REQ of the TGS request is an anonymous one, the anonymous KDC option SHOULD be set in the request. So the first MUST becomes a SHOULD, and the second sentence goes away. If people feel that there should be a rationale for the SHOULD, I would suggest this text instead: If the ticket in the PA-TGS-REQ of the TGS request is an anonymous one, the anonymous KDC option SHOULD be set in the request, as a previous version of this specification required the KDC to reject the TGS request otherwise. From kaduk@mit.edu Mon Nov 25 19:22:58 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533491AE103 for ; Mon, 25 Nov 2013 19:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYs3YBXCRRqh for ; Mon, 25 Nov 2013 19:22:56 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF091ADFEF for ; Mon, 25 Nov 2013 19:22:56 -0800 (PST) X-AuditID: 12074425-b7fd96d000000c39-f7-5294140fa118 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 6E.ED.03129.F0414925; Mon, 25 Nov 2013 22:22:56 -0500 (EST) 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 rAQ3MsVG021882; Mon, 25 Nov 2013 22:22:55 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAQ3Mq1e024215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Nov 2013 22:22:54 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAQ3MqIa022720; Mon, 25 Nov 2013 22:22:52 -0500 (EST) Date: Mon, 25 Nov 2013 22:22:52 -0500 (EST) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <528D431C.5020803@mit.edu> Message-ID: References: <528D431C.5020803@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixG6nrisgMiXI4IqNxdHNq1gcGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJVx5OIN1oLTohXLj+xkbmDcINjFyMkhIWAicbTvKSuELSZx4d56 ti5GLg4hgdlMEgeaP0E5Gxkljp35wwjhHGKSONY/jRXCaWCUWHaiiRGkn0VAW+L6zxksIDab gIrEzDcb2UBsEQFFid8r34LVMAsIS6w/N4MZxBYWiJX41bOKHcTmFFCX2Hp/PlicV8BRYvv2 J0wQCyYxStz7NxWsSFRAR2L1/iksEEWCEidnPmGBGGop8W/tL9YJjIKzkKRmIUktYGRaxSib klulm5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERyYLqo7GCccUjrEKMDBqMTDK9E5OUiI NbGsuDL3EKMkB5OSKO9f/ilBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4Xe8DlfOmJFZWpRbl w6SkOViUxHlvcdgHCQmkJ5akZqemFqQWwWRlODiUJHiFhYGGChalpqdWpGXmlCCkmTg4QYbz AA13FgKq4S0uSMwtzkyHyJ9iVJQS53UHaRYASWSU5sH1whLHK0ZxoFeEeVeAtPMAkw5c9yug wUxAg7uMQK4uLklESEk1MB5L02s9lS2gHV8jLH32wqH7d5/G8qpvYndZaf07Nf6V58Eb7Cx2 /hK950Qm8Tt8jtzyKe7YBH8pvZuropUNWo+3rzy26WjTjdPLFLcc22/ffMFoz79qu6JyHUWV LS4dT8reHYo2+Pn7B/fpKfrtv9S7f77pZvXLmGcRJufv/Z3/3cJdUeaJnUosxRmJhlrMRcWJ ABnX5En3AgAA Cc: kitten@ietf.org Subject: Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-01.txt (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 03:22:58 -0000 On Wed, 20 Nov 2013, Greg Hudson wrote: > On 11/20/2013 05:45 PM, Benjamin Kaduk wrote: > >> The send_token()/receive_token() routines are not very good examples. >> It is probably better to rewrite them to use sendmsg/recvmsg with >> socketpair, which also eliminates the need to add framing with the token >> length. > > I think the RFC should only include the do_initiator() and do_acceptor() > functions. The sample code does not need to compile and run, only > demonstrate how the API should be used and be a reasonable starting > point for cut and paste. Adding questionable framing code runs the risk > of people actually using it, and adding solid framing code would be too > much verbiage. release_buffer() is needed, of course, unless we get rid > of it somehow (perhaps by assuming that receive_token will free what's > already there, and then just calling free() in cleanup). How would you feel about having stub routines send_token()/receive_token() which are just comments indicating what an implementation of them should do? My original intention in including these routines was in fact to have sample code that would compile (and maybe run, if the mechanism supports nameless initiators), to make it as clear as possible what was necessary for an application implementation. Subsequent discussion has convinced me that (as you say) including an actual implementation of those routines is unwise, but I would still like to be as explicit as possible what is necessary for applications. A stub routine with comment seems like it could be more clear than just a call to an unimplemented routine with an argument 'readfd' or 'writefd'. I will still have an implementation locally, so that I can test the sample code -- it wouldn't do to include buggy sample code. > I would rather see anonymous handled as a runtime parameter than an > #ifdef, which is distracting. We had previously discussed having separate sample code for the anonymous and non-anonymous case, but as I was writing it seemed like the differences were so small that duplicating everything was not worth it. However, I still wanted to make clear that if an application did not care about supporting anonymous initiators, the code in question could be removed; using a preprocessor conditional seemed the clearest way to do so. I don't think the sense of "this code can be entirely removed" is as clear with a C-level conditional. > "if ((ret_flags & GSS_C_ANON_FLAG) != GSS_C_ANON_FLAG)" can be > simplified to "if (!(ret_flags & GSS_C_ANON_FLAG))", and similarly > elsewhere. This is true. If you think it is more clear to write it that way, I guess I can change it for the next revision. -Ben From mrex@sap.com Wed Nov 27 14:59:35 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01ECA1ADFA4 for ; Wed, 27 Nov 2013 14:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW8TqZEfqC7p for ; Wed, 27 Nov 2013 14:59:33 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9D1ADF9A for ; Wed, 27 Nov 2013 14:59:32 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rARMxVEJ019076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Nov 2013 23:59:31 +0100 (MET) To: kitten@ietf.org Date: Wed, 27 Nov 2013 23:59:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131127225931.08F211AB0B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Subject: [kitten] OT: MS Kerb constrained delegation, tickets with KRB_NT_ENTERPRISE X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 22:59:35 -0000 Sorry for a slightly OT question about a Kerberos protocol/interop issue. What is the exact purpose and semantics of a Kerberos Ticket that contains a KRB_NT_ENTERPRISE cname for the receiver of the AP_REQ (the acceptor)? The usage scenario is Microsoft Kerberos using constrained delegation (a web server plugin in some Sharepoint environment). That web server plugin was written in .NET and passes the Client UPN it receives from Sharepoint "User@example.com" to "S4UClient.UpnLogon()", and according to the Wireshark trace, results in a KRB_TGS_REP with http://tools.ietf.org/html/rfc4120#section-5.4.2 crealm = "EXAMPLE.COM" cname = { KRB_NT_ENTERPRISE, "User@example.com" } When a Microsoft Kerberos Acceptor processes the resulting AP_REQ, it appears to return "User@EXAMPLE.COM@EXAMPLE.COM" from QueryContextAttributes(NATIVE_NAMES), which will be rejected by the application caller since it does not match the name as it appears on the ACL ("User@EXAMPLE.COM"). When the Webserver plugin is modified to strip the domain/realm before passing it to S4UClient.UpnLogon(), then the resulting ticket seems to contain: crealm = "EXAMPLE.COM" cname = { KRB_NT_ENTERPRISE, "User" } and the Microsoft Kerberos Acceptor will return "User@EXAMPLE.COM" from QueryContextAttributes(NATIVE_NAMES), i.e. something that the server can match. I believe something is going wrong, but wondering where: - client/initiator in creating KRB_TGS_REQ ? - KDC in creating KRB_TGS_REP ? - server/acceptor in processing AS_REQ and creating (the equivalent of) src_name for gss_accept_sec_context ? My world is GSS-API and I'm no Kerberos protocol wrangler. This issue was reported to me by a customer, I have no personal experience with programming .NET, IIS-plugins and constrained delegation. But my "gsskrb5.dll" wrapper for the Microsoft Kerberos SSP was used during impersonation/delegation for authenticating to our backend application, and the wrong Username popped up at the backend. -Martin From Josh.Howlett@ja.net Thu Nov 28 03:52:24 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20DF1AE0D1; Thu, 28 Nov 2013 03:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dueuhi522cT3; Thu, 28 Nov 2013 03:52:21 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 907CF1AE0CF; Thu, 28 Nov 2013 03:52:21 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0A5544A6BA0_2972E74B; Thu, 28 Nov 2013 11:52:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id A21944A6B1C_2972E72F; Thu, 28 Nov 2013 11:52:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 11:52:18 +0000 From: Josh Howlett To: Sam Hartman , "kitten@ietf.org" , "emu@ietf.org" , "abfab@ietf.org" Thread-Topic: [Emu] Right place for ABFAB ephemeral keying Thread-Index: AQHO4jAYN1MIKnIBekG46BO4ULt9e5o6nCiA Date: Thu, 28 Nov 2013 11:52:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <8687A9390B2F9F429FD8BEC1958F0720@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [kitten] [Emu] Right place for ABFAB ephemeral keying X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:52:24 -0000 Sam, I agree with your conclusion. There are example of lower layers using EAP-based ephemeral keying, and ABFAB could perhaps look to those for inspiration and perhaps reuse. Josh. On 16/11/2013 02:25, "Sam Hartman" wrote: > >Hi. >At the most recent ABFAB meeting I brought up the idea of adding >ephemeral keying to ABFAB. >This would provide the following: > >* Protect the EAP conversation between the peer and NAS (initiator and > acceptor in GSS terms) > >* Provide a key to protect ABFAB negotiations > >* Prevent the EAP server or proxies between the EAP server and NAS from > observing the resulting session > >This would help defeat fingerprinting by passive observers as well as >minimize the damage that a passive server could do cooperating with the >home EAP server. This is more valuable for ABFAB used in protocols like >NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used >within an TLS session for IMAP, XMPP or SMTP. > > >Stephen thought the general idea of protecting ABFAB sounded good but >would prefer that we get better protocol re-use and suggested we look >into protecting EAP in general. I was dubious of that but suggested >protecting Kerberos GSS in general as an option. > >After trying to work through how to protect either EAP or Kerberos, I've >mostly concluded that I don't know how to get significant protocol >re-use. However I do agree with Stephen that it would be better that >get protocol re-use if we can still implement relatively quickly and >meet all of the above protection goals for ABFAB. > >So, here are my thoughts on EAP and Kerberos: > >EAP. Ephemeral keying doesn't belong in an EAP method. EAP methods run >between the peer and EAP server. We want PFS between the peer and NAS. >The endpoints are wrong. > >We could insert a layer similar to ERP (the hokey produced EAP >Reauthentication Protocol) between the peer and NAS. It's been a while >since I've looked at ERP, but I seem to recall that ERP runs between the >peer and an entity in the visited domain although it does have specific >NAS support. > >That approach would be OK for ABFAB assuming it could be implemented >efficiently. It would be a bit ugly because you want to start using the >ephemeral key well before EAP has concluded. However, for lower layers >that do complex keying after EAP concludes, it's probably the wrong >approach. Also, ERP took a long time to specify. I don't want to >commit to astandardization effort that complex. > >Kerberos. I was considering trying to share some tokens for ephemeral >keying with Kerberos. keying wants ephemeral keing within a GSS >mechanism. You could do that for Kerberos, although you'd need to take >advantage of the not-widely-implemented extension to the magic checksum >used by GSS for channel binding and (in that magic extension) other >extensions. In ABFAb the framing would be different because our context >tokens have subtokens. However we could use the same PDU. > >Except for two things. First, Kerberos probably would be happier with >an ap-req and ap-rep extension than a GSS mechanism level extension. >Secondly, Kerberos might well want to use pkinit data structures and >possibly even run a stripped down client-server version of pkinit for >the ephemeral keying. That's way too expensive in terms of >implementation complexity if you don't already have a pkinit >implementation sitting around. > >my conclusion from all this is that the right place to do ephemeral >keying for an EAP protocol is in the lower layer and that unless I got >something wrong or missed an alternative, ABFAb should do its own >mechanism. > >Can anyone see a good way to get protocol re-use here? >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238