http://blog.gmane.org/gmane.ietf.krb-wg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.krb-wg/8774 <pre>This should be discarded, and a response sent. try 2. </pre> Douglas E. Engert 2013-03-25T20:01:06 http://permalink.gmane.org/gmane.ietf.krb-wg/8773 <pre>This should be discarded, and a response sent. </pre> Douglas E. Engert 2013-03-25T19:57:32 http://permalink.gmane.org/gmane.ietf.krb-wg/8770 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberos Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Author(s) : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-04.txt Pages : 8 Date : 2013-02-25 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> internet-drafts< at >ietf.org 2013-02-25T23:45:01 http://permalink.gmane.org/gmane.ietf.krb-wg/8740 <pre> Excuse me? Work that may never happen? http://tools.ietf.org/html/draft-chu-ldap-kdc-schema-00 This has been waiting around for 3 years waiting for the Model document to be finalized. Naturally the schema can't be finalized before the Model. </pre> Howard Chu 2013-01-06T12:07:08 http://permalink.gmane.org/gmane.ietf.krb-wg/8737 <pre>----- Original Message ----- From: "Jeffrey Hutzelman" &lt;jhutz&lt; at &gt;cmu.edu&gt; To: "Simon Josefsson" &lt;simon&lt; at &gt;josefsson.org&gt; Cc: &lt;kitten&lt; at &gt;ietf.org&gt;; &lt;ietf-krb-wg&lt; at &gt;lists.anl.gov&gt;; &lt;jhutz&lt; at &gt;cmu.edu&gt; Sent: Friday, January 04, 2013 7:04 PM kitten WG. Kerberos WG items. in "This charter combines the work of the Kerberos WG and the kitten WG (under the aegis of the kitten WG). In places, it identifies which WG was previously home for that work. " I think that some text is required, for this and perhaps a further update to the charter, should one occur in the next year or two. Tom Petch based to for additional (draft-ietf-kitten-kerberos-iana-registries) (draft-ietf-krb-wg-iakerb) (draft-ietf-krb-wg-ticket-extensions) getting to the contextualized involved. must be of definite need. to policies to an practice, kept management contexts milestones pkinit-agility, a _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> t.p 2013-01-05T12:20:35 http://permalink.gmane.org/gmane.ietf.krb-wg/8724 <pre> A new Request for Comments is now available in online RFC libraries. RFC 6806 Title: Kerberos Principal Name Canonicalization and Cross-Realm Referrals Author: S. Hartman, Ed., K. Raeburn, L. Zhu Status: Standards Track Stream: IETF Date: November 2012 Mailbox: hartmans-ietf&lt; at &gt;mit.edu, raeburn&lt; at &gt;mit.edu, lzhu&lt; at &gt;microsoft.com Pages: 19 Characters: 47572 Updates: RFC4120 I-D Tag: draft-ietf-krb-wg-kerberos-referrals-15.txt URL: http://www.rfc-editor.org/rfc/rfc6806.txt This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. [STANDARDS-TRACK] This document is a product of the Kerberos WG Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor&lt; at &gt;rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> rfc-editor< at >rfc-editor.org 2012-11-30T23:02:07 http://permalink.gmane.org/gmane.ietf.krb-wg/8718 <pre> Folks, Apologies for this spam. I just wanted to announce the availability of an early version of Kerberos-for-Android. This is the port of Krb5 for the Android platform. The code and examples are available under the usual MIT License at the following github location: https://github.com/cconlon/kerberos-android-ndk https://github.com/cconlon/kerberos-java-gssapi Please feel free to play around, develop further, etc. Please use the krb-dev mailing list to post questions, suggestions and fixes/bugs. http://mailman.mit.edu/mailman/listinfo/krbdev /thomas/ __________________________________________ Thomas Hardjono MIT Kerberos Consortium email: hardjono[at]mit.edu mobile: +1 781-729-9559 __________________________________________ __________________________________________ Thomas Hardjono MIT Kerberos Consortium email:  hardjono[at]mit.edu mobile: +1 781-729-9559 __________________________________________ _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg</pre> Thomas Hardjono 2012-11-19T21:03:40 http://permalink.gmane.org/gmane.ietf.krb-wg/8718 <pre> Folks, Apologies for this spam. I just wanted to announce the availability of an early version of Kerberos-for-Android. This is the port of Krb5 for the Android platform. The code and examples are available under the usual MIT License at the following github location: https://github.com/cconlon/kerberos-android-ndk https://github.com/cconlon/kerberos-java-gssapi Please feel free to play around, develop further, etc. Please use the krb-dev mailing list to post questions, suggestions and fixes/bugs. http://mailman.mit.edu/mailman/listinfo/krbdev /thomas/ __________________________________________ Thomas Hardjono MIT Kerberos Consortium email: hardjono[at]mit.edu mobile: +1 781-729-9559 __________________________________________ __________________________________________ Thomas Hardjono MIT Kerberos Consortium email:  hardjono[at]mit.edu mobile: +1 781-729-9559 __________________________________________ _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg</pre> Thomas Hardjono 2012-11-19T21:03:40 http://permalink.gmane.org/gmane.ietf.krb-wg/8717 <pre>Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team&lt; at &gt;meetecho.com. Cheers, the Meetecho team </pre> Meetecho IETF support 2012-11-09T17:06:38 http://permalink.gmane.org/gmane.ietf.krb-wg/8716 <pre> I never saw an answer to this, and the references in question are still in the normative references section in -07. Additionally, while I originally pointed out that RFC1320 (MD4) had been obsoleted by RFC6150 (MD4 to historic), the latter document does not actually contain a description of the algorithm. Given the context, maybe a reference to the original document is more appropriate. Finally, Tom pointed out that the ASN.1 module in Appendix A does not contain definitions for id-pkinit-kdc nor for the two new TD types. And of course, we have the error code conflict. :-( </pre> Jeffrey Hutzelman 2012-11-08T20:10:41 http://permalink.gmane.org/gmane.ietf.krb-wg/8715 <pre> I was mistaken, we do not rely on the error code luckily. (sorry had time to check the code just now and I was misremembering it). Simo. </pre> Simo Sorce 2012-11-06T23:04:22 http://permalink.gmane.org/gmane.ietf.krb-wg/8714 <pre> Would you care to elaborate on how you use that error code to detect when users need migration? That is somewhat surprising. _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> Tom Yu 2012-11-06T22:49:12 http://permalink.gmane.org/gmane.ietf.krb-wg/8712 <pre> I do not find any reference to that symbol in current Solaris code. </pre> Will Fiveash 2012-11-06T20:31:34 http://permalink.gmane.org/gmane.ietf.krb-wg/8711 <pre> If it is the error I thin it is I think we use that error code in FreeIPA to detect when some users need migration. Simo. </pre> Simo Sorce 2012-11-06T13:43:21 http://permalink.gmane.org/gmane.ietf.krb-wg/8708 <pre> Personally, I don't think it would be a big deal to change this error code despite the released code, since the error itself isn't likely to appear in practice until people start disabling SHA-256. I don't know that my opinion would gain consensus among MIT krb5 developers, but my individual preference would be to reassign the error code in the alg-agility draft. _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> Greg Hudson 2012-11-06T06:04:19 http://permalink.gmane.org/gmane.ietf.krb-wg/8707 <pre>For discussion tomorrow: While I was going through my database of Kerberos number assignments in preparation for handing off numbers to IANA, I found that there is a conflict for error code 82. draft-ietf-krb-wg-pkinit-alg-agility-06 has KDC_ERR_NO_ACCEPTABLE_KDF=82, while the published RFC 6111 has KRB_AP_ERR_PRINCIPAL_UNKNOWN=82. I'm not sure how this happened. I tried to find e-mail relevant to this assignment but could not. (I haven't done a really extensive search though.) Unfortunately, I also see error_code KRB5KDC_ERR_NO_ACCEPTABLE_KDF, "No acceptable KDF offered" in the MIT krb5 code, which we seem to have some released code referencing. RFC 6111 seems to have priority, though: 2007-03-03 draft-ietf-krb-wg-naming-03 vs 2007-07-09 draft-ietf-krb-wg-pkinit-alg-agility-03 were the earliest versions of each that I could find. What should we do about this? Has anyone implemented anything that uses KRB_AP_ERR_PRINCIPAL_UNKNOWN=82? Sam has suggested that we overload the error code, because there shouldn't be a situation where an unknown well-known principal name is used in conjunction with PKINIT algorithm agility. I think it's still possible, but unlikely. _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> Tom Yu 2012-11-06T00:37:30 http://permalink.gmane.org/gmane.ietf.krb-wg/8706 <pre> No, Tom's point here is that the message type numbers are in fact in exactly the same situation as the protocol version -- in any place where such a number appears, there is only one value that can possibly appear there; any other value is a protocol error, not an opportunity for extension. In particular, message types are not used to distinguish between messages -- they cannot be, since they are contained within each PDU and such distinction must be done before a PDU can be parsed. IANA registries are not intended as "a centralised database of anything [...] you need to know in order to understand or deal with the Internet". They are intended to serve as a mechanism for the management of namespace, to insure that the same name (number) is not reused for more than one purpose. Where there is nothing to manage, there is no need for a registry. </pre> Jeffrey Hutzelman 2012-10-28T04:47:01 http://permalink.gmane.org/gmane.ietf.krb-wg/8705 <pre>----- Original Message ----- From: "Tom Yu" &lt;tlyu&lt; at &gt;MIT.EDU&gt; To: "t.p." &lt;daedulus&lt; at &gt;btconnect.com&gt; Cc: &lt;ietf-krb-wg&lt; at &gt;lists.anl.gov&gt; Sent: Friday, October 26, 2012 7:26 PM omission Um; that logic seems to say that anything that is subject to Standards Action need not be in the IANA registry, which seems to me to be quite wrong. It would, however, enable us to eliminate much of the current web site. The IANA registry is a major source of information, a centralised database of anything, in the shape of a name or a number, that you need to know in order to understand or deal with the Internet. Thus SNMP puts Security Models and Message Models there, a new one of which would take a new Working Group and years of work to produce. I am sure that there are many more such cases in our core protocols. Having a central source, with references, makes the information usable to everyone. So, I think that Kerberos Message Types would make a most useful registry. Tom Petch _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> t.p 2012-10-27T11:07:47 http://permalink.gmane.org/gmane.ietf.krb-wg/8704 <pre> Transited Encoding types should probably have a registry for the sake of completeness, even though there are unlikely to ever be any more, and it's best to leave them for standards action. The protocol version number is effectively never going to change, for various reasons. Message types are probably not suitable for registration. The sort of change that would result in a new message type number would be a significant change to the protocol, well beyond what reasonable people might agree is a new protocol parameter value. Message types are identical to the ASN.1 application tag numbers of protocol messages that contain them. In any given type of protocol message, the msg-type value will never change. New message type numbers will only come into existence with new protocol messages, and thus be subject to standards action. _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> Tom Yu 2012-10-26T18:26:34 http://permalink.gmane.org/gmane.ietf.krb-wg/8703 <pre>I did a concordance on this I-D, the IANA Kerberos entries and RFC4120 which yields, crudely, ========================================== ** RFC4120 I-D 7.5. Protocol Constants and Associated Values 106 7.5.1. Key Usage Numbers 106 s4.4 7.5.2. PreAuthentication Data Types 108 s4.6 already in IANA 7.5.3. Address Types 109 s4.1 7.5.4. Authorization Data Types 109 s4.2 7.5.5. Transited Encoding Types 109 {?? ONLY ONE VALUE} 7.5.6. Protocol Version Number 109 {not worth registering} 7.5.7. Kerberos Message Types 110 {?? why not} 7.5.8. Name Types 110 s4.5 7.5.9. Error Codes 110 s4.3 5.5.1 AP-REQ s5.1 5.4.1 KDC-REQ s5.2 5.3 Ticket Flags s5.3 ** IANA website 23Oct2012 Checksum Type Numbers RFC 3961 Standards Action or Expert Review (Ken Raeburn) Encryption Type Numbers RFC 3961 Standards Action or Expert Review (Ken Raeburn) FAST Armor Types RFC 6113 Standards Action FAST Options RFC 6113 Standards Action Kerberos Message Transport Types draft-sakane-dhc-dhcpv6-kdc-option-18 IETF Review Kerberos TCP Extensions RFC 5021 IESG Approval or Standards Action Pre-authentication and Typed Data RFC 6113 Expert Review (expert may find that IETF Review is required) (Experts: Sam Hartman - primary, Larry Zhu - secondary) Well-Known Kerberos Principal Names draft-ietf-krb-wg-naming-07 Specification Required Well-Known Kerberos Realm Names draft-ietf-krb-wg-naming-07 Specification Required ============================================ from which I think that this I-D should contain 7.5.1. Key Usage Numbers 106 s4.4 7.5.3. Address Types 109 s4.1 7.5.4. Authorization Data Types 109 s4.2 7.5.8. Name Types 110 s4.5 7.5.9. Error Codes 110 s4.3 5.5.1 AP-REQ s5.1 5.4.1 KDC-REQ s5.2 5.3 Ticket Flags s5.3 (not necessarily in that order) but should not contain 7.5.2. PreAuthentication Data Types 108 s4.6 as it is already in IANA - but a line saying that would seem appropriate. As for Transited Encoding Types Protocol Version Number they do not seem worthy of a registry but I am puzzled by the omission from the I-D of Kerberos Message Types which looks like an incipient registry to me. Tom Petch ----- Original Message ----- From: "t.p." &lt;daedulus&lt; at &gt;btconnect.com&gt; To: &lt;ietf-krb-wg&lt; at &gt;lists.anl.gov&gt;; "Tom Yu" &lt;tlyu&lt; at &gt;MIT.EDU&gt; Sent: Wednesday, October 24, 2012 10:39 AM krb-wg at identified IANA draft-ietf-kitten-kerberos-iana-registries-00.txt https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registr ies htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-00 _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> t.p 2012-10-26T16:24:07 http://permalink.gmane.org/gmane.ietf.krb-wg/8702 <pre>p.s. Since this is in the Charter for krb-wg, I assume that the right place for discussion, unless and until the WGs are merger, is the krb-wg list and not the kitten one. I am subscribed to the former but not, at present, to the latter. Tom Petch ----- Original Message ----- From: "t.p." &lt;daedulus&lt; at &gt;btconnect.com&gt; To: &lt;ietf-krb-wg&lt; at &gt;lists.anl.gov&gt;; "Tom Yu" &lt;tlyu&lt; at &gt;MIT.EDU&gt; Sent: Tuesday, October 23, 2012 2:51 PM document, Considerations, of that by initial IANA over https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registr http://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-00 _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> t.p 2012-10-24T09:39:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.krb-wg