From Jan.Pechanec@Sun.COM Sun May 2 02:44:53 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31D83A69CD for ; Sun, 2 May 2010 02:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BlO7fTATctu for ; Sun, 2 May 2010 02:44:52 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id EBB5F3A6957 for ; Sun, 2 May 2010 02:44:51 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o429iXhp022540 for ; Sun, 2 May 2010 09:44:34 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1S00F00DGE2200@fe-emea-13.sun.com> for saag@ietf.org; Sun, 02 May 2010 10:44:27 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1S00EWLDQ3AV60@fe-emea-13.sun.com>; Sun, 02 May 2010 10:44:27 +0100 (BST) Date: Sun, 02 May 2010 11:44:20 +0200 (CEST) From: Jan Pechanec Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: saag@ietf.org Message-id: X-Mailman-Approved-At: Sun, 02 May 2010 08:15:41 -0700 Cc: Darren.Moffat@Oracle.COM Subject: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 09:44:53 -0000 hi, while working on a couple of projects in the OpenSolaris development we realized that a new PKCS#11 URI scheme would be very handy to universaly reference public and private keys as well as certificates that are stored in PKCS#11 tokens. For example, we already use the scheme in our OpenSSL PKCS#11 engine to access keys in tokens through the regular OpenSSL API, and SSH is one of another candidates. I was told recently that this working group has many people who care about PKCS#11. We would appreciate any feedback on the I-D. the draft is here: http://www.ietf.org/id/draft-pechanec-pkcs11uri-01.txt while we discussed the initial attribute-value pair idea on the Cryptoki mailing list, the I-D itself sent there raised no discussion, and we didn't get any feedback from the OpenSC mailing list either. So, I can't provide any link to any passed discussion on the I-D. best regards, Jan. PS: please CC both Darren and me since we are not members of the mailing list. Thank you. -- Jan Pechanec http://blogs.sun.com/janp From turners@ieca.com Thu May 6 19:23:36 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE763A68C8 for ; Thu, 6 May 2010 19:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULSMTbNLXbfV for ; Thu, 6 May 2010 19:23:25 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 2585B3A68FA for ; Thu, 6 May 2010 19:23:19 -0700 (PDT) Received: (qmail 81638 invoked from network); 7 May 2010 02:23:03 -0000 Received: from thunderfish.local (turners@96.241.7.90 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 06 May 2010 19:23:03 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: NaFv894VM1n8fHXaUTHmUSkzCh.nd2RWQnBeL1oJMYEq8hn5MUvuxyAf2wuov1P6X4Nanv__bOM7kJkpBnNdFJ0ELR_og.OSTB9HKyLZzMq3hHOneAOufKzPm5_9qN7TZ.v7sQwIwqHsRm2fnAG3NMQsUq8Gy8ddKdPNRU9VJ9vizPVxr8Pzo9N_o3lRaLPYSxRuycT10QVPQrv1TD0573XTKmC2Fr0oNa6J_XS97WNKXIiCMvs0aiM4CSRQ6whOAIXz1ovUPK5WsYHnqW6bZLGxBKW64.mTYZbeAP_1d_7WL0vxp915Lpp_J9gSlgWhK8bXoGqCcmEjJVL_zmODhn8dZjFNYeOdlif5QpHTkoUYMvC2Dyb1U0LSIeygbH7KLiut3g1Uqy91uyDqW0k8hgTP0.TpSIwe.mR7PhxI4HbwKKm0avxV2XgInJ0AKgU5fI_.X1SmdtY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BE37986.70908@ieca.com> Date: Thu, 06 May 2010 22:23:02 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Sean's 1st AD Notes for 2010-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 02:23:36 -0000 Here's my 1st attempt at continuing Pasi's much liked monthly AD notes. It's a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Pasi had a clock going on many of these. I'm going to restart the clock. Oh and the date format is YYYY-MM-DD. Also these were written as of 2010-05-01 and things have happened since then. Cheers, spt MISC NOTES - Reviewed SAAG meeting minutes (Thanks Tero for the draft). - IETF 78 planning with Tim: SAAG presentations. - Arranged weekly call with Tim. - Learning just how much I'm going to rely on SECDIR reviews. - Reviewed draft-iab-auth-mech and provided lots of comments. - ~100 errata received from Constantin Hagemeier on RFC 3447, RFC 4301 RFC 4302, RFC 4306, and RFC 4880. Will rely on authors to help resolve these. - Errata 762, 1609, 1620, 1840, 2090, 2089, 2090, 2089, 2088, 2087, Held for Document Update (HFDU). - Errata 1886, 1812, 1676, 1839, and 1886 verified. - Errata 1480 rejected. WORKING GROUPS DKIM - draft-ietf-dkim-deployment: In AUTH48. RFC editor is waiting for authors to respond to questions. 2010-04-30. - A ton of email that I haven't gotten all the way through. - Errata 1532 and 1596: Awaiting WG chairs proposal for new text and recommended status. 2010-05-05. EMU - WG chairs submitted/delivered response to ITU-T X.1034 liaison. - draft-ietf-emu-eaptunnel-req: Joe proposed some text for the mandatory attributes section and text to address Dan's comments. Joe was going to publish new I-D. 2010-04-25. IPSECME - RFC 5480 published (was draft-ietf-ipsecme-traffic-visibility). - draft-ietf-ipsecme-aes-ctr-ikev2 completed last call and is on the 2010-05-06 IESG telechat. - draft-ietf-ipsecme-ikev2bis: On 2010-05-06 IESG telechat. - draft-ietf-ipsecme-roadmap: Authors told me they're almost done with their edits. Will post new version in early 2010-05. Expecting to IETF LC the document in 2010-05. - draft-ietf-ipsecme-ipsec-ha: Revised. - draft-ietf-ipsecme-eap-mutual: Revised. - (not a WG item and it happened in 2010-03) draftdraft-sheffer-ipsecme-pake-criteria-02.txt: Fair amount of discussion about definition of gateway. ISMS - draft-ietf-isms-dtls-tm: Added to 2010-05-06 IESG telechat. - draft-ietf-isms-radius-vacm: Need to get this one moving again. KEYPROV (I know it's Tim's but I am following it closely) - draft-ietf-keyprov-dskpp: Completed IETF LC. Dealt with GEN-Art comments. Placed on 2010-05-06 IESG telechat. Began dealing with AD DISCUSS/COMMENT positions. - draft-ietf-keyprov-pskc: Completed IETF LC. Placed on 2010-05-06 IESG telechat. - draft-ietf-keyprov-symmetrickeyformat: Completed IETF LC. Placed on 2010-05-06 IESG telechat. Began dealing with AD DISCUSS/COMMENT positions. SASL - draft-ietf-sasl-gs2 and draft-ietf-sasl-scram: in RFC editor queue, waiting for draft-altman-tls-channel-bindings. - (not WG item) draft-altman-tls-channel-bindings: Entered COMMENT position. Authors extremenly responsive and all were resolved a week before the 2010-05-06 IESG telechat. SYSLOG - draft-ietf-syslog-sign: RFC editor is waiting for J. Kelsey to respond. I have also pinged him via email. Next step is a phone call. 2010-05-05. - draft-ietf-syslog-dtls: Provided AD comments. Awaiting new version before issuing IETF LC. TLS - draft-ietf-tls-rfc4366-bis: Need to get this one moving. Still waiting on WG chairs/editor to drive discussion/propose text about the following topics (same as from Pasi's last email): 1) The "server_name" extension contains a list of domain names. Apparently, existing clients only send one, and some servers ignore everything except the first one. Since it seems nobody is using multiple names (and there are some unclear aspects about their exact semantics), perhaps the spec should just forbid more than one name of same "name_type"? 2) The document probably should be clearer about how "server_name" and session resumption interact (or do not interact). In particular, are Session IDs scoped by "server_name"? (If they are, the client MUST send the same "server_name" when resuming a session.) If they are not, does the server ignore the "server_name" when it resumes the session (in case the "server_name" in the original session was different) or not? IMHO RFC 4366 is quite clear that "server_name" is completely ignored when the server resumes a session (so Session IDs are not scoped by "server_name", and the server does not check it against the original session), but perhaps it doesn't hurt to clarify this with some new text. 3) As noted in Stephen Farrell's SecDir review (http://www.ietf.org/mail-archive/web/secdir/current/msg01195.html), the document probably should explain why SHA-1 is OK and algorithm agility is not needed. Tim and I have agreed with the WG that this use of SHA-1 (without algorithm agility) is acceptable. "trusted_ca_keys" clearly does not need a cryptographic function, and client_certificate_url does not seem to be affected by collisions either (and this extension is rarely used, so creating a new extension with agility is not really useful work). 4) Joe thought the WG should also consider whether the renegotiation fix has any effect on the "server_name" extension. I don't think it necessarily does (beyond the one sentence that's already in RFC 5746). - draft-ietf-tls-cached-info: New version posted. OTHER DOCUMENTS - draft-hoffman-tls-additional-random-ext: Initiated IETF LC. Lots of discussion. - draft-hoffman-tls-master-secret-input: Initiated IETF LC. Some discussion, but not nearly as much as draft-hoffman-tls-additional-random-ext. DISCUSSES - draft-ietf-avt-register-srtp: Awaiting response from Robert wrt his discussions with Cullen. 2010-04-22. - draft-ietf-bmwg-ipsec-meth: I picked up Pasi's DISCUSS. 2010-04-08. - draft-ietf-bmwg-ipsec-term: I picked up Pasi's DISCUSS. 2010-03-31. - draft-ietf-csi-hash-threat: I picked up Pasi's DISCUSS. 2010-04-08. - draft-ietf-geopriv-lis-discovery: Tim picked up Pasi's DISCUSS, but we're both working with the authors and the AD to resolve this one. - draft-ietf-sipping-config-framework: Waiting for revised I-D. 2010-04-22. - draft-cheshire-dnsext-nbp: I picked up part of Pasi's DISCUSS and Russ picked up the rest. From hotz@jpl.nasa.gov Thu May 13 18:32:25 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C592D3A68F2; Thu, 13 May 2010 18:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF8j6vesvL2B; Thu, 13 May 2010 18:32:25 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id EDD613A67FC; Thu, 13 May 2010 18:32:24 -0700 (PDT) Received: from dhcp-137-79-179-99.jpl.nasa.gov (dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4E1WDOo022275; Thu, 13 May 2010 18:32:14 -0700 From: "Henry B. Hotz" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 May 2010 18:32:13 -0700 Message-Id: To: ietf-krb-wg@lists.anl.gov, pkix@ietf.org, saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Source-IP: dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: [saag] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 01:32:25 -0000 I have just submitted the KX509 draft which I discussed in the Kerberos = working group in Anaheim. It's available at = https://datatracker.ietf.org/doc/draft-hotz-kx509/. The immediate question is where (if anywhere) should work on this draft = take place. Since it's function is to translate Kerberos tickets into = X.509 certificates, it might equally be handled by the krb-wg, or pkix. = Since I understand it's outside the precise charter of both, perhaps = saag should step in. What interest is there in handling work on this? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Thu May 13 18:32:31 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690E53A69E8; Thu, 13 May 2010 18:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np7Fh7Gbzsaz; Thu, 13 May 2010 18:32:30 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id B80243A69E5; Thu, 13 May 2010 18:32:29 -0700 (PDT) Received: from dhcp-137-79-179-99.jpl.nasa.gov (dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4E1WDOp022275; Thu, 13 May 2010 18:32:20 -0700 From: "Henry B. Hotz" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 13 May 2010 18:32:19 -0700 Message-Id: <7ACFE4E5-080E-42C0-8867-A99DBC930B19@jpl.nasa.gov> To: ietf-krb-wg@lists.anl.gov, pkix@ietf.org, saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Source-IP: dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: [saag] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 01:32:31 -0000 I was able to circulate this draft privately before I had clearance to = submit it. Based on feedback from two implementors of the protocol I = can already say: 1) There should be a standards-track version of an update to the = protocol which takes advantage of the evolution of both Kerberos and PKI = since the protocol was created. 2) The draft, though written to be standards-track, should instead be = informational. I welcome other feedback. Comments I have so far are: Should use the kerberos checksum instead of HMAC-SHA1 (IMO bumps = protocol version). Error codes should be standardized, allowing better client failover. Public Key type needs more specification. In particular some = specification (or negotiation) of minimum key size, and allowable key = types. (Existing client implementations seem to only generate 512-bit = RSA keys. Needs updating, but that doesn't force a version change.) Certificate encoding needs more specification. In particular I'm told = that the issued certificates should include: =95 KCA "1.3.6.1.4.1.250.42" =95 KCA AUTH REALM "1.3.6.1.4.1.250.42.1" =95 Krb5 Principal Name "1.3.6.1.5.2.2" =95 Use of subject Alt e-mail field for principal name (I think I disagree with the last, since IMO a principal only looks like = an email address, and it won't necessarily work as one. If it's = existing practice, then fine, but delete it in the new version.) Add text to the security considerations noting that there is no proof = the requester is in possession of the corresponding private key, which = opens up a number of issues. Shouldn't use these certs for digital = signature. (Need to fix this in the next version. Isn't there a = chicken-and-egg problem with using the PKI key pair for standard digital = signatures in advance of having an actual certificate?) Reference TAGPMA requirements. Error text should be UTF8String instead of VisibleString (IMO should = change in new version.) ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From deengert@anl.gov Fri May 14 08:43:46 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5B63A6B1A; Fri, 14 May 2010 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvCL-LTejk5D; Fri, 14 May 2010 08:43:45 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by core3.amsl.com (Postfix) with ESMTP id 95ED53A68B0; Fri, 14 May 2010 08:43:45 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 9493395; Fri, 14 May 2010 10:43:36 -0500 (CDT) Received: from [IPv6:::1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 8B18087; Fri, 14 May 2010 10:43:36 -0500 (CDT) Message-ID: <4BED6FA8.8080502@anl.gov> Date: Fri, 14 May 2010 10:43:36 -0500 From: "Douglas E. Engert" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Henry B. Hotz" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:43:46 -0000 Henry B. Hotz wrote: > I have just submitted the KX509 draft which I discussed in the Kerberos working group in Anaheim. It's available at https://datatracker.ietf.org/doc/draft-hotz-kx509/. > > The immediate question is where (if anywhere) should work on this draft take place. Since it's function is to translate Kerberos tickets into X.509 certificates, it might equally be handled by the krb-wg, or pkix. Since I understand it's outside the precise charter of both, perhaps saag should step in. > > What interest is there in handling work on this? A related question. The draft appears to be documenting the existing protocol. If so then it should state so. Should Appendix B be split up into know problems in the current implementations, and ideas for Protocol version 3? Known issues: Use of UDP can be a problem if the Kerberos ticket is large, for example if it contains a Microsoft PAC. A returned certificate could also be large. What are the cross realm issues? Multiple (replicated) KCA servers should create at lease different serial numbers. Ideas for version 3: Use the KRB_SAFE, KRB_PRIV and KRB_ERROR. This would address Appendix B items: 1, 2, 3. Or should it use gssapi to make this more general. Could a certificate chain be returned? Allow TCP. Other comments: Section 2.2 uses e-text and error-message. I assume they are the same. Appendix A says: "a widely used solution to this problem is to implement the KX509 client within a PKCS#11 library." I have seen a PKCS#11 library that access the kx509 certificate and key previously obtained by running a kx509 command, but not obtained from within the PKCS#11 lib. Is there such an implementation? > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Fri May 14 11:43:53 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0C13A69F3; Fri, 14 May 2010 11:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qxr1FTzdZJC; Fri, 14 May 2010 11:43:51 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by core3.amsl.com (Postfix) with ESMTP id 80B773A68FC; Fri, 14 May 2010 11:43:51 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 8A070AA; Fri, 14 May 2010 13:43:42 -0500 (CDT) Received: from [IPv6:::1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 6D7A887; Fri, 14 May 2010 13:43:42 -0500 (CDT) Message-ID: <4BED99DE.9030109@anl.gov> Date: Fri, 14 May 2010 13:43:42 -0500 From: "Douglas E. Engert" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Miller, Timothy J." References: <20100514022006.53A267CC05E@mailrelay.anl.gov> from "Michael StJohns" at May 13, 10 10:20:03 pm <201005141709.o4EH92OI022790@fs4113.wdf.sap.corp> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5C7@IMCMBX2.MITRE.ORG> In-Reply-To: <17FD76C1ECD0AB49817637E21809ABF9082FEDA5C7@IMCMBX2.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "'mrex@sap.com'" , Michael StJohns , "saag@ietf.org" Subject: Re: [saag] [Ietf-krb-wg] [pkix] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:43:53 -0000 Miller, Timothy J. wrote: >> Unfortunately it shares the awkwardness with their APIs in that it >> is not a valid Kerberos principal name. > > That's because it's not a principal name at all. If you inspect the PKINIT packets Windows emits, they use NT-ENTERPRISE for this identifier. NT-ENTERPRISE is an arbitrary identifier that maps to a unique principal name. > When Microsoft started using smart cads the the principal as the subjectAltName othername MSUPN to the cards. This was a simple way to map a cert to an AD account using the existing attribute of userPrincipalName. This would only work if the card is issued by the enterprise CA. So over the years things have changed. One can change the account userPrincipalName attribute to match whatever is on the smart card and as you point out W2003 will also look at: > Windows principal names are sAMAccountName@DOMAIN.FQDN. And IIRC, one can still kinit using either sAMAccountName@DOMAIN.FQDN or the userPrincipalName value. So CAC or PIV cards with a MSUPN like nnnnnnnnnnnnn@FEDIDCARD.GOV to the cert can still work on W2003 DCs. With W2008s DC the subjectAltName does not need to be in the certificate, and some other mapping of certs to accounts can be used. But the damage has been done, the userPrincipalName attribute is not what one might expect. > > -- Tim > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Martin Rex >> Sent: Friday, May 14, 2010 12:09 PM >> To: Michael StJohns >> Cc: pkix@ietf.org; ietf-krb-wg@lists.anl.gov; saag@ietf.org >> Subject: Re: [pkix] [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00 >> >> Michael StJohns wrote: >>> At 09:32 PM 5/13/2010, Henry B. Hotz wrote: >>>> * Use of subject Alt e-mail field for principal name >>>> (I think I disagree with the last, since IMO a principal only looks >> like an email address, and it won't necessarily work as one. If it's >> existing practice, then fine, but delete it in the new version.) >>> See RFC4456 - specifically the id-pkinit-san subject alternative name >>> encoding which defines a kerberos centric certificate name encoding. >> It seems that Microsoft has been shipping functionality to include >> _some_ principal name ("UPN") in X.509v3 certificates, in a >> subjectAltName type "other" with the OID 1.3.6.1.4.1.311.20.2.3. >> >> Unfortunately it shares the awkwardness with their APIs in that it >> is not a valid Kerberos principal name. The uppper/lowercasing >> of the Realm part is definitely incorrect, and I wouldn't bet on >> the correctness of the upper/lower-casing on the part before >> the "@" either. So that entry is a someone unusable unless oneself >> happens to be the responsible Active Directory that is cabable to >> correctly canonicalize that UPN into a correct Kerberos principal >> name for use within Kerberos protocol exchanges. >> >> -Martin >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@lists.anl.gov > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From hartmans@mit.edu Fri May 14 12:23:04 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B88D3A683F; Fri, 14 May 2010 12:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyfWTvsIcCVO; Fri, 14 May 2010 12:23:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 021F928C154; Fri, 14 May 2010 12:22:04 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7A74220239; Fri, 14 May 2010 15:21:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A663743EE; Fri, 14 May 2010 15:21:52 -0400 (EDT) From: Sam Hartman To: saag@ietf.org Date: Fri, 14 May 2010 15:19:34 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) X-Brightmail-Tracker: AAAAAA== MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org Subject: [saag] Summary of Federated Authentication BOF at IETF 77 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:23:04 -0000 I'm told there were around 30 people in the room. That seemed like a good turn out for Thursday at 9 PM. Many of the participants had already read some or all of the proposed documents. I presented a problem statement based on providing federated authentication for non-web applications. Two solutions were presented. I presented work on Moonshot, a technology that combines EAP, GSS-API, RADIUS and SAML to solve the problem. Eliot Lear and Klaas Wierenga presented a simpler solution that uses browser-based SAML and Open ID. The sense of the room was that these solutions compliment each other. Moonshot requires more infrastructure and client configuration but provides several advantages. The browser-based solutions are something that requires fewer client changes. Volunteers were collected from the EAP, GSS and RADIUS communities who would be interested in working on these problems. Some of the work discussed, possibly especially including the Open ID and SAML browser-based solutions may be able to progress in kitten. I and I believe several of the other Moonshot proponents would prefer to focus the Moonshot work in one working group. Other solutions could also be progressed in that group, although we should be careful not to slow down work that could progress quickly in kitten by moving it into an as-yet-unchartered group. There seemed to be strong support for going forward. However, several things to address in a BOF were raised with regard to the Moonshot work. * Steve Bellovin pointed out that we need to be very aware of the operational impact and how this fits with the operational model of the technologies that are used/extended. * Klaas pointed out that Moonshot involves changes to a lot of different components. We need to make sure that there are incremental advantages to each of these changes so they will be deployed: a system where there is no benefit until the end when all the peaces fall together is much harder to deploy. * Klaas pointed out that we need to consider the operational security around how RADIUS federations are deployed. If network access is not considered sensitive today, people may be more lax in the security surrounding their RADIUS infrastructure. If we use that infrastructure to secure more sensitive resources we need to have practices that tighten up the security of the infrastructure sufficiently. * Someone brought up that this is another one of those authentication proposals where user-interface is critical. While we should not lay out dialogues in the IETF, we're going to need to describe the usability aspects of this enough to increase the probability of a good security solution. People specifically asked to look at the following: * Complexity * What can't be handled with simpler solutions * Is Moonshot broad enough in scope? * The UI questions Since the bar BOF, there has been a lot of traffic on the list and work continues. We're definitely going to put together a BOF request for IETF 78. From hotz@jpl.nasa.gov Fri May 14 14:29:39 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BA43A68DC; Fri, 14 May 2010 14:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUZKp6efKGri; Fri, 14 May 2010 14:29:38 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id AB3623A67E3; Fri, 14 May 2010 14:29:38 -0700 (PDT) Received: from dhcp-137-79-179-99.jpl.nasa.gov (dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4ELTSb1017884; Fri, 14 May 2010 14:29:28 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <201005141918.o4EJIs80029787@fs4113.wdf.sap.corp> Date: Fri, 14 May 2010 14:29:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201005141918.o4EJIs80029787@fs4113.wdf.sap.corp> To: "mrex@sap.com" X-Mailer: Apple Mail (2.1078) X-Source-IP: dhcp-137-79-179-99.jpl.nasa.gov [137.79.179.99] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 21:29:39 -0000 I should have checked this first, but the third item is identically the = kerberos principal name described in RFC4556, section 3.2.2. I do = believe the cert should unambiguously record what it's based on, and I = think this is the correct way to do it. On May 14, 2010, at 11:24 AM, Martin Rex wrote: > Henry B. Hotz wrote: >>=20 >> Certificate encoding needs more specification. >> In particular I'm told that the issued certificates should include: >>=20 >> o KCA "1.3.6.1.4.1.250.42" >> o KCA AUTH REALM "1.3.6.1.4.1.250.42.1" >> o Krb5 Principal Name "1.3.6.1.5.2.2" >> o Use of subject Alt e-mail field for principal name >>=20 >> (I think I disagree with the last, since IMO a principal only looks >> like an email address, and it won't necessarily work as one. >> If it's existing practice, then fine, but delete it in the new = version.) >=20 > I agree to your disagreement with the last. >=20 > The problematic thing with the rfc822Name subjectAltName is > the underlying ASN.1 type: >=20 > http://tools.ietf.org/html/rfc5280#page-128 >=20 > GeneralName ::=3D CHOICE { > otherName [0] AnotherName, > rfc822Name [1] IA5String, > dNSName [2] IA5String, >=20 > I don't recall a desision that I18N for Kerberos principal names > was going to use an "ascii compatible encoding"... 8-] >=20 >=20 > -Martin >=20 > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@lists.anl.gov > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Fri May 14 16:55:36 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CD23A688F; Fri, 14 May 2010 16:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvA1EpXJpS2B; Fri, 14 May 2010 16:55:35 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id 875A23A67F6; Fri, 14 May 2010 16:55:35 -0700 (PDT) Received: from dhcp-137-78-127-84.jpl.nasa.gov (dhcp-137-78-127-84.jpl.nasa.gov [137.78.127.84]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4ENsZUq023781; Fri, 14 May 2010 16:55:25 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4BED6FA8.8080502@anl.gov> Date: Fri, 14 May 2010 16:55:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> To: "Douglas E. Engert" X-Mailer: Apple Mail (2.1078) X-Source-IP: dhcp-137-78-127-84.jpl.nasa.gov [137.78.127.84] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 23:55:36 -0000 On May 14, 2010, at 8:43 AM, Douglas E. Engert wrote: > Henry B. Hotz wrote: >> I have just submitted the KX509 draft which I discussed in the = Kerberos working group in Anaheim. It's available at = https://datatracker.ietf.org/doc/draft-hotz-kx509/. >>=20 >> The immediate question is where (if anywhere) should work on this = draft take place. Since it's function is to translate Kerberos tickets = into X.509 certificates, it might equally be handled by the krb-wg, or = pkix. Since I understand it's outside the precise charter of both, = perhaps saag should step in. >>=20 >> What interest is there in handling work on this? >=20 > A related question. The draft appears to be documenting the existing > protocol. If so then it should state so. See other email. This draft should become informational and document = the existing protocol. Need a new one. > Should Appendix B be split > up into know problems in the current implementations, and ideas for > Protocol version 3? >=20 > Known issues: >=20 > Use of UDP can be a problem if the Kerberos ticket is large, > for example if it contains a Microsoft PAC. A returned certificate > could also be large. Forgot to include a recommendation I got that the PAC should be = prohibited in tickets for this service for just that reason. > What are the cross realm issues? That's a really good question. Note that the original identity should = be recorded in an id-pkinit-san attribute (per comments in email, not = the current draft). I think that's necessary, but not sufficient for = cross realm issues. =20 Probably part of the right solution is to say something about how = subject names should be constructed, based on the principal name and = realm. I currently say nothing about that, and it now seems like an = oversight. =20 Then, of course, there are all the capath validation questions. Do you = have any recommendations? > Multiple (replicated) KCA servers should create at lease different > serial numbers. That's probably implied by the other PKIX standards already, but it = wouldn't hurt to mention it. (As an implementation point, I don't think = the Heimdal KCA will do that.) > Ideas for version 3: >=20 > Use the KRB_SAFE, KRB_PRIV and KRB_ERROR. This would address > Appendix B items: 1, 2, 3. Already have related comments. Sounds reasonable. > Or should it use gssapi to make this more general. Offhand, no, because that no longer seems like a simple update. OTOH, = if there is interest and a real use case, perhaps so. > Could a certificate chain be returned? I'm neutral. Seems unnecessary, but easy to do (at least over TCP). > Allow TCP. I'm actually happy with UDP, but I seem to have more confidence in my = ability to get firewalls to behave than most. Sure, why not? Would you then argue for allowing the Microsoft PAC back in as a = consequence? > Other comments: > Section 2.2 uses e-text and error-message. I assume they are the = same. Yes. > Appendix A says: "a widely used solution to this problem is to > implement the KX509 client within a PKCS#11 library." I have seen > a PKCS#11 library that access the kx509 certificate and key > previously obtained by running a kx509 command, but not obtained from > within the PKCS#11 lib. Is there such an implementation? You're quite right. The version of the UMICH code I have has a build = option to make the command into a library, but the pkcs11 library does = not call it. IMO what I said is how it should work, but I don't believe = that's what's actually in the wild. Should this standard say anything about how the cert should be cached in = a Kerberos credential cache? I see advantages to having UMICH/MIT code = share an already-feched certificate with Heimdal code, but I had = considered that to be out of scope for this work. I think I still do. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From jhutz@cmu.edu Fri May 14 19:03:31 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9743A67FC; Fri, 14 May 2010 19:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDHKagXmuDhs; Fri, 14 May 2010 19:03:29 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id C6D903A679C; Fri, 14 May 2010 19:03:29 -0700 (PDT) Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4F23GHH024550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 22:03:17 -0400 (EDT) Date: Fri, 14 May 2010 22:03:16 -0400 From: Jeffrey Hutzelman To: "Henry B. Hotz" , "Douglas E. Engert" Message-ID: <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> In-Reply-To: <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 02:03:31 -0000 --On Friday, May 14, 2010 04:55:24 PM -0700 "Henry B. Hotz" wrote: >> What are the cross realm issues? > > That's a really good question. Note that the original identity should be > recorded in an id-pkinit-san attribute (per comments in email, not the > current draft). I think that's necessary, but not sufficient for cross > realm issues. It's certainly necessary, since otherwise you don't know what to what principal the certificate belongs. > Probably part of the right solution is to say something about how subject > names should be constructed, based on the principal name and realm. I > currently say nothing about that, and it now seems like an oversight. You may want to say something about how to construct a subject DN. In practice, it might be better to leave it unspecified. The answer is likely to be heavily influenced by local policy and might be based in part on the result of a directory lookup done by the KCA. > Then, of course, there are all the capath validation questions. Do you > have any recommendations? IMHO the only sane thing to do is for the KCA to apply whatever cross-realm path validation policy it has and then either issue the certificate or not based on whether it believes the request is sufficiently well authenticated. Any attempt to push Kerberos cross-realm path information into the certificate is almost certainly going to be ignored by any relying party. >> Multiple (replicated) KCA servers should create at lease different >> serial numbers. > > That's probably implied by the other PKIX standards already, but it > wouldn't hurt to mention it. (As an implementation point, I don't think > the Heimdal KCA will do that.) Yeah; any given CA should not ever issue multiple certificates with the same serial number. One way to achieve this therough deployment configuration is to give each KCA a separate name, private key, and CA certificate, making them in effect independent CA's with separate serial number spaces. >> Could a certificate chain be returned? > > I'm neutral. Seems unnecessary, but easy to do (at least over TCP). I could see this being useful. In security-sensitive deployments the root CA will be carefully controlled, and its private key will likely be kept offline. As a result, the KCA itself will not be a root, and this there will be at least one intermediate CA certificate. It therefore becomes useful to be able to provide a client with the set of intermediates required to get from the root to the newly-issued certificate. >> Appendix A says: "a widely used solution to this problem is to >> implement the KX509 client within a PKCS#11 library." I have seen >> a PKCS#11 library that access the kx509 certificate and key >> previously obtained by running a kx509 command, but not obtained from >> within the PKCS#11 lib. Is there such an implementation? > > You're quite right. The version of the UMICH code I have has a build > option to make the command into a library, but the pkcs11 library does > not call it. IMO what I said is how it should work, but I don't believe > that's what's actually in the wild. I'm not sure how that would work. Is enrollment even in scope for PKCS#11? > Should this standard say anything about how the cert should be cached in > a Kerberos credential cache? I see advantages to having UMICH/MIT code > share an already-feched certificate with Heimdal code, but I had > considered that to be out of scope for this work. I think I still do. I agree that specifying the details of the file credential cache format used by some implementations is out of scope. -- Jeff From hartmans@mit.edu Sat May 15 09:38:01 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4395F3A69F2; Sat, 15 May 2010 09:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg8OKx4AeK6X; Sat, 15 May 2010 09:38:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id A665B3A692C; Sat, 15 May 2010 09:37:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8FFA8202D2; Sat, 15 May 2010 12:37:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AEADA43EE; Sat, 15 May 2010 12:37:46 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> Date: Sat, 15 May 2010 12:37:46 -0400 In-Reply-To: <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Fri, 14 May 2010 22:03:16 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 16:38:01 -0000 What are the implications of using the pkinit SAN on being able to turn around and use a KCA certificate with pkinit? I'd assume that you really do not want to permit that usage under normal circumstances, at least not with the AS that issued the cert. From jhutz@cmu.edu Mon May 17 10:25:56 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694F528C118; Mon, 17 May 2010 10:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCvblvX17kfq; Mon, 17 May 2010 10:25:52 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 2482A28C125; Mon, 17 May 2010 10:23:01 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4HHMpj4002025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 13:22:51 -0400 (EDT) Date: Mon, 17 May 2010 13:22:51 -0400 From: Jeffrey Hutzelman To: Sam Hartman Message-ID: <8900F9010016226491F8D479@lysithea.fac.cs.cmu.edu> In-Reply-To: References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 17:25:56 -0000 --On Saturday, May 15, 2010 12:37:46 PM -0400 Sam Hartman wrote: > What are the implications of using the pkinit SAN on being able to turn > around and use a KCA certificate with pkinit? I'd assume that you > really do not want to permit that usage under normal circumstances, at > least not with the AS that issued the cert. Good question. I think we mostly intended that the KRB5PrincipalName SAN be usable in certificates for a variety of purposes, and not only when the certificate was intended for use with PKINIT. In fact, while the form is formalle specified in RFC4556, IIRC we borrowed it from another document that was not going to be advancing as quickly. Unfortunately, while RFC4556 defines an extended key usage OID for use with PKINIT client certificates, it does not require this EKU to be present. So, a KDC which accepts any certificate containing a KRB5PrincipalName SAN as authenticating that principal for PKINIT is compliant. That makes it dangerous to specify use of that SAN or issue certificates containing it, except when the issuer either intends the certificate to be usable with PKINIT or includes an ExtendedKeyUsage extension which precludes such use. And, I wouldn't really count on the latter, given the trouble we had with PKINIT and later documents in getting people to understand how EKU's were intended to work. FWIW, the present issue is exactly why I and others have been so agressive in making the point that presence of a particular name type does not and should not imply that a certificate is acceptable for a particular use. By allowing PKINIT implementations to infer such an implication, we've essentially destroyed the usefulness of the KRB5PrincipalName SAN for other usages. This is going to suck, but I think I'm going to propose the specification of a new name type which has the form of KRB5PrincipalName but an OID distinct from that of id-pkinit-san. The new type would be usable any time an issuer wishes to identify a certificate as belonging to a particular principal, and would explicitly _not_ imply usability for PKINIT or any other application. In fact, I think I'd go so far as to specify that PKINIT implementations MUST NOT accept certificates on the basis of the new name type unless the id-pkinit-KPClientAuth EKU is present. -- Jeff From hotz@jpl.nasa.gov Mon May 17 10:41:32 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66743A68AA; Mon, 17 May 2010 10:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.788 X-Spam-Level: X-Spam-Status: No, score=-4.788 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjBhz5H3j6d2; Mon, 17 May 2010 10:41:32 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id D70793A699F; Mon, 17 May 2010 10:41:22 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4HHfCb2029576; Mon, 17 May 2010 10:41:12 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <17FD76C1ECD0AB49817637E21809ABF9082FEDA5CB@IMCMBX2.MITRE.ORG> Date: Mon, 17 May 2010 10:41:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00B6FAF1-5CA3-4201-89D2-ECE5F6F57B4E@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5CB@IMCMBX2.MITRE.ORG> To: "Miller, Timothy J." X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , 'Sam Hartman' , "saag@ietf.org" Subject: Re: [saag] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 17:41:33 -0000 I'm pretty sure I don't levy any requirements in this area. I also = don't believe I should, though I could easily be convinced to put in a = "SHOULD NOT" statement. I do try to say the right things in the Security Considerations Section. = Please review that and make any suggestions you think appropriate. I = agree there's a lot of opportunity for problems (even if you don't allow = authentication loops). Also note, from other email, that I will be adding something to deal = with the possibility of someone stealing just a public key and using = this service to get a "duplicate" certificate. On May 17, 2010, at 7:22 AM, Miller, Timothy J. wrote: > PKINIT requires additional EKUs (unless the KDC isn't enforcing this), = so a profile with a Kerberos principal name SAN isn't sufficient by = itself. >=20 > However I agree with the general sentiment. KX509 can act like a = credential elevator, which makes me uncomfortable, but I haven't made up = my mind re: further work on the protocol. >=20 > -- Tim >=20 >=20 >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >> Sam Hartman >> Sent: Saturday, May 15, 2010 11:38 AM >> To: Jeffrey Hutzelman >> Cc: pkix@ietf.org; ietf-krb-wg@lists.anl.gov; saag@ietf.org >> Subject: Re: [pkix] [saag] Draft KX509 Proposal >>=20 >> What are the implications of using the pkinit SAN on being able to = turn >> around and use a KCA certificate with pkinit? I'd assume that you >> really do not want to permit that usage under normal circumstances, = at >> least not with the AS that issued the cert. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Mon May 17 12:14:11 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D00D3A6AF2; Mon, 17 May 2010 12:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGJW5JHdijMt; Mon, 17 May 2010 12:14:09 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id B0BE43A6AE3; Mon, 17 May 2010 12:13:41 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4HJDUHp013679; Mon, 17 May 2010 12:13:30 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> Date: Mon, 17 May 2010 12:13:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 19:14:11 -0000 Leaving PKINIT and authentication loop issues for another thread. . . On May 14, 2010, at 7:03 PM, Jeffrey Hutzelman wrote: > --On Friday, May 14, 2010 04:55:24 PM -0700 "Henry B. Hotz"=20 > wrote: >=20 >> Probably part of the right solution is to say something about how = subject >> names should be constructed, based on the principal name and realm. = I >> currently say nothing about that, and it now seems like an oversight. >=20 > You may want to say something about how to construct a subject DN. In=20= > practice, it might be better to leave it unspecified. =20 I tried to come up with some "SHOULD" wordage, but couldn't think of = anything that didn't seem meaningless. I'm open to suggestions, but = will leave it unspecified in their absence. > The answer is likely=20 > to be heavily influenced by local policy and might be based in part on = the=20 > result of a directory lookup done by the KCA. Yep. Need to conform to local X.509 naming conventions first. The = mapping between that and the Kerberos name isn't something I can = generalize to a requirement. Most I could possibly say is there ought = to be some kind of relationship, except in exceptional cases. >> Then, of course, there are all the capath validation questions. Do = you >> have any recommendations? >=20 > IMHO the only sane thing to do is for the KCA to apply whatever = cross-realm=20 > path validation policy it has and then either issue the certificate or = not=20 > based on whether it believes the request is sufficiently well=20 > authenticated. Any attempt to push Kerberos cross-realm path = information=20 > into the certificate is almost certainly going to be ignored by any = relying=20 > party. So I should put in a cross-reference to the right section of 4120, with = a "SHOULD enforce" clause? >>> Multiple (replicated) KCA servers should create at lease different >>> serial numbers. >>=20 >> That's probably implied by the other PKIX standards already, but it >> wouldn't hurt to mention it. (As an implementation point, I don't = think >> the Heimdal KCA will do that.) >=20 > Yeah; any given CA should not ever issue multiple certificates with = the=20 > same serial number. One way to achieve this therough deployment=20 > configuration is to give each KCA a separate name, private key, and CA=20= > certificate, making them in effect independent CA's with separate = serial=20 > number spaces. That's probably the right technical solution. Since I'm in the middle = of trying to figure out how to get a JPL CA certified, I'd expect some = non-trivial auditing costs associated with that approach. Maybe easier = to just give each one a unique serial number prefix. That's all implementation though. I think the requirement is just that = KCA's MUST issue certificates with globally unique serial numbers = (somehow or other). >>> Could a certificate chain be returned? >>=20 >> I'm neutral. Seems unnecessary, but easy to do (at least over TCP). >=20 > I could see this being useful. In security-sensitive deployments the = root=20 > CA will be carefully controlled, and its private key will likely be = kept=20 > offline. As a result, the KCA itself will not be a root, and this = there=20 > will be at least one intermediate CA certificate. It therefore = becomes=20 > useful to be able to provide a client with the set of intermediates=20 > required to get from the root to the newly-issued certificate. Have to see if the UMICH KCA supports that. This draft is supposed to = document existing practice. For the next version, I'd say the KCA MAY return the chain and define a = place in the ASN1. >>> Appendix A says: "a widely used solution to this problem is to >>> implement the KX509 client within a PKCS#11 library." I have seen >>> a PKCS#11 library that access the kx509 certificate and key >>> previously obtained by running a kx509 command, but not obtained = from >>> within the PKCS#11 lib. Is there such an implementation? >>=20 >> You're quite right. The version of the UMICH code I have has a build >> option to make the command into a library, but the pkcs11 library = does >> not call it. IMO what I said is how it should work, but I don't = believe >> that's what's actually in the wild. >=20 > I'm not sure how that would work. Is enrollment even in scope for = PKCS#11? IMO the way it ought to work (as opposed to how it works now) is when = you open the PKCS#11 library it should look for a an existing = (unexpired) cert in the Kerberos ccache. If there is, use it. If there = isn't one, then it goes and gets one (via KX509) and saves it to the = ccache. In other words, the use profile ought to be the same as any other = Kerberized service. >> Should this standard say anything about how the cert should be cached = in >> a Kerberos credential cache? I see advantages to having UMICH/MIT = code >> share an already-feched certificate with Heimdal code, but I had >> considered that to be out of scope for this work. I think I still = do. >=20 > I agree that specifying the details of the file credential cache = format=20 > used by some implementations is out of scope. OK. > -- Jeff ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From deengert@anl.gov Mon May 17 12:58:19 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FBE3A6ACE; Mon, 17 May 2010 12:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWo48fpow1xL; Mon, 17 May 2010 12:58:18 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by core3.amsl.com (Postfix) with ESMTP id B12A43A69D3; Mon, 17 May 2010 12:58:17 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 22BB864; Mon, 17 May 2010 14:58:10 -0500 (CDT) Received: from [IPv6:::1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 1732537; Mon, 17 May 2010 14:58:10 -0500 (CDT) Message-ID: <4BF19FD2.7020006@anl.gov> Date: Mon, 17 May 2010 14:58:10 -0500 From: "Douglas E. Engert" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Henry B. Hotz" References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> In-Reply-To: <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 19:58:20 -0000 Henry B. Hotz wrote: > Leaving PKINIT and authentication loop issues for another thread. . . > > On May 14, 2010, at 7:03 PM, Jeffrey Hutzelman wrote: > >> --On Friday, May 14, 2010 04:55:24 PM -0700 "Henry B. Hotz" >> wrote: >> >>> Probably part of the right solution is to say something about how subject >>> names should be constructed, based on the principal name and realm. I >>> currently say nothing about that, and it now seems like an oversight. >> You may want to say something about how to construct a subject DN. In >> practice, it might be better to leave it unspecified. > > I tried to come up with some "SHOULD" wordage, but couldn't think of anything that didn't seem meaningless. I'm open to suggestions, but will leave it unspecified in their absence. > Most likely the it is determined by the local policy of the KCA, just like any other CA. Depending on how you want to look at how kx509 is being used. Is it more like the Windows auto enroll certificates intended for a short time, usable only at the local site, where the KCA cert is signed by the local CA or is kx509 being used as a source of a Grid certificate to be used at many sites. >> The answer is likely >> to be heavily influenced by local policy and might be based in part on the >> result of a directory lookup done by the KCA. > > Yep. Need to conform to local X.509 naming conventions first. The mapping between that and the Kerberos name isn't something I can generalize to a requirement. Most I could possibly say is there ought to be some kind of relationship, except in exceptional cases. > >>> Then, of course, there are all the capath validation questions. Do you >>> have any recommendations? >> IMHO the only sane thing to do is for the KCA to apply whatever cross-realm >> path validation policy it has and then either issue the certificate or not >> based on whether it believes the request is sufficiently well >> authenticated. Any attempt to push Kerberos cross-realm path information >> into the certificate is almost certainly going to be ignored by any relying >> party. > > So I should put in a cross-reference to the right section of 4120, with a "SHOULD enforce" clause? Yes. It could also be a policy of the KCA to not issue certificates if cross realm is used! A lot of these questions come down how will the certificates issued by the KCA be used, and how much of the original Kerberos authentication info need to be passed along in the certificate. > >>>> Multiple (replicated) KCA servers should create at lease different >>>> serial numbers. >>> That's probably implied by the other PKIX standards already, but it >>> wouldn't hurt to mention it. (As an implementation point, I don't think >>> the Heimdal KCA will do that.) >> Yeah; any given CA should not ever issue multiple certificates with the >> same serial number. One way to achieve this therough deployment >> configuration is to give each KCA a separate name, private key, and CA >> certificate, making them in effect independent CA's with separate serial >> number spaces. The original UMich had a sn_increment=n parameter in the kca.cnf to to make sure the serial numbers are different. (and setting the starting serial numbers accordingly, like n=2 and even, odd.) > > That's probably the right technical solution. Since I'm in the middle of trying to figure out how to get a JPL CA certified, I'd expect some non-trivial auditing costs associated with that approach. Maybe easier to just give each one a unique serial number prefix. > > That's all implementation though. I think the requirement is just that KCA's MUST issue certificates with globally unique serial numbers (somehow or other). > >>>> Could a certificate chain be returned? >>> I'm neutral. Seems unnecessary, but easy to do (at least over TCP). >> I could see this being useful. In security-sensitive deployments the root >> CA will be carefully controlled, and its private key will likely be kept >> offline. As a result, the KCA itself will not be a root, and this there >> will be at least one intermediate CA certificate. It therefore becomes >> useful to be able to provide a client with the set of intermediates >> required to get from the root to the newly-issued certificate. > > Have to see if the UMICH KCA supports that. This draft is supposed to document existing practice. > > For the next version, I'd say the KCA MAY return the chain and define a place in the ASN1. > >>>> Appendix A says: "a widely used solution to this problem is to >>>> implement the KX509 client within a PKCS#11 library." I have seen >>>> a PKCS#11 library that access the kx509 certificate and key >>>> previously obtained by running a kx509 command, but not obtained from >>>> within the PKCS#11 lib. Is there such an implementation? >>> You're quite right. The version of the UMICH code I have has a build >>> option to make the command into a library, but the pkcs11 library does >>> not call it. IMO what I said is how it should work, but I don't believe >>> that's what's actually in the wild. >> I'm not sure how that would work. Is enrollment even in scope for PKCS#11? > > IMO the way it ought to work (as opposed to how it works now) is when you open the PKCS#11 library it should look for a an existing (unexpired) cert in the Kerberos ccache. If there is, use it. If there isn't one, then it goes and gets one (via KX509) and saves it to the ccache. > > In other words, the use profile ought to be the same as any other Kerberized service. Depends on how PKCS#11 is used. For example, if I am running FireFox, that can have multiple Security Modules i.e. PKCS#11s, I don't know if I would want it getting my a key can cert under the covers. > >>> Should this standard say anything about how the cert should be cached in >>> a Kerberos credential cache? I see advantages to having UMICH/MIT code >>> share an already-feched certificate with Heimdal code, but I had >>> considered that to be out of scope for this work. I think I still do. >> I agree that specifying the details of the file credential cache format >> used by some implementations is out of scope. > > OK. > >> -- Jeff > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert@anl.gov Mon May 17 13:33:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9E03A681E; Mon, 17 May 2010 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9S8VKWQ8FtP; Mon, 17 May 2010 13:33:28 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by core3.amsl.com (Postfix) with ESMTP id 79F4F28C157; Mon, 17 May 2010 13:30:25 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id E1EBD35; Mon, 17 May 2010 15:30:17 -0500 (CDT) Received: from [IPv6:::1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id B1C0731; Mon, 17 May 2010 15:30:17 -0500 (CDT) Message-ID: <4BF1A759.1010505@anl.gov> Date: Mon, 17 May 2010 15:30:17 -0500 From: "Douglas E. Engert" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Henry B. Hotz" References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5CB@IMCMBX2.MITRE.ORG> <00B6FAF1-5CA3-4201-89D2-ECE5F6F57B4E@jpl.nasa.gov> In-Reply-To: <00B6FAF1-5CA3-4201-89D2-ECE5F6F57B4E@jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Miller, Timothy J." , "saag@ietf.org" , "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , 'Sam Hartman' Subject: Re: [saag] [Ietf-krb-wg] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 20:33:29 -0000 Henry B. Hotz wrote: > I'm pretty sure I don't levy any requirements in this area. I also don't believe I should, though I could easily be convinced to put in a "SHOULD NOT" statement. > > I do try to say the right things in the Security Considerations Section. Please review that and make any suggestions you think appropriate. I agree there's a lot of opportunity for problems (even if you don't allow authentication loops). > > Also note, from other email, that I will be adding something to deal with the possibility of someone stealing just a public key and using this service to get a "duplicate" certificate. > Good catch. This is an issue with the current protocol, that the client only send the pub key, without demonstrating that it holds the private key. In the Considerations, maybe it should be sending a PKCS#10 request - RFC2986. The request is would not be saved, but if its still sent unencrtypted, as the key is in the current protocol, it could be replayed. So it needs to be sent encrypted or used in some way to prove to the KCA that the request is current. > > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@lists.anl.gov > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From hotz@jpl.nasa.gov Mon May 17 18:35:56 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9B93A6B9F; Mon, 17 May 2010 18:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLiGv3iO2-Ea; Mon, 17 May 2010 18:35:55 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id 335F73A6A8A; Mon, 17 May 2010 18:35:55 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4I1Zkcj014234; Mon, 17 May 2010 18:35:46 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <87eihaxc8g.fsf@windlord.stanford.edu> Date: Mon, 17 May 2010 18:35:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D657E58-3578-4BDD-ADF2-FDD0C3F9578F@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <8900F9010016226491F8D479@lysithea.fac.cs.cmu.edu> <4BF17CB6.20408@secure-endpoints.com> <87eihaxc8g.fsf@windlord.stanford.edu> To: Russ Allbery X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 01:35:56 -0000 On May 17, 2010, at 5:52 PM, Russ Allbery wrote: > Jeffrey Altman writes: >> On 5/17/2010 1:22 PM, Jeffrey Hutzelman wrote: >=20 >>> FWIW, the present issue is exactly why I and others have been so >>> aggressive in making the point that presence of a particular name = type >>> does not and should not imply that a certificate is acceptable for a >>> particular use. By allowing PKINIT implementations to infer such an >>> implication, we've essentially destroyed the usefulness of the >>> KRB5PrincipalName SAN for other usages. >=20 >>> This is going to suck, but I think I'm going to propose the >>> specification of a new name type which has the form of >>> KRB5PrincipalName but an OID distinct from that of id-pkinit-san. = The >>> new type would be usable any time an issuer wishes to identify a >>> certificate as belonging to a particular principal, and would >>> explicitly _not_ imply usability for PKINIT or any other = application. >>> In fact, I think I'd go so far as to specify that PKINIT >>> implementations MUST NOT accept certificates on the basis of the new >>> name type unless the id-pkinit-KPClientAuth EKU is present. >=20 >> It is then unfortunate that deployed KCA implementations have been = using >> the KRB5PrincipalName type for many many years now. The KCA = developers >> lifted the name type from the same place that PKINIT did. It is too >> late to put the genie back in the bottle. >=20 > While not ideal, this *can* be addressed operationally by telling > implementors to not use the same root CA trust path for KCA-issued > certificates as for PKINIT client authentication, yes? Yes. I expect there are lots ways to "break" the potential loop. = What's important is that deployers know they need to avoid the pothole. This is off-topic, but the Microsoft UPN and the id-pkinit-san value in = the certificate are put there by the certificate issuer. In the case of = smart cards the issuer frequently (mostly?) is a different organization = from the one running the KDC and supporting PKINIT. That makes those = attributes problematic at best and dangerous at worst. What I'm doing in my deployment is set a PKINIT ACL on the Kerberos = identity matching the Subject the issuer put in the card's cert. (Those = attributes are given no authority, and all the client-side stuff that = tries to use them is just an annoying waste of time.) Then I made sure = any KCA-issued certs have a completely different form for the Subject. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From jhutz@cmu.edu Tue May 18 08:01:40 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8265E3A694E; Tue, 18 May 2010 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9TEh8Q-KVN8; Tue, 18 May 2010 08:01:39 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 1168B3A69B7; Tue, 18 May 2010 08:01:27 -0700 (PDT) Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4IF1IKL024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 11:01:19 -0400 (EDT) Date: Tue, 18 May 2010 11:01:18 -0400 From: Jeffrey Hutzelman To: "Henry B. Hotz" , Russ Allbery Message-ID: In-Reply-To: <2D657E58-3578-4BDD-ADF2-FDD0C3F9578F@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <8900F9010016226491F8D479@lysithea.fac.cs.cmu.edu> <4BF17CB6.20408@secure-endpoints.com> <87eihaxc8g.fsf@windlord.stanford.edu> <2D657E58-3578-4BDD-ADF2-FDD0C3F9578F@jpl.nasa.gov> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 15:01:40 -0000 --On Monday, May 17, 2010 06:35:46 PM -0700 "Henry B. Hotz" wrote: > This is off-topic, but the Microsoft UPN and the id-pkinit-san value in > the certificate are put there by the certificate issuer. In the case of > smart cards the issuer frequently (mostly?) is a different organization > from the one running the KDC and supporting PKINIT. That makes those > attributes problematic at best and dangerous at worst. Only if you blindly trust them. If you're going to trust an issuer for PKINIT, you'd better make sure you understand their naming policy. > What I'm doing in my deployment is set a PKINIT ACL on the Kerberos > identity matching the Subject the issuer put in the card's cert. Right, so the mapping between certificate subjects and Kerberos principals is done by lookup in your KDB, rather than by an algorithmic translation. PKINIT permits this, because it was anticipated that it would be common for KDC operators to want such a policy. It also permits the KDC to ignore the PKI entirely and record direct mappings between principals and individual certificates or public keys. -- Jeff From jhutz@cmu.edu Tue May 18 08:09:19 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49113A6A48; Tue, 18 May 2010 08:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.125 X-Spam-Level: X-Spam-Status: No, score=-5.125 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q3q4iDsNxeD; Tue, 18 May 2010 08:09:18 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 89AC33A68CE; Tue, 18 May 2010 08:09:18 -0700 (PDT) Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4IF90hA024464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 11:09:00 -0400 (EDT) Date: Tue, 18 May 2010 11:09:00 -0400 From: Jeffrey Hutzelman To: jaltman@secure-endpoints.com, "Henry B. Hotz" Message-ID: In-Reply-To: <4BF21ADF.5090301@secure-endpoints.com> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> <4BF21ADF.5090301@secure-endpoints.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 15:09:19 -0000 --On Tuesday, May 18, 2010 12:43:11 AM -0400 Jeffrey Altman wrote: > On 5/17/2010 3:13 PM, Henry B. Hotz wrote: >> That's probably the right technical solution. Since I'm in the middle >> of trying to figure out how to get a JPL CA certified, I'd expect some >> non-trivial auditing costs associated with that approach. Maybe easier >> to just give each one a unique serial number prefix. > > There are multiple ways to handle this. The draft does not have to > indicate what approach should be taken as long as the requirement is met. Agree. > The existing deployed versions do not support delivering certificate > chains. > >> For the next version, I'd say the KCA MAY return the chain and define a >> place in the ASN1. > > I believe what you need to say is that the KCA clients must be prepared > to accept certificate chains if they are provided. The existing clients > do not. Well, you'd also have to define a way to do so. This is clearly a protocol change, and my comments, at least, were in the context of a potential revision _after_ the informational document. > The fact that some UMich code stores an X.509 client certificate and > private key within a Kerberos v5 FILE: credential cache is very much a > hack. If a certificate/key is going to be stored somewhere it should be > in the certificate/key store provided by the OS and used by the majority > of applications. It's a hack, but it's a useful hack, on some platforms. It is also widely supported in existing KX509 implementations, and so IMHO is worth documenting to the extent that the present document does so. Whether we continue to include that information in a revised protocol document is another question entirely. > Several people over the years have recommended that a PKCS#11 library > should automatically fetch a client certificate on behalf of a user at > the time the certificate is required. Given the way that most if not > all TLS libraries work, that would require the PKCS#11 module be aware > of all of the potential KCA certs that could be requested along with the > properly binding to the correct Kerberos principal and credential cache. Yes, there's an identity management problem here. There's nothing new about that. >> In other words, the use profile ought to be the same as any other >> Kerberized service. > > I believe that the X.509 KCA cert is the equivalent to a TGT. A TGT is > not automatically fetched when contacting a service and neither should a > KCA cert be. On the contrary, a KCA cert is the equivalent of a _cross-realm_ TGT, which most definitely is fetched automatically when appropriate. I see no problem with automatically fetching a KCA cert when contacting a service that would accept such a cert. Of course, the difficulty is that the primary means of automatic identity selection among PKCS#11 users is to compare issuers of certificates one has with those the service claims to trust, and one cannot do that until one actually _has_ the certificate. > Not only do I believe it is out of scope but that it should actively be > avoided. The Kerberos v5 credential cache does not have the appropriate > infrastructure to manage non-Kerberos tickets. You appear to be saying "it won't work", but that is demonstrably untrue. If you think we should actively discourage this feature, you need a stronger argument than that. -- Jeff From alan.sill@ttu.edu Fri May 14 06:55:31 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042713A6903; Fri, 14 May 2010 06:55:31 -0700 (PDT) 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_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jkwq6sxFOCO; Fri, 14 May 2010 06:55:29 -0700 (PDT) Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by core3.amsl.com (Postfix) with ESMTP id 3F0B73A68B1; Fri, 14 May 2010 06:55:24 -0700 (PDT) Received: from hyperbius.net.ttu.edu (129.118.1.214) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.2.254.0; Fri, 14 May 2010 08:55:12 -0500 Received: from es103.dhcp.ttu.edu (129.118.38.230) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 May 2010 08:55:11 -0500 Message-ID: From: Alan Sill To: "Henry B. Hotz" In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 May 2010 08:55:11 -0500 References: X-Mailer: Apple Mail (2.936) Received-SPF: Pass (eurymedon.net.ttu.edu: domain of Alan.Sill@ttu.edu designates 129.118.1.214 as permitted sender) receiver=eurymedon.net.ttu.edu; client-ip=129.118.1.214; helo=hyperbius.net.ttu.edu; X-TechMail-Edge-Route: TTU X-Mailman-Approved-At: Tue, 18 May 2010 08:25:02 -0700 Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" , Alan Sill Subject: Re: [saag] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 13:55:31 -0000 In this context, I recommend study of the IGTF's relevant authentication profiles. There are at least two (SLCS and MICS) that are relevant here. Both are linked from the home page http://igtf.net SLCS covers kx509 and similar services to turn internally held secure directories into X.509 short-term certs. SLCS is oriented toward this "non-exhaustive list" of sources for issuing short-lived certs. 1. Kerberos-based authentication service 2. Windows Domain 3. One Time password service 4. Another PKI with long term certificates 5. LDAP User Account service 6. Shibboleth-based federation MICS is a generalization and variation of the SLCS profile aimed at similar situations, but can in some cases issue long-lived certs. While these are not per se PKIX topics, in that the structure of the cert is governed more by GFD.125 (the grid certificate profile of OGF), it shows that there are no specific reasons that we cannot already handle kx509 acceptably in the extensive existing range of existing profiles. What specific problem would you want to solve in the context of PKIX with respect to kx509 that is not already solved by the above? (Not a hostile question, I'm just curious.) On May 13, 2010, at 8:32 PM, Henry B. Hotz wrote: > I have just submitted the KX509 draft which I discussed in the > Kerberos working group in Anaheim. It's available at https://datatracker.ietf.org/doc/draft-hotz-kx509/ > . > > The immediate question is where (if anywhere) should work on this > draft take place. Since it's function is to translate Kerberos > tickets into X.509 certificates, it might equally be handled by the > krb-wg, or pkix. Since I understand it's outside the precise > charter of both, perhaps saag should step in. > > What interest is there in handling work on this? > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix Alan Sill, Ph.D Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ==================================================================== From jaltman@secure-endpoints.com Mon May 17 10:29:36 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3626228C144 for ; Mon, 17 May 2010 10:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50h3WzOomllp for ; Mon, 17 May 2010 10:29:35 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 5EBC83A6ABB for ; Mon, 17 May 2010 10:28:40 -0700 (PDT) Received: from www.secure-endpoints.com (cpe-24-193-47-88.nyc.res.rr.com [24.193.47.88]) (user=jea31 mech=LOGIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4HHSVQc005783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 17 May 2010 13:28:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1274117265; x=1274722065; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=h4YSFlO447y8OLrK8s BXM1gI2D+rlpr669Im8kD0S1c=; b=sQaIvdqExCO0Voriu0jvhHKpZd/P71csxg Nu44mvdH1oAEB1XEkY5pNnv5e4KmE/JsB+i5XDzu7L9sQyxAW8QHm30CLGNcsDNv CUT5/sE4kuPoXWTqwXK5xMnDeFaDAvosjfJ4WldLN+4Q0REv6dDQSLBfz8lkAncI OgVnSYvG0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=R9oeH5cb07wrwilRGLGZIyTiyMDtmPie8fcitZTqdkYbNUY2QZtVzzMoVFs8 FDeCUOd82dn1KRzZpJwqylHqOpf+1sa4qgPmAlFVEPm/HuTkiePCODpBB RzlbNb+dBBswKjrgDrXstGfcXAJRE3nQr4hLcU0eQL6dujl68XBWVE=; X-MDAV-Processed: www.secure-endpoints.com, Mon, 17 May 2010 13:27:45 -0400 Received: from [172.16.1.5] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v11.0.1) with ESMTP id md50000238777.msg for ; Mon, 17 May 2010 13:27:45 -0400 X-Spam-Processed: www.secure-endpoints.com, Mon, 17 May 2010 13:27:45 -0400 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=ool-457cc3af.dyn.optonline.net (ip=69.124.195.175) (www.secure-endpoints.com) X-MDHeloLookup-Result: hardfail smtp.helo=[172.16.1.5] (does not match 69.124.195.175) (www.secure-endpoints.com) X-Authenticated-Sender: jaltman@secure-endpoints.com X-MDRemoteIP: 69.124.195.175 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: saag@ietf.org Message-ID: <4BF17CB6.20408@secure-endpoints.com> Date: Mon, 17 May 2010 13:28:22 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <8900F9010016226491F8D479@lysithea.fac.cs.cmu.edu> In-Reply-To: <8900F9010016226491F8D479@lysithea.fac.cs.cmu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030703040406070808080407" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 X-Mailman-Approved-At: Tue, 18 May 2010 08:26:31 -0700 Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 17:29:36 -0000 This is a cryptographically signed message in MIME format. --------------ms030703040406070808080407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/17/2010 1:22 PM, Jeffrey Hutzelman wrote: > FWIW, the present issue is exactly why I and others have been so > aggressive in making the point that presence of a particular name type > does not and should not imply that a certificate is acceptable for a > particular use. By allowing PKINIT implementations to infer such an > implication, we've essentially destroyed the usefulness of the > KRB5PrincipalName SAN for other usages. >=20 >=20 > This is going to suck, but I think I'm going to propose the > specification of a new name type which has the form of KRB5PrincipalNam= e > but an OID distinct from that of id-pkinit-san. The new type would be > usable any time an issuer wishes to identify a certificate as belonging= > to a particular principal, and would explicitly _not_ imply usability > for PKINIT or any other application. In fact, I think I'd go so far as= > to specify that PKINIT implementations MUST NOT accept certificates on > the basis of the new name type unless the id-pkinit-KPClientAuth EKU is= > present. It is then unfortunate that deployed KCA implementations have been using the KRB5PrincipalName type for many many years now. The KCA developers lifted the name type from the same place that PKINIT did. It is too late to put the genie back in the bottle. Jeffrey Altman --------------ms030703040406070808080407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEAMF9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoX DTEwMDgyODA0MDExOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDZNscYIvF6xzGSAfa/QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6 y0zlFqSbiFwgNM8m69K6m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWL kNdaXQKk6EZVW9pfV2A4Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iE jVhVzPobuZzwD2tuepY/bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1Zp Yh8Fx+9cqsG8O4nqo26SVfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOK ifHDyLZQC4qSsCUfP7vdwAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/Z cW3icObO9FIZCSmgFMt2Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAxcwggKAoAMCAQICEAMF 9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoXDTEwMDgyODA0MDExOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZNscYIvF6xzGSAfa/ QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6y0zlFqSbiFwgNM8m69K6 m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWLkNdaXQKk6EZVW9pfV2A4 Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iEjVhVzPobuZzwD2tuepY/ bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1ZpYh8Fx+9cqsG8O4nqo26S VfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOKifHDyLZQC4qSsCUfP7vd wAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/ZcW3icObO9FIZCSmgFMt2 Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIID bQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AwX1FMIY7PXnV9OkcuKH5zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1MTcxNzI4MjJaMCMGCSqGSIb3DQEJBDEWBBRIeghc G7VAK/hXEnhKvIdSORcSIzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhADBfUUwhjs9edX06Ry4ofnMIGHBgsqhkiG9w0BCRACCzF4oHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhADBfUUwhjs 9edX06Ry4ofnMA0GCSqGSIb3DQEBAQUABIIBAL2SeS/BuU1GkgjGumN2Q0l8+gDkW6x/r17L faJUbrPSkXdPJAG+aeOZVhhxa72wNFgy96/Y77HvTKX4LFoxltkSnGBnWFJAEjYrzbeCnSlE nuCQy/CJosAw8YIyiurFzxSjFBQn2oDmVPoBXztqKqEIHtVtG5fqjW4eCtXKGC/0PiMV/u3W ryaZlNCfR3ddthqauX7JGjZIDPmyHycE6W8klCL9RtCcY19tn5eUeGgYQsELWCA/ZtKcqSmo N5y44TYV5Qq7bz8WZsvBF4nuBz63ymLgzU/jB5xjGRBdIGGimOankZc13/wjs8y8BuMKLcrL l7yziRopf+BcfTao9p8AAAAAAAA= --------------ms030703040406070808080407-- From mstjohns@comcast.net Thu May 13 19:20:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE473A67EB for ; Thu, 13 May 2010 19:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG7Ibr5kgWh8 for ; Thu, 13 May 2010 19:20:23 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id EBF3D3A69E5 for ; Thu, 13 May 2010 19:20:22 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta06.westchester.pa.mail.comcast.net with comcast id HBpF1e00C0bG4ec56EL6r8; Fri, 14 May 2010 02:20:06 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta03.westchester.pa.mail.comcast.net with comcast id HEL51e00L1EtFYL3PEL5nk; Fri, 14 May 2010 02:20:06 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 May 2010 22:20:03 -0400 To: "Henry B. Hotz" ,ietf-krb-wg@lists.anl.gov, pkix@ietf.org,saag@ietf.org From: Michael StJohns In-Reply-To: <7ACFE4E5-080E-42C0-8867-A99DBC930B19@jpl.nasa.gov> References: <7ACFE4E5-080E-42C0-8867-A99DBC930B19@jpl.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <20100514022022.EBF3D3A69E5@core3.amsl.com> X-Mailman-Approved-At: Tue, 18 May 2010 08:26:36 -0700 Subject: Re: [saag] [pkix] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 02:20:24 -0000 At 09:32 PM 5/13/2010, Henry B. Hotz wrote: > =95 Use of subject Alt e-mail field for principal name >(I think I disagree with the last, since IMO a principal only looks like an= email address, and it won't necessarily work as one. If it's existing= practice, then fine, but delete it in the new version.) See RFC4456 - specifically the id-pkinit-san subject alternative name= encoding which defines a kerberos centric certificate name encoding. Mike From mrex@sap.com Fri May 14 10:09:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0325E3A6926; Fri, 14 May 2010 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.745 X-Spam-Level: X-Spam-Status: No, score=-7.745 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW2Rakp4781e; Fri, 14 May 2010 10:09:23 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E00113A6877; Fri, 14 May 2010 10:09:22 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4EH93Qg018402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 19:09:03 +0200 (MEST) From: Martin Rex Message-Id: <201005141709.o4EH92OI022790@fs4113.wdf.sap.corp> To: mstjohns@comcast.net (Michael StJohns) Date: Fri, 14 May 2010 19:09:02 +0200 (MEST) In-Reply-To: <20100514022006.53A267CC05E@mailrelay.anl.gov> from "Michael StJohns" at May 13, 10 10:20:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out X-Mailman-Approved-At: Tue, 18 May 2010 08:26:35 -0700 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] [pkix] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:09:24 -0000 Michael StJohns wrote: > > At 09:32 PM 5/13/2010, Henry B. Hotz wrote: > > • Use of subject Alt e-mail field for principal name > >(I think I disagree with the last, since IMO a principal only looks like an email address, and it won't necessarily work as one. If it's existing practice, then fine, but delete it in the new version.) > > See RFC4456 - specifically the id-pkinit-san subject alternative name > encoding which defines a kerberos centric certificate name encoding. It seems that Microsoft has been shipping functionality to include _some_ principal name ("UPN") in X.509v3 certificates, in a subjectAltName type "other" with the OID 1.3.6.1.4.1.311.20.2.3. Unfortunately it shares the awkwardness with their APIs in that it is not a valid Kerberos principal name. The uppper/lowercasing of the Realm part is definitely incorrect, and I wouldn't bet on the correctness of the upper/lower-casing on the part before the "@" either. So that entry is a someone unusable unless oneself happens to be the responsible Active Directory that is cabable to correctly canonicalize that UPN into a correct Kerberos principal name for use within Kerberos protocol exchanges. -Martin From tmiller@mitre.org Fri May 14 11:10:12 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368443A6816; Fri, 14 May 2010 11:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHKCFB2Rv2Q7; Fri, 14 May 2010 11:10:11 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7123A3A67BD; Fri, 14 May 2010 11:10:10 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4EIA0OZ015538; Fri, 14 May 2010 14:10:00 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4EIA0J1015528; Fri, 14 May 2010 14:10:00 -0400 Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 14 May 2010 14:10:00 -0400 From: "Miller, Timothy J." To: "'mrex@sap.com'" , Michael StJohns Date: Fri, 14 May 2010 14:09:59 -0400 Thread-Topic: [pkix] [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00 Thread-Index: Acrzj4t36Fn1xIDlQsO7a9+1El4rNAAAMlIw Message-ID: <17FD76C1ECD0AB49817637E21809ABF9082FEDA5C7@IMCMBX2.MITRE.ORG> References: <20100514022006.53A267CC05E@mailrelay.anl.gov> from "Michael StJohns" at May 13, 10 10:20:03 pm <201005141709.o4EH92OI022790@fs4113.wdf.sap.corp> In-Reply-To: <201005141709.o4EH92OI022790@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 18 May 2010 08:26:34 -0700 Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [pkix] [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:10:12 -0000 >Unfortunately it shares the awkwardness with their APIs in that it >is not a valid Kerberos principal name. That's because it's not a principal name at all. If you inspect the PKINIT= packets Windows emits, they use NT-ENTERPRISE for this identifier. NT-ENT= ERPRISE is an arbitrary identifier that maps to a unique principal name. Windows principal names are sAMAccountName@DOMAIN.FQDN. -- Tim >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Martin Rex >Sent: Friday, May 14, 2010 12:09 PM >To: Michael StJohns >Cc: pkix@ietf.org; ietf-krb-wg@lists.anl.gov; saag@ietf.org >Subject: Re: [pkix] [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00 > >Michael StJohns wrote: >> >> At 09:32 PM 5/13/2010, Henry B. Hotz wrote: >> > * Use of subject Alt e-mail field for principal name >> >(I think I disagree with the last, since IMO a principal only looks >like an email address, and it won't necessarily work as one. If it's >existing practice, then fine, but delete it in the new version.) >> >> See RFC4456 - specifically the id-pkinit-san subject alternative name >> encoding which defines a kerberos centric certificate name encoding. > >It seems that Microsoft has been shipping functionality to include >_some_ principal name ("UPN") in X.509v3 certificates, in a >subjectAltName type "other" with the OID 1.3.6.1.4.1.311.20.2.3. > >Unfortunately it shares the awkwardness with their APIs in that it >is not a valid Kerberos principal name. The uppper/lowercasing >of the Realm part is definitely incorrect, and I wouldn't bet on >the correctness of the upper/lower-casing on the part before >the "@" either. So that entry is a someone unusable unless oneself >happens to be the responsible Active Directory that is cabable to >correctly canonicalize that UPN into a correct Kerberos principal >name for use within Kerberos protocol exchanges. > >-Martin >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Fri May 14 12:11:44 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037833A6BE3; Fri, 14 May 2010 12:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU-TtwFalwkc; Fri, 14 May 2010 12:11:40 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 00F363A6BA2; Fri, 14 May 2010 12:11:34 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4EJBO4b008956; Fri, 14 May 2010 15:11:25 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4EJBOC8008953; Fri, 14 May 2010 15:11:24 -0400 Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 14 May 2010 15:11:24 -0400 From: "Miller, Timothy J." To: "'Douglas E. Engert'" Date: Fri, 14 May 2010 15:11:23 -0400 Thread-Topic: [Ietf-krb-wg] [pkix] Updates Needed for draft-hotz-kx509-00 Thread-Index: AcrzlWD7AneazAYjSneyVHivQ0PhHwAADkfg Message-ID: <17FD76C1ECD0AB49817637E21809ABF9082FEDA5C9@IMCMBX2.MITRE.ORG> References: <20100514022006.53A267CC05E@mailrelay.anl.gov> from "Michael StJohns" at May 13, 10 10:20:03 pm <201005141709.o4EH92OI022790@fs4113.wdf.sap.corp> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5C7@IMCMBX2.MITRE.ORG> <4BED99DE.9030109@anl.gov> In-Reply-To: <4BED99DE.9030109@anl.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 18 May 2010 08:26:34 -0700 Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "'mrex@sap.com'" , Michael StJohns , "saag@ietf.org" Subject: Re: [saag] [Ietf-krb-wg] [pkix] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:11:44 -0000 >And IIRC, one can still kinit using either sAMAccountName@DOMAIN.FQDN >or the userPrincipalName value. Yep. I've done this for kinit w/ both Heimdal and MIT Kerberos clients and= Microsoft KDCs. > So CAC or PIV cards with a MSUPN li= ke >nnnnnnnnnnnnn@FEDIDCARD.GOV to the cert can still work on W2003 DCs. As long as you set the sAMAccountName to 'nnnnnnnnnnnnn' you can use NT-PRI= NCIPAL in the AS-REQ, but you still must have 'nnnnnnnnnnnnn' in the UPN or= the Win2k3 KDC will blow chunks. >With W2008s DC the subjectAltName does not need to be in the >certificate, and some other mapping of certs to accounts can be used. Depending on whether or not the user entered a domain hint or username hint= (or both) in the Credential Provider UI and whether or not the UPN is in t= he selected certificate, the Windows Vista and Win7 clients send either NT-= PRINCIPAL with the actual principal name (or the client's guess as to what = that principal name should be), NT-ENTERPRISE with the userPrincipalName fr= om the cert, or NT-X500-PRINCIPAL with the certificate subject distinguishe= d name. Only the Win2k8 KDC can deal properly with NT-PRINCIPAL or NT-X500-PRINCIPA= L when the UPN is not also in the PKINIT certificate, and in both cases wil= l attempt discovery of the mapped account (when NT-X500-PRINCIPAL is used) = or verifification the certificate mapping to the specific account (when NT-= PRINCIPAL or NT-ENTERPRISE is used) using any of 8 methods (upn, subject DN= , subject & issuer DNs, subject DN & issuer DN & serial, issuer DN & serial= , subject key identifier, sha1 hash of the public key, or rfc822name). > But= the damage >has been done, the userPrincipalName attribute is not what one might >expect. Exactly; the userPrincipalName...isn't. What a mess. However, I think this is probably way off topic. -- Tim >-----Original Message----- >From: Douglas E. Engert [mailto:deengert@anl.gov] >Sent: Friday, May 14, 2010 1:44 PM >To: Miller, Timothy J. >Cc: 'mrex@sap.com'; Michael StJohns; pkix@ietf.org; ietf-krb- >wg@lists.anl.gov; saag@ietf.org >Subject: Re: [Ietf-krb-wg] [pkix] Updates Needed for draft-hotz-kx509-00 > > > >Miller, Timothy J. wrote: >>> Unfortunately it shares the awkwardness with their APIs in that it >>> is not a valid Kerberos principal name. >> >> That's because it's not a principal name at all. If you inspect the >PKINIT packets Windows emits, they use NT-ENTERPRISE for this >identifier. NT-ENTERPRISE is an arbitrary identifier that maps to a >unique principal name. >> > >When Microsoft started using smart cads the the principal as the >subjectAltName othername MSUPN to the cards. This was a simple way >to map a cert to an AD account using the existing attribute of >userPrincipalName. This would only work if the card is issued by >the enterprise CA. > >So over the years things have changed. One can change the account >userPrincipalName attribute to match whatever is on the smart card and >as you point out W2003 will also look at: > >> Windows principal names are sAMAccountName@DOMAIN.FQDN. > >And IIRC, one can still kinit using either sAMAccountName@DOMAIN.FQDN >or the userPrincipalName value. So CAC or PIV cards with a MSUPN like >nnnnnnnnnnnnn@FEDIDCARD.GOV to the cert can still work on W2003 DCs. > >With W2008s DC the subjectAltName does not need to be in the >certificate, >and some other mapping of certs to accounts can be used. But the damage >has been done, the userPrincipalName attribute is not what one might >expect. > > >> >> -- Tim >> >> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >Of >>> Martin Rex >>> Sent: Friday, May 14, 2010 12:09 PM >>> To: Michael StJohns >>> Cc: pkix@ietf.org; ietf-krb-wg@lists.anl.gov; saag@ietf.org >>> Subject: Re: [pkix] [Ietf-krb-wg] Updates Needed for draft-hotz- >kx509-00 >>> >>> Michael StJohns wrote: >>>> At 09:32 PM 5/13/2010, Henry B. Hotz wrote: >>>>> * Use of subject Alt e-mail field for principal name >>>>> (I think I disagree with the last, since IMO a principal only looks >>> like an email address, and it won't necessarily work as one. If it's >>> existing practice, then fine, but delete it in the new version.) >>>> See RFC4456 - specifically the id-pkinit-san subject alternative >name >>>> encoding which defines a kerberos centric certificate name encoding. >>> It seems that Microsoft has been shipping functionality to include >>> _some_ principal name ("UPN") in X.509v3 certificates, in a >>> subjectAltName type "other" with the OID 1.3.6.1.4.1.311.20.2.3. >>> >>> Unfortunately it shares the awkwardness with their APIs in that it >>> is not a valid Kerberos principal name. The uppper/lowercasing >>> of the Realm part is definitely incorrect, and I wouldn't bet on >>> the correctness of the upper/lower-casing on the part before >>> the "@" either. So that entry is a someone unusable unless oneself >>> happens to be the responsible Active Directory that is cabable to >>> correctly canonicalize that UPN into a correct Kerberos principal >>> name for use within Kerberos protocol exchanges. >>> >>> -Martin >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> ietf-krb-wg mailing list >> ietf-krb-wg@lists.anl.gov >> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg >> >> > >-- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 From mrex@sap.com Fri May 14 12:20:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8C93A6A2D; Fri, 14 May 2010 12:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.014 X-Spam-Level: X-Spam-Status: No, score=-9.014 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9evuquGhmqN; Fri, 14 May 2010 12:20:48 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 54F5328C15C; Fri, 14 May 2010 12:19:18 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4EJIs9c017599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 21:18:54 +0200 (MEST) From: Martin Rex Message-Id: <201005141918.o4EJIs80029787@fs4113.wdf.sap.corp> Orig-To: hotz@jpl.nasa.gov (Henry B. Hotz) To: ietf-krb-wg@lists.anl.gov, pkix@ietf.org, saag@ietf.org Date: Fri, 14 May 2010 20:24:02 +0200 (MEST) In-Reply-To: <7ACFE4E5-080E-42C0-8867-A99DBC930B19@jpl.nasa.gov> from "Henry B. Hotz" at May 13, 10 06:32:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal05 X-SAP: out X-Mailman-Approved-At: Tue, 18 May 2010 08:26:36 -0700 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:20:49 -0000 Henry B. Hotz wrote: > > Certificate encoding needs more specification. > In particular I'm told that the issued certificates should include: > > o KCA "1.3.6.1.4.1.250.42" > o KCA AUTH REALM "1.3.6.1.4.1.250.42.1" > o Krb5 Principal Name "1.3.6.1.5.2.2" > o Use of subject Alt e-mail field for principal name > > (I think I disagree with the last, since IMO a principal only looks > like an email address, and it won't necessarily work as one. > If it's existing practice, then fine, but delete it in the new version.) I agree to your disagreement with the last. The problematic thing with the rfc822Name subjectAltName is the underlying ASN.1 type: http://tools.ietf.org/html/rfc5280#page-128 GeneralName ::= CHOICE { otherName [0] AnotherName, rfc822Name [1] IA5String, dNSName [2] IA5String, I don't recall a desision that I18N for Kerberos principal names was going to use an "ascii compatible encoding"... 8-] -Martin From tmiller@mitre.org Mon May 17 07:26:57 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6B63A6A56; Mon, 17 May 2010 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.058 X-Spam-Level: X-Spam-Status: No, score=-5.058 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3+xch-4K7s1; Mon, 17 May 2010 07:26:57 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id AD7153A6A6A; Mon, 17 May 2010 07:22:52 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4HEMiCI032738; Mon, 17 May 2010 10:22:44 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4HEMiXV032735; Mon, 17 May 2010 10:22:44 -0400 Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 17 May 2010 10:22:43 -0400 From: "Miller, Timothy J." To: "'Sam Hartman'" , Jeffrey Hutzelman Date: Mon, 17 May 2010 10:22:42 -0400 Thread-Topic: [pkix] [saag] Draft KX509 Proposal Thread-Index: Acr0dEVPxKjvYX+gQ6+ja346fct0WQBV+JFw Message-ID: <17FD76C1ECD0AB49817637E21809ABF9082FEDA5CB@IMCMBX2.MITRE.ORG> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 18 May 2010 08:26:34 -0700 Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 14:26:58 -0000 PKINIT requires additional EKUs (unless the KDC isn't enforcing this), so a= profile with a Kerberos principal name SAN isn't sufficient by itself. However I agree with the general sentiment. KX509 can act like a credentia= l elevator, which makes me uncomfortable, but I haven't made up my mind re:= further work on the protocol. -- Tim >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Sam Hartman >Sent: Saturday, May 15, 2010 11:38 AM >To: Jeffrey Hutzelman >Cc: pkix@ietf.org; ietf-krb-wg@lists.anl.gov; saag@ietf.org >Subject: Re: [pkix] [saag] Draft KX509 Proposal > >What are the implications of using the pkinit SAN on being able to turn >around and use a KCA certificate with pkinit? I'd assume that you >really do not want to permit that usage under normal circumstances, at >least not with the AS that issued the cert. >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From eagle@windlord.stanford.edu Mon May 17 17:52:45 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C183A6B9F; Mon, 17 May 2010 17:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riKs3KD3benf; Mon, 17 May 2010 17:52:43 -0700 (PDT) Received: from smtp.stanford.edu (smtp4.Stanford.EDU [171.67.219.84]) by core3.amsl.com (Postfix) with ESMTP id 0D5E53A6B71; Mon, 17 May 2010 17:52:40 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CBC5C632; Mon, 17 May 2010 17:52:32 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 8004DCA80; Mon, 17 May 2010 17:52:31 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 740CE2F47F; Mon, 17 May 2010 17:52:31 -0700 (PDT) From: Russ Allbery To: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org In-Reply-To: <4BF17CB6.20408@secure-endpoints.com> (Jeffrey Altman's message of "Mon, 17 May 2010 13:28:22 -0400") Organization: The Eyrie References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <8900F9010016226491F8D479@lysithea.fac.cs.cmu.edu> <4BF17CB6.20408@secure-endpoints.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Date: Mon, 17 May 2010 17:52:31 -0700 Message-ID: <87eihaxc8g.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 18 May 2010 08:26:35 -0700 Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 00:52:45 -0000 Jeffrey Altman writes: > On 5/17/2010 1:22 PM, Jeffrey Hutzelman wrote: >> FWIW, the present issue is exactly why I and others have been so >> aggressive in making the point that presence of a particular name type >> does not and should not imply that a certificate is acceptable for a >> particular use. By allowing PKINIT implementations to infer such an >> implication, we've essentially destroyed the usefulness of the >> KRB5PrincipalName SAN for other usages. >> This is going to suck, but I think I'm going to propose the >> specification of a new name type which has the form of >> KRB5PrincipalName but an OID distinct from that of id-pkinit-san. The >> new type would be usable any time an issuer wishes to identify a >> certificate as belonging to a particular principal, and would >> explicitly _not_ imply usability for PKINIT or any other application. >> In fact, I think I'd go so far as to specify that PKINIT >> implementations MUST NOT accept certificates on the basis of the new >> name type unless the id-pkinit-KPClientAuth EKU is present. > It is then unfortunate that deployed KCA implementations have been using > the KRB5PrincipalName type for many many years now. The KCA developers > lifted the name type from the same place that PKINIT did. It is too > late to put the genie back in the bottle. While not ideal, this *can* be addressed operationally by telling implementors to not use the same root CA trust path for KCA-issued certificates as for PKINIT client authentication, yes? -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Mon May 17 21:44:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57103A6BDE for ; Mon, 17 May 2010 21:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1WeZ4Aergj0 for ; Mon, 17 May 2010 21:44:09 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 38ABD3A6A03 for ; Mon, 17 May 2010 21:44:04 -0700 (PDT) Received: from www.secure-endpoints.com (cpe-24-193-47-88.nyc.res.rr.com [24.193.47.88]) (user=jea31 mech=LOGIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4I4hrVt021217 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 May 2010 00:43:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1274157786; x=1274762586; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=GHvl+mSaH54ve7usOZ k+ZBEqTOV3ooOKiNr9O9gWmIE=; b=aT6zAIpbjYKfEJ2hDJYnHP3YS8i6lr5rIp /vjm7MIyT7/KEt93JSaukrqXPyt5AjTF6QrPgS5BTjK4Lytod94UrCrE6mPxBBYA zzaFICxO5j3ra+iiZsNeooKNQuMAUsilvyT0rD1cCJ8qSwYxZyXcK7kXqx7CJsaF OKa0lesDk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=Zp/nNVtN1DjzDyPHkR2LePmFoGLhCx6zCe2wU/Q4DeTA0AFvjWtI/jkqq3Wi k8CccIp+w/duBURjWAoku4ybiYvqvsO47MBnWLrD8KO2VoExsdK2pTBS6 Gs/2vIn1Bv3GxFEfTbzPykQ2h4YzbutaXMxgCaYEL+n5RpijUCqzZw=; X-MDAV-Processed: www.secure-endpoints.com, Tue, 18 May 2010 00:43:05 -0400 Received: from [172.16.1.5] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v11.0.1) with ESMTP id md50000239043.msg for ; Tue, 18 May 2010 00:43:03 -0400 X-Spam-Processed: www.secure-endpoints.com, Tue, 18 May 2010 00:43:03 -0400 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=ool-457cc3af.dyn.optonline.net (ip=69.124.195.175) (www.secure-endpoints.com) X-MDHeloLookup-Result: hardfail smtp.helo=[172.16.1.5] (does not match 69.124.195.175) (www.secure-endpoints.com) X-Authenticated-Sender: jaltman@secure-endpoints.com X-MDRemoteIP: 69.124.195.175 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: saag@ietf.org Message-ID: <4BF21ADF.5090301@secure-endpoints.com> Date: Tue, 18 May 2010 00:43:11 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: "Henry B. Hotz" References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> In-Reply-To: <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080602020906030008020408" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 X-Mailman-Approved-At: Tue, 18 May 2010 08:26:33 -0700 Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 04:44:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080602020906030008020408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/17/2010 3:13 PM, Henry B. Hotz wrote: > That's probably the right technical solution. Since I'm in the middle = of trying to figure out how to get a JPL CA certified, I'd expect some no= n-trivial auditing costs associated with that approach. Maybe easier to = just give each one a unique serial number prefix. There are multiple ways to handle this. The draft does not have to indicate what approach should be taken as long as the requirement is met.= >=20 > That's all implementation though. I think the requirement is just that= KCA's MUST issue certificates with globally unique serial numbers (someh= ow or other). Agreed. >>>> Could a certificate chain be returned? >>> >>> I'm neutral. Seems unnecessary, but easy to do (at least over TCP). >> >> I could see this being useful. In security-sensitive deployments the = root=20 >> CA will be carefully controlled, and its private key will likely be ke= pt=20 >> offline. As a result, the KCA itself will not be a root, and this the= re=20 >> will be at least one intermediate CA certificate. It therefore become= s=20 >> useful to be able to provide a client with the set of intermediates=20 >> required to get from the root to the newly-issued certificate. >=20 > Have to see if the UMICH KCA supports that. This draft is supposed to = document existing practice. The existing deployed versions do not support delivering certificate chai= ns. > For the next version, I'd say the KCA MAY return the chain and define a= place in the ASN1. I believe what you need to say is that the KCA clients must be prepared to accept certificate chains if they are provided. The existing clients do not. >>>> Appendix A says: "a widely used solution to this problem is to >>>> implement the KX509 client within a PKCS#11 library." I have seen >>>> a PKCS#11 library that access the kx509 certificate and key >>>> previously obtained by running a kx509 command, but not obtained fro= m >>>> within the PKCS#11 lib. Is there such an implementation? >>> >>> You're quite right. The version of the UMICH code I have has a build= >>> option to make the command into a library, but the pkcs11 library doe= s >>> not call it. IMO what I said is how it should work, but I don't beli= eve >>> that's what's actually in the wild. >> >> I'm not sure how that would work. Is enrollment even in scope for PKC= S#11? >=20 > IMO the way it ought to work (as opposed to how it works now) is when y= ou open the PKCS#11 library it should look for a an existing (unexpired) = cert in the Kerberos ccache. If there is, use it. If there isn't one, t= hen it goes and gets one (via KX509) and saves it to the ccache. The fact that some UMich code stores an X.509 client certificate and private key within a Kerberos v5 FILE: credential cache is very much a hack. If a certificate/key is going to be stored somewhere it should be in the certificate/key store provided by the OS and used by the majority of applications. Several people over the years have recommended that a PKCS#11 library should automatically fetch a client certificate on behalf of a user at the time the certificate is required. Given the way that most if not all TLS libraries work, that would require the PKCS#11 module be aware of all of the potential KCA certs that could be requested along with the properly binding to the correct Kerberos principal and credential cache. > In other words, the use profile ought to be the same as any other Kerbe= rized service. I believe that the X.509 KCA cert is the equivalent to a TGT. A TGT is not automatically fetched when contacting a service and neither should a KCA cert be. >>> Should this standard say anything about how the cert should be cached= in >>> a Kerberos credential cache? I see advantages to having UMICH/MIT co= de >>> share an already-feched certificate with Heimdal code, but I had >>> considered that to be out of scope for this work. I think I still do= =2E >> >> I agree that specifying the details of the file credential cache forma= t=20 >> used by some implementations is out of scope. >=20 > OK. Not only do I believe it is out of scope but that it should actively be avoided. The Kerberos v5 credential cache does not have the appropriate infrastructure to manage non-Kerberos tickets. Jeffrey Altman --------------ms080602020906030008020408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEAMF9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoX DTEwMDgyODA0MDExOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDZNscYIvF6xzGSAfa/QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6 y0zlFqSbiFwgNM8m69K6m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWL kNdaXQKk6EZVW9pfV2A4Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iE jVhVzPobuZzwD2tuepY/bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1Zp Yh8Fx+9cqsG8O4nqo26SVfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOK ifHDyLZQC4qSsCUfP7vdwAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/Z cW3icObO9FIZCSmgFMt2Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAxcwggKAoAMCAQICEAMF 9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoXDTEwMDgyODA0MDExOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZNscYIvF6xzGSAfa/ QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6y0zlFqSbiFwgNM8m69K6 m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWLkNdaXQKk6EZVW9pfV2A4 Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iEjVhVzPobuZzwD2tuepY/ bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1ZpYh8Fx+9cqsG8O4nqo26S VfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOKifHDyLZQC4qSsCUfP7vd wAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/ZcW3icObO9FIZCSmgFMt2 Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIID bQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AwX1FMIY7PXnV9OkcuKH5zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1MTgwNDQzMTFaMCMGCSqGSIb3DQEJBDEWBBSek5j6 XMeqxOaXHl0Wyn8bf36XRTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhADBfUUwhjs9edX06Ry4ofnMIGHBgsqhkiG9w0BCRACCzF4oHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhADBfUUwhjs 9edX06Ry4ofnMA0GCSqGSIb3DQEBAQUABIIBAE+WcbHxyjrE9wnZj+sR1+fCz8rdYEqeYg2Y Tu2GS+hOBUGIytO2p5Mc2kFMt1/SqesYtUFH3VCeruXG8oH8fCXcZfe9cGgQhwThNNXqEY9B lbRUgPMkR9pfAwasArJ8UBvGkPbjfn1MC75MaRVXK2og12/6dfUxL1k8UDrhc9/KN0u4ocQH nOTrAcEQW3MLV2HrlvDeM5YDtWDayajt2l79iaPdq74SYz5tYxQKoJizQSlEgq67DZQ+lqrj iWtxrZdePHCQ36bmbfWNbYBuyoMhC4RYJJ8Q3tAfLQ7Y6LzpU9eBkg3Mi0eBBBmJ8sOUU/7I IENaYFbfCVyf475ONu8AAAAAAAA= --------------ms080602020906030008020408-- From jhutz@cmu.edu Tue May 18 09:18:35 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339803A6C5A; Tue, 18 May 2010 09:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDvp+vHKXUgd; Tue, 18 May 2010 09:18:33 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id AFEB33A6C5B; Tue, 18 May 2010 09:13:24 -0700 (PDT) Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4IGDEwb026064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 12:13:14 -0400 (EDT) Date: Tue, 18 May 2010 12:13:14 -0400 From: Jeffrey Hutzelman To: jaltman@secure-endpoints.com Message-ID: <988B65E30D1F154448A9CC07@atlantis.pc.cs.cmu.edu> In-Reply-To: <4BF2B64D.60907@secure-endpoints.com> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> <4BF21ADF.5090301@secure-endpoints.com> <4BF2B64D.60907@secure-endpoints.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:18:35 -0000 --On Tuesday, May 18, 2010 11:46:21 AM -0400 Jeffrey Altman wrote: > Besides which, where a cert is stored has nothing to do with the > protocol and as such (in my opinion) should not be a part of an > Internet-Draft. Ordinarily, I'd agree. It certainly has no place in normative text. But for an informational draft describing the existing KX509, I think it's worth documenting that this is being done, as Henry has done in the existing appendix. I suggest leaving the appendix as-is in the current, without adding more detail but also not removing it. If/when the standards track document happens, we can remove it entirely from there. -- Jeff From hotz@jpl.nasa.gov Tue May 18 11:05:51 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FDF3A6A5A; Tue, 18 May 2010 11:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZv8pnTED-2j; Tue, 18 May 2010 11:05:50 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id CFFE43A6A73; Tue, 18 May 2010 11:05:50 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4II5fBC000936; Tue, 18 May 2010 11:05:41 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <988B65E30D1F154448A9CC07@atlantis.pc.cs.cmu.edu> Date: Tue, 18 May 2010 11:05:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17007A0C-7BE2-4416-80B4-EB4CFB4617D6@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <75FEA72D-131C-47FE-BFEB-299189A8D523@jpl.nasa.gov> <4BF21ADF.5090301@secure-endpoints.com> <4BF2B64D.60907@secure-endpoints.com> <988B65E30D1F154448A9CC07@atlantis.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "jaltman@secure-endpoints.com" , "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 18:05:51 -0000 I was going to write a response to Jeffrey A's email myself, but I agree = with Jeffrey H says (except I'll correct my factual error re existing = client behavior). Is Jeffrey A comfortable with postponing the rest of = the discussion until we have a revised protocol on the table? On May 18, 2010, at 9:13 AM, Jeffrey Hutzelman wrote: > --On Tuesday, May 18, 2010 11:46:21 AM -0400 Jeffrey Altman=20 > wrote: >=20 >> Besides which, where a cert is stored has nothing to do with the >> protocol and as such (in my opinion) should not be a part of an >> Internet-Draft. >=20 > Ordinarily, I'd agree. It certainly has no place in normative text. = But=20 > for an informational draft describing the existing KX509, I think it's=20= > worth documenting that this is being done, as Henry has done in the=20 > existing appendix. >=20 > I suggest leaving the appendix as-is in the current, without adding = more=20 > detail but also not removing it. If/when the standards track document=20= > happens, we can remove it entirely from there. >=20 > -- Jeff ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Tue May 18 11:07:34 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900FE3A688B; Tue, 18 May 2010 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.539 X-Spam-Level: X-Spam-Status: No, score=-5.539 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLM+OwKajDFh; Tue, 18 May 2010 11:07:33 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 08C9428C122; Tue, 18 May 2010 11:07:28 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4II7HK4001970; Tue, 18 May 2010 11:07:18 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Tue, 18 May 2010 11:07:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9919ADB6-1B4E-463E-862B-C24589ACCAB5@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <8900F9010016226491F8D479@lysithea.fac.cs.cmu.edu> <4BF17CB6.20408@secure-endpoints.com> <87eihaxc8g.fsf@windlord.stanford.edu> <2D657E58-3578-4BDD-ADF2-FDD0C3F9578F@jpl.nasa.gov> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , Russ Allbery , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [Ietf-krb-wg] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 18:07:35 -0000 On May 18, 2010, at 8:01 AM, Jeffrey Hutzelman wrote: > --On Monday, May 17, 2010 06:35:46 PM -0700 "Henry B. Hotz"=20 > wrote: >=20 >> This is off-topic, but the Microsoft UPN and the id-pkinit-san value = in >> the certificate are put there by the certificate issuer. In the case = of >> smart cards the issuer frequently (mostly?) is a different = organization >> from the one running the KDC and supporting PKINIT. That makes those >> attributes problematic at best and dangerous at worst. >=20 > Only if you blindly trust them. If you're going to trust an issuer = for=20 > PKINIT, you'd better make sure you understand their naming policy. The ringer here is I've hit an awful lot of client card infrastructure = that thinks you should fill in the username at login based on the UPN = (and I don't just mean on Microsoft clients). Figuring out how to = disable that behavior everywhere has been a royal PITA. I've been complaining about that a lot lately. Sorry if this off-topic = tangent is a repeat for people. >> What I'm doing in my deployment is set a PKINIT ACL on the Kerberos >> identity matching the Subject the issuer put in the card's cert. >=20 > Right, so the mapping between certificate subjects and Kerberos = principals=20 > is done by lookup in your KDB, rather than by an algorithmic = translation.=20 > PKINIT permits this, because it was anticipated that it would be = common for=20 > KDC operators to want such a policy. It also permits the KDC to = ignore the=20 > PKI entirely and record direct mappings between principals and = individual=20 > certificates or public keys. Well, I do verify the cert against a known CA, but skipping that's not = what you meant by "ignore", I'm sure. I anticipate needing to support PKINIT clients using certs from many = different issuers. This direct mapping approach is way more = straightforward and flexible (as long as I don't get multiple issuers = with overlapping subject name hierarchies). (It also adds fuel to my = flame concerning how clients handle the UPN and/or the id-kinit-san = attribute.) > -- Jeff ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Tue May 18 11:09:42 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEAF3A6903; Tue, 18 May 2010 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+igDnlXWGrN; Tue, 18 May 2010 11:09:41 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 182983A69BC; Tue, 18 May 2010 11:09:34 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4II9NaE003694; Tue, 18 May 2010 11:09:24 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Tue, 18 May 2010 11:09:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2ED4FF5F-7AA5-485A-AD86-2DD0412DCA5E@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5CB@IMCMBX2.MITRE.ORG> To: Sam Hartman X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, "Miller, Timothy J." , saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 18:09:42 -0000 On May 18, 2010, at 5:56 AM, Sam Hartman wrote: > Honestly, though, the more I think about this, this seems a classic > problem of trust: under most circumstances, the KCA should not be > trusted by the KDC's pkinit CA to issue any certificates. > > It seems like there are many ways to accomplish this: And you didn't even cover the one I actually implemented. ;-) ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From deengert@anl.gov Thu May 20 09:23:13 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88DD3A659A; Thu, 20 May 2010 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[AWL=-1.432, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6j4w9LEpna9; Thu, 20 May 2010 09:23:06 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by core3.amsl.com (Postfix) with ESMTP id E0BF93A6B1B; Thu, 20 May 2010 09:22:39 -0700 (PDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 204C5C0; Thu, 20 May 2010 11:22:33 -0500 (CDT) Received: from [IPv6:::1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 04321C2; Thu, 20 May 2010 11:22:32 -0500 (CDT) Message-ID: <4BF561C7.10500@anl.gov> Date: Thu, 20 May 2010 11:22:31 -0500 From: "Douglas E. Engert" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 16:23:13 -0000 Stefan Santesson wrote: > I'm replying to the initial message, having read the whole thread (at least > the part that has been sent to the PKIX list). > > There are many things with this draft and the discussion which confuses me > and I would be happy if you could help un-confuse me. The original kx509 http://www.citi.umich.edu/projects/kerb_pki/ the Readme file says Kx509 has been around with Kerberos V5 since at least 6/26/2000. I started working with this in August 1999. It has had wide use but no standards. Henry is attempting to do this. Thanks Henry. > > Firstly I don't see the relevance of the discussion at large in relation to > the draft. A lot of things discussed refers to use of name forms, trust > policies and the potential use of a KCA certificates for PKINIT. Even though > that is very interesting, I don't see anything in the draft that states that > a KCA issues certificates for any particular purpose. Strictly reading the > draft I see a CA that calls itself KCA only based on the fact that it can > accept this form of request supported by Kerberos authentication. > > If that is true, then the issued certificate could be any type of > certificate used for any purpose. The Kerberos ticket is then reduced to a > means of authentication and optionally a source of subject name information > (Kerberos principal name). > Agreed. > However, I see nothing that prevents the KCA to map the authenticated > Kerberos ticket to any other identity data based on a local identity > database trusted by the KCA. Agreed. > > If so, then I don't understand why you would limit the lifetime of the > certificate to the lifetime of the ticket. Similar to the Windows Auto Enroll certificates, The Kx509 certificates where originally meant to be short term and disposable where the key is not protected by a passphrase, but stored in temp protected bu the OS, accessible only to the user and deleted at logoff. The user could always get another one, and could have multiple Kx509 certificates one per session and could have them on multiple machines. Each certificate would have the same subject name derived from the principal name. Thus a web server would accept these as coming from the user. Since they are short term, the KCA may not produce CRLs. > Compare if I use an ID-card to > authenticate my identity to the passport issuance service, that does not > mean that my passport will be limited to the validity of my id-card. The > only thing is that my ID-card is valid when it is used. > > I don't understand why we need to invent a new certificate request format. > PKIX have already gone through the pain to develop certificate request > formats that are widely deployed. An obvious flaw in the current draft is > the lack of proof-of-possession of the corresponding private key, which > would be avoided if an existing request format was used The draft is attempting to document the current protocol. I agree that any new version should use PKIX request forms. > > Maybe small issue. The protocol has no wait message. It only delivers either > a certificate or an error. What if the request is pending for some reason? The original KCA would issue or not issue a certificate. There was no way to hold a request. But in a new version, maybe that would be a good idea, especially if you want to issue longer term certificates. > > Finally I don't understand why you need to limit the protocol to UDP, or > even why you need to specify the use of UDP in the first place. > Again that was how the original code worked. The Kerberos tickets and certificates were small, so UDP worked well. If the next version adds larger tickets, certificate chains some other protocol might be better. > > /Stefan > > > > > On 10-05-14 3:32 AM, "Henry B. Hotz" wrote: > >> I have just submitted the KX509 draft which I discussed in the Kerberos >> working group in Anaheim. It's available at >> https://datatracker.ietf.org/doc/draft-hotz-kx509/. >> >> The immediate question is where (if anywhere) should work on this draft take >> place. Since it's function is to translate Kerberos tickets into X.509 >> certificates, it might equally be handled by the krb-wg, or pkix. Since I >> understand it's outside the precise charter of both, perhaps saag should step >> in. >> >> What interest is there in handling work on this? >> >> ------------------------------------------------------ >> The opinions expressed in this message are mine, >> not those of Caltech, JPL, NASA, or the US Government. >> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@lists.anl.gov > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From stefan@aaa-sec.com Thu May 20 14:49:12 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17BA3A68CD for ; Thu, 20 May 2010 14:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elmI3BaeRmZX for ; Thu, 20 May 2010 14:49:12 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 7ACC63A67DB for ; Thu, 20 May 2010 14:49:08 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E8F3438795A for ; Thu, 20 May 2010 23:47:32 +0200 (CEST) Received: (qmail 14449 invoked from network); 20 May 2010 21:47:24 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 May 2010 21:47:24 -0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 20 May 2010 23:47:21 +0200 From: Stefan Santesson To: "Douglas E. Engert" Message-ID: Thread-Topic: [Ietf-krb-wg] [pkix] Draft KX509 Proposal Thread-Index: Acr4ZgZT6zhHkxgzUkmHbRC7jXjbtQ== In-Reply-To: <4BF561C7.10500@anl.gov> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org, ietf-krb-wg@lists.anl.gov, saag@ietf.org Subject: Re: [saag] [Ietf-krb-wg] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 21:49:12 -0000 Thanks for the explanations Douglas. That certainty brings a lot of clarity. If this is documenting an existing protocol, then that should be clearly stated. Perhaps it is and I just missed it? On 10-05-20 6:22 PM, "Douglas E. Engert" wrote: >> If so, then I don't understand why you would limit the lifetime of the >> certificate to the lifetime of the ticket. > > Similar to the Windows Auto Enroll certificates, The Kx509 certificates > where originally meant to be short term and disposable where the key is not > protected by a passphrase, but stored in temp protected bu the OS, accessible > only to the user and deleted at logoff. The user could always get another one, > and could have multiple Kx509 certificates one per session and could have them > on multiple machines. Each certificate would have the same subject name > derived > from the principal name. Thus a web server would accept these as coming from > the user. Since they are short term, the KCA may not produce CRLs. This to me is not an argument why this need to be a general rule. This is just explaining one out of many possible use cases. Microsoft auto-enrollment is not limited to short lived certificates. It is equally useful for managing issuance and renewal of long lived certificates. If the specification doesn't limit the scope of issued certificates, then I don't think it is appropriate to limit the validity either. The appropriate lifetime of a certificate is much more dependent on the protection of the private key and the stability of identification attributes, than it is dependent on the quality of authentication. That aspect does not degrade over time. IT either was, or was not good enough at the time of issuance. /Stefan From hotz@jpl.nasa.gov Fri May 21 00:57:57 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744FA3A6FCF; Fri, 21 May 2010 00:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.119 X-Spam-Level: X-Spam-Status: No, score=-5.119 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydp+LyYI8pBJ; Fri, 21 May 2010 00:57:56 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id D9E9B3A7DAF; Thu, 20 May 2010 22:35:29 -0700 (PDT) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4L5ZI2B015968 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Thu, 20 May 2010 22:35:19 -0700 Received: from [192.168.2.2] (128.149.137.113) by ums-smtp.jpl.nasa.gov (128.149.137.72) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 20 May 2010 22:35:18 -0700 MIME-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset="us-ascii" From: "Henry B. Hotz" In-Reply-To: Date: Thu, 20 May 2010 22:15:02 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Stefan Santesson X-Mailer: Apple Mail (2.1078) X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 07:57:57 -0000 What Doug said. ;-) On May 20, 2010, at 6:56 AM, Stefan Santesson wrote: > I'm replying to the initial message, having read the whole thread (at = least > the part that has been sent to the PKIX list). >=20 > There are many things with this draft and the discussion which = confuses me > and I would be happy if you could help un-confuse me. I think a lot of the comments are from people who already have some = familiarity with the protocol. > Firstly I don't see the relevance of the discussion at large in = relation to > the draft. A lot of things discussed refers to use of name forms, = trust > policies and the potential use of a KCA certificates for PKINIT. Even = though > that is very interesting, I don't see anything in the draft that = states that > a KCA issues certificates for any particular purpose. Strictly reading = the > draft I see a CA that calls itself KCA only based on the fact that it = can > accept this form of request supported by Kerberos authentication. While there are serious issues to point out in the security = considerations section, that's fundamentally true. Nothing is = technically out of scope or explicitly prohibited (or impossible even if = it were prohibited). Like everything else, you can shoot yourself in = the foot, hand, head, or anywhere else if you so choose. > If that is true, then the issued certificate could be any type of > certificate used for any purpose. The Kerberos ticket is then reduced = to a > means of authentication and optionally a source of subject name = information > (Kerberos principal name). I wouldn't deploy something that didn't include part of the Kerberos = principal name in the cert's Subject name. I could imagine someone = wanting to use a KCA to provide a kind of anonymous authentication = though. > However, I see nothing that prevents the KCA to map the authenticated > Kerberos ticket to any other identity data based on a local identity > database trusted by the KCA. Correct, though as a practical matter a UDP protocol with a fixed = timeout doesn't work well when the reply is dependent on other services' = replies. Kerberos services typically have shorter timeouts than LDAP = services for instance. > If so, then I don't understand why you would limit the lifetime of the > certificate to the lifetime of the ticket. Compare if I use an ID-card = to > authenticate my identity to the passport issuance service, that does = not > mean that my passport will be limited to the validity of my id-card. = The > only thing is that my ID-card is valid when it is used. If the expiration of your ID card actually represents an expiration of = the identity it represents, then it would be foolish to issue a passport = with a later expiration date. What you describe is done because the = date is usually the expiration of some authorization (e.g. to drive a = car) rather than of the identity itself. An expired passport is still = valid as identification (I just used a 2-year-expired one to get a new = passport). It just doesn't authorize you to travel. If you replicate the original expiration time, then that's "safe" from a = policy standpoint. It's also short enough you probably don't need an = OCSP server, etc. If you want to extend the lifetime, then you should = know why your particular infrastructure makes that reasonable. > I don't understand why we need to invent a new certificate request = format. > PKIX have already gone through the pain to develop certificate request > formats that are widely deployed. An obvious flaw in the current draft = is > the lack of proof-of-possession of the corresponding private key, = which > would be avoided if an existing request format was used. I think that's a perfectly valid criticism, which may be addressed in a = future revision of the protocol. In the mean time we have what's = already out in the wild. > Maybe small issue. The protocol has no wait message. It only delivers = either > a certificate or an error. What if the request is pending for some = reason? I think that's a perfectly. . . (see above) As noted in Appendix B, I don't fully specify timeout/retry behavior. I = confess the concept of a "wait" response is foreign to me. Could you = elaborate? > Finally I don't understand why you need to limit the protocol to UDP, = or > even why you need to specify the use of UDP in the first place. I think that's a perfectly. . . (see above) If I don't specify *some* transport mechanism then I haven't specified = enough for someone to build an interoperable implementation. > /Stefan As Doug noted, this protocol is actually fairly old. It was originally = implemented and documented with Kerberos 4, for instance. > On 10-05-14 3:32 AM, "Henry B. Hotz" wrote: >=20 >> I have just submitted the KX509 draft which I discussed in the = Kerberos >> working group in Anaheim. It's available at >> https://datatracker.ietf.org/doc/draft-hotz-kx509/. >>=20 >> The immediate question is where (if anywhere) should work on this = draft take >> place. Since it's function is to translate Kerberos tickets into = X.509 >> certificates, it might equally be handled by the krb-wg, or pkix. = Since I >> understand it's outside the precise charter of both, perhaps saag = should step >> in. >>=20 >> What interest is there in handling work on this? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Fri May 21 00:58:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A963A73F7; Fri, 21 May 2010 00:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ClIVQstgJiP; Fri, 21 May 2010 00:58:09 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 63CC53A68B5; Thu, 20 May 2010 22:35:43 -0700 (PDT) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4L5ZYX7016049 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Thu, 20 May 2010 22:35:34 -0700 Received: from [192.168.2.2] (128.149.137.113) by ums-smtp.jpl.nasa.gov (128.149.137.72) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 20 May 2010 22:35:33 -0700 MIME-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset="us-ascii" From: "Henry B.Hotz" In-Reply-To: Date: Thu, 20 May 2010 22:35:33 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Stefan Santesson X-Mailer: Apple Mail (2.1078) X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 07:58:10 -0000 What Doug said. ;-) On May 20, 2010, at 6:56 AM, Stefan Santesson wrote: > I'm replying to the initial message, having read the whole thread (at = least > the part that has been sent to the PKIX list). >=20 > There are many things with this draft and the discussion which = confuses me > and I would be happy if you could help un-confuse me. I think a lot of the comments are from people who already have some = familiarity with the protocol. > Firstly I don't see the relevance of the discussion at large in = relation to > the draft. A lot of things discussed refers to use of name forms, = trust > policies and the potential use of a KCA certificates for PKINIT. Even = though > that is very interesting, I don't see anything in the draft that = states that > a KCA issues certificates for any particular purpose. Strictly reading = the > draft I see a CA that calls itself KCA only based on the fact that it = can > accept this form of request supported by Kerberos authentication. While there are serious issues to point out in the security = considerations section, that's fundamentally true. Nothing is = technically out of scope or explicitly prohibited (or impossible even if = it were prohibited). Like everything else, you can shoot yourself in = the foot, hand, head, or anywhere else if you so choose. > If that is true, then the issued certificate could be any type of > certificate used for any purpose. The Kerberos ticket is then reduced = to a > means of authentication and optionally a source of subject name = information > (Kerberos principal name). I wouldn't deploy something that didn't include part of the Kerberos = principal name in the cert's Subject name. I could imagine someone = wanting to use a KCA to provide a kind of anonymous authentication = though. > However, I see nothing that prevents the KCA to map the authenticated > Kerberos ticket to any other identity data based on a local identity > database trusted by the KCA. Correct, though as a practical matter a UDP protocol with a fixed = timeout doesn't work well when the reply is dependent on other services' = replies. Kerberos services typically have shorter timeouts than LDAP = services for instance. > If so, then I don't understand why you would limit the lifetime of the > certificate to the lifetime of the ticket. Compare if I use an ID-card = to > authenticate my identity to the passport issuance service, that does = not > mean that my passport will be limited to the validity of my id-card. = The > only thing is that my ID-card is valid when it is used. If the expiration of your ID card actually represents an expiration of = the identity it represents, then it would be foolish to issue a passport = with a later expiration date. What you describe is done because the = date is usually the expiration of some authorization (e.g. to drive a = car) rather than of the identity itself. An expired passport is still = valid as identification (I just used a 2-year-expired one to get a new = passport). It just doesn't authorize you to travel. If you replicate the original expiration time, then that's "safe" from a = policy standpoint. It's also short enough you probably don't need an = OCSP server, etc. If you want to extend the lifetime, then you should = know why your particular infrastructure makes that reasonable. > I don't understand why we need to invent a new certificate request = format. > PKIX have already gone through the pain to develop certificate request > formats that are widely deployed. An obvious flaw in the current draft = is > the lack of proof-of-possession of the corresponding private key, = which > would be avoided if an existing request format was used. I think that's a perfectly valid criticism, which may be addressed in a = future revision of the protocol. In the mean time we have what's = already out in the wild. > Maybe small issue. The protocol has no wait message. It only delivers = either > a certificate or an error. What if the request is pending for some = reason? I think that's a perfectly. . . (see above) As noted in Appendix B, I don't fully specify timeout/retry behavior. I = confess the concept of a "wait" response is foreign to me. Could you = elaborate? > Finally I don't understand why you need to limit the protocol to UDP, = or > even why you need to specify the use of UDP in the first place. I think that's a perfectly. . . (see above) If I don't specify *some* transport mechanism then I haven't specified = enough for someone to build an interoperable implementation. > /Stefan As Doug noted, this protocol is actually fairly old. It was originally = implemented and documented with Kerberos 4, for instance. > On 10-05-14 3:32 AM, "Henry B. Hotz" wrote: >=20 >> I have just submitted the KX509 draft which I discussed in the = Kerberos >> working group in Anaheim. It's available at >> https://datatracker.ietf.org/doc/draft-hotz-kx509/. >>=20 >> The immediate question is where (if anywhere) should work on this = draft take >> place. Since it's function is to translate Kerberos tickets into = X.509 >> certificates, it might equally be handled by the krb-wg, or pkix. = Since I >> understand it's outside the precise charter of both, perhaps saag = should step >> in. >>=20 >> What interest is there in handling work on this? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From stefan@aaa-sec.com Fri May 21 07:59:14 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC48C3A84FE for ; Fri, 21 May 2010 07:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ng0A09sns3I for ; Fri, 21 May 2010 07:59:12 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 883013A857E for ; Fri, 21 May 2010 03:26:25 -0700 (PDT) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1C7C9397B5C for ; Fri, 21 May 2010 12:26:16 +0200 (CEST) Received: (qmail 12310 invoked from network); 21 May 2010 10:26:15 -0000 Received: from unknown (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.2.114]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 May 2010 10:26:15 -0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 21 May 2010 12:26:11 +0200 From: Stefan Santesson To: "Henry B. Hotz" Message-ID: Thread-Topic: [pkix] Draft KX509 Proposal Thread-Index: Acr40AhSO/D9zNzLrk690iGd/FOxTQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , "saag@ietf.org" Subject: Re: [saag] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 14:59:14 -0000 In line; On 10-05-21 7:15 AM, "Henry B. Hotz" wrote: > What Doug said. ;-) > > On May 20, 2010, at 6:56 AM, Stefan Santesson wrote: > >> I'm replying to the initial message, having read the whole thread (at least >> the part that has been sent to the PKIX list). >> >> There are many things with this draft and the discussion which confuses me >> and I would be happy if you could help un-confuse me. > > I think a lot of the comments are from people who already have some > familiarity with the protocol. > >> Firstly I don't see the relevance of the discussion at large in relation to >> the draft. A lot of things discussed refers to use of name forms, trust >> policies and the potential use of a KCA certificates for PKINIT. Even though >> that is very interesting, I don't see anything in the draft that states that >> a KCA issues certificates for any particular purpose. Strictly reading the >> draft I see a CA that calls itself KCA only based on the fact that it can >> accept this form of request supported by Kerberos authentication. > > While there are serious issues to point out in the security considerations > section, that's fundamentally true. Nothing is technically out of scope or > explicitly prohibited (or impossible even if it were prohibited). Like > everything else, you can shoot yourself in the foot, hand, head, or anywhere > else if you so choose. > >> If that is true, then the issued certificate could be any type of >> certificate used for any purpose. The Kerberos ticket is then reduced to a >> means of authentication and optionally a source of subject name information >> (Kerberos principal name). > > I wouldn't deploy something that didn't include part of the Kerberos principal > name in the cert's Subject name. I could imagine someone wanting to use a KCA > to provide a kind of anonymous authentication though. > >> However, I see nothing that prevents the KCA to map the authenticated >> Kerberos ticket to any other identity data based on a local identity >> database trusted by the KCA. > > Correct, though as a practical matter a UDP protocol with a fixed timeout > doesn't work well when the reply is dependent on other services' replies. > Kerberos services typically have shorter timeouts than LDAP services for > instance. > >> If so, then I don't understand why you would limit the lifetime of the >> certificate to the lifetime of the ticket. Compare if I use an ID-card to >> authenticate my identity to the passport issuance service, that does not >> mean that my passport will be limited to the validity of my id-card. The >> only thing is that my ID-card is valid when it is used. > > If the expiration of your ID card actually represents an expiration of the > identity it represents, then it would be foolish to issue a passport with a > later expiration date. Exactly. And since the it is not clear from the draft that the certificate will carry an identity that expires at the same time as the ticket, I don't see why the general rule is that the certificate should not survive past the ticket used for user authentication. > What you describe is done because the date is usually > the expiration of some authorization (e.g. to drive a car) rather than of the > identity itself. No. The expiry date of my drivers license is not a date when my license to drive expires. It is just a date when I have to renew the license, probably so that I can include a more recent photo and prevent it from falling apart. > An expired passport is still valid as identification (I just > used a 2-year-expired one to get a new passport). It just doesn't authorize > you to travel. > > If you replicate the original expiration time, then that's "safe" from a > policy standpoint. It's also short enough you probably don't need an OCSP > server, etc. If you want to extend the lifetime, then you should know why > your particular infrastructure makes that reasonable. > >> I don't understand why we need to invent a new certificate request format. >> PKIX have already gone through the pain to develop certificate request >> formats that are widely deployed. An obvious flaw in the current draft is >> the lack of proof-of-possession of the corresponding private key, which >> would be avoided if an existing request format was used. > > I think that's a perfectly valid criticism, which may be addressed in a future > revision of the protocol. In the mean time we have what's already out in the > wild. > >> Maybe small issue. The protocol has no wait message. It only delivers either >> a certificate or an error. What if the request is pending for some reason? > > I think that's a perfectly. . . (see above) > > As noted in Appendix B, I don't fully specify timeout/retry behavior. I > confess the concept of a "wait" response is foreign to me. Could you > elaborate? If for example the request is pending. E.g. Because the KCA is waiting for a response from user identity repository to retrieve user identity attributes that are going into the certificate, then it would be useful if the KCA could say like: "Certificate request is pending, ask again later", or ".... Ask again in xx seconds" or whatever is relevant for this case. > >> Finally I don't understand why you need to limit the protocol to UDP, or >> even why you need to specify the use of UDP in the first place. > > I think that's a perfectly. . . (see above) > > If I don't specify *some* transport mechanism then I haven't specified enough > for someone to build an interoperable implementation. > Many request/response protocols are agnostic about transport, and other defines transport in an independent document to make it easy to define how to add/use other transport protocols over time. For example RFC 5272 (CMC) and RFC 5273 (CMC Transport protocols) /Stefan >> /Stefan > > As Doug noted, this protocol is actually fairly old. It was originally > implemented and documented with Kerberos 4, for instance. > >> On 10-05-14 3:32 AM, "Henry B. Hotz" wrote: >> >>> I have just submitted the KX509 draft which I discussed in the Kerberos >>> working group in Anaheim. It's available at >>> https://datatracker.ietf.org/doc/draft-hotz-kx509/. >>> >>> The immediate question is where (if anywhere) should work on this draft take >>> place. Since it's function is to translate Kerberos tickets into X.509 >>> certificates, it might equally be handled by the krb-wg, or pkix. Since I >>> understand it's outside the precise charter of both, perhaps saag should >>> step >>> in. >>> >>> What interest is there in handling work on this? > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From hotz@jpl.nasa.gov Sun May 23 22:27:39 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255913A69B9; Sun, 23 May 2010 22:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.02 X-Spam-Level: X-Spam-Status: No, score=-5.02 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbXV+rNHEgqJ; Sun, 23 May 2010 22:27:37 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id E523D3A6D43; Sun, 23 May 2010 22:27:17 -0700 (PDT) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o4O5QpaS020923 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Sun, 23 May 2010 22:26:52 -0700 Received: from dhcp-137-78-127-84.jpl.nasa.gov (128.149.137.113) by ums-smtp.jpl.nasa.gov (128.149.137.72) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 23 May 2010 22:26:51 -0700 MIME-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset="us-ascii" From: "Henry B. Hotz" In-Reply-To: <4BF1A759.1010505@anl.gov> Date: Sun, 23 May 2010 22:26:44 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <6E4FAC73-C435-47AE-8B60-680123ACBADF@jpl.nasa.gov> References: <4BED6FA8.8080502@anl.gov> <29260_1273881338_o4ENtbpG009604_0B3AD433-3752-44DC-9505-B8B00176722E@jpl.nasa.gov> <8E33C37C9F04CDF5DED82040@atlantis.pc.cs.cmu.edu> <17FD76C1ECD0AB49817637E21809ABF9082FEDA5CB@IMCMBX2.MITRE.ORG> <00B6FAF1-5CA3-4201-89D2-ECE5F6F57B4E@jpl.nasa.gov> <4BF1A759.1010505@anl.gov> To: "Douglas E. Engert" X-Mailer: Apple Mail (2.1078) X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "Miller, Timothy J." , "saag@ietf.org" , "pkix@ietf.org" , "ietf-krb-wg@lists.anl.gov" , 'Sam Hartman' Subject: Re: [saag] [Ietf-krb-wg] [pkix] Draft KX509 Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 05:27:39 -0000 To keep the record straight, I'm not the one who caught the problem = (though I feel like I should have). Jeffrey Altman told me about it. I = don't know if anyone else told him about it. On May 17, 2010, at 1:30 PM, Douglas E. Engert wrote: > Henry B. Hotz wrote: >> I'm pretty sure I don't levy any requirements in this area. I also = don't believe I should, though I could easily be convinced to put in a = "SHOULD NOT" statement. >>=20 >> I do try to say the right things in the Security Considerations = Section. Please review that and make any suggestions you think = appropriate. I agree there's a lot of opportunity for problems (even if = you don't allow authentication loops). >>=20 >> Also note, from other email, that I will be adding something to deal = with the possibility of someone stealing just a public key and using = this service to get a "duplicate" certificate. >>=20 >=20 > Good catch. This is an issue with the current protocol, that the = client only send the > pub key, without demonstrating that it holds the private key. >=20 > In the Considerations, maybe it should be sending a PKCS#10 request - = RFC2986. The request is > would not be saved, but if its still sent unencrtypted, as the key is = in the current > protocol, it could be replayed. So it needs to be sent encrypted or = used in some way > to prove to the KCA that the request is current. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From tlr@w3.org Wed May 26 01:51:57 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E52C3A68CC for ; Wed, 26 May 2010 01:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c4cuJIEC1Vg for ; Wed, 26 May 2010 01:51:56 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id E64903A67AF for ; Wed, 26 May 2010 01:51:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=iCoaster.does-not-exist.org) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OHCL4-0006ii-7M; Wed, 26 May 2010 04:51:46 -0400 Received: from localhost ([127.0.0.1]) by iCoaster.does-not-exist.org with esmtp (Exim 4.71) (envelope-from ) id L30RAA-000LF3-LY; Wed, 26 May 2010 10:51:46 +0200 From: Thomas Roessler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 10:51:44 +0200 Message-Id: <68694D80-7C7A-4FCF-B1C2-591BB6B9096A@w3.org> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: Frederick Hirsch Subject: [saag] W3C Last Call: XML Security Specifications X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 08:51:57 -0000 The W3C XML Security Working Group has three specifications in Last = Call: XML Encryption Syntax and Processing Version 1.1 http://www.w3.org/TR/2010/WD-xmlenc-core1-20100513/ XML Signature Syntax and Processing Version 1.1 http://www.w3.org/TR/2010/WD-xmldsig-core1-20100513/ XML Security Generic Hybrid Ciphers http://www.w3.org/TR/2010/WD-xmlsec-generic-hybrid-20100513/ The first two are incremental revisions of the existing XML Signature = and Encryption Specifications; the Generic Hybrid Ciphers specification = is new. =20 We had previously last called Signature 1.1; the new last call is due to = a proposed fix for known issues around RetrievalMethod that the Working = Group realized it could make without violating its constraints. The Last Call period ends on 10 June. If you have any questions, do not = hesitate to contact Frederick Hirsch (WG chair, CCed on this message) or = myself. Regards, -- Thomas Roessler, W3C (@roessler) From turners@ieca.com Wed May 26 06:19:48 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350063A692B for ; Wed, 26 May 2010 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUF2wGrnl6Dn for ; Wed, 26 May 2010 06:19:47 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 42E9B3A6958 for ; Wed, 26 May 2010 06:19:46 -0700 (PDT) Received: (qmail 51639 invoked from network); 26 May 2010 13:19:34 -0000 Received: from dhcptemp39.cs.columbia.edu (turners@128.59.17.239 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 26 May 2010 06:19:34 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: YXEvTeAVM1khqxrFudEPTcPQqJ851F3NiHePGwQMV0U80l4Dk.fwxkiAEUVLhXDl6heBHIxeo773La2QKpOGtbwiHJIXurEKZwJEvRtKEPTxNnu7XWcmfEkf.d3zG8y5AAveiEMV3Us7nPcw6yyzm_yjyufl7_gEMNh4Ae4rbyMM2fpZtN32S2rY6bQkuUNVxb7wGIJIlEFIA_qhthmZUOeo.uA3h5FeZ5vQLkl4qH93T7AluuhwkNmHHtKb7GWMb58mbnKqcA4sulJtqC7cgZDUdRrvWaBneQ3d6IVQqeubQ8mc4AGvB34qsttcsQ1KZj.YwJPUjxPPN0L5K0zt_Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BFD1FE5.10207@ieca.com> Date: Wed, 26 May 2010 09:19:33 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] The IETF Security Area Wiki and our new AD blogs X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 13:19:48 -0000 While at the IESG retreat, Tim and I decided to update the Security Area wiki, which if you didn't know is located at: http://trac.tools.ietf.org/area/sec/trac/wiki Tim and I also decided to add a blog for each of us, which is going to be eerily similar to monthly AD notes: http://trac.tools.ietf.org/area/sec/trac/wiki/TimsBlog http://trac.tools.ietf.org/area/sec/trac/wiki/SeansBlog I'm hoping that we'll both update on it on a regular basis. spt