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://comments.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://comments.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://comments.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</pre> internet-drafts< at >ietf.org 2013-02-25T23:45:01 http://comments.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 returni</pre> rfc-editor< at >rfc-editor.org 2012-11-30T23:02:07 http://comments.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</pre> Thomas Hardjono 2012-11-19T21:03:40 http://comments.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</pre> Thomas Hardjono 2012-11-19T21:03:40 http://comments.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://comments.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 th</pre> Tom Yu 2012-11-06T00:37:30 http://comments.gmane.org/gmane.ietf.krb-wg/8699 <pre>Hi. Josh, Shawn and I are delighted to welcome Simon as the kitten WG secretary. He'll be helping us review documents, track them through the publication process, helping with meeting logistics, that sort of thing. Simon has been active in this community for a long time and has provided a lot of review to the SASL and GSS-API community. Simon was instrumental in pulling together GS2 and SCRAM, and has helped out our more recent SASL mechanisms as well. He's also been helpful with GSS-API naming extensions. I'm really excited about the group of people we have coming into the Atlanta meeting. _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> Sam Hartman 2012-10-22T23:44:28 http://comments.gmane.org/gmane.ietf.krb-wg/8694 <pre>From: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org Subject: I-D Action: draft-ietf-kitten-kerberos-iana-registries-00.txt Message-ID: &lt;20121015235222.6701.67782.idtracker&lt; at &gt;ietfa.amsl.com&gt; Date: Mon, 15 Oct 2012 16:52:22 -0700 Cc: kitten&lt; at &gt;ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Move Kerberos protocol parameter registries to IANA Author(s) : Tom Yu Filename : draft-ietf-kitten-kerberos-iana-registries-00.txt Pages : 6 Date : 2012-10-15 Abstract: The Keberos 5 network authentication protocol has several numeric protocol parameters. Most of these parameters are not currently under IANA maintenance. This document requests that IANA take over the maintenance of the remainder of these Kerberos parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf</pre> Tom Yu 2012-10-16T00:22:17 http://comments.gmane.org/gmane.ietf.krb-wg/8688 <pre>The IESG has approved the following document: - 'Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals' (draft-ietf-krb-wg-kerberos-referrals-15.txt) as Proposed Standard This document is the product of the Kerberos Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-krb-wg-kerberos-referrals/ Technical Summary The 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 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 verifyi</pre> The IESG 2012-10-01T18:52:00 http://comments.gmane.org/gmane.ietf.krb-wg/8685 <pre> I wanted to call out that in response to a genart review and discuss from Russ, wwe're making a minor change. Referrals currently says that the pa-enc-pa-req for FAST negotiation SHOULD have an empty value. We're changing that to MUST be empty on send; MUST be ignored on receive. _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg&lt; at &gt;lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg </pre> Sam Hartman 2012-09-26T12:05:47 http://comments.gmane.org/gmane.ietf.krb-wg/8682 <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 Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals Author(s) : Painless Security Kenneth Raeburn Larry Zhu Filename : draft-ietf-krb-wg-kerberos-referrals-15.txt Pages : 21 Date : 2012-09-23 Abstract: The 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 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. Th</pre> internet-drafts< at >ietf.org 2012-09-23T19:45:11 http://comments.gmane.org/gmane.ietf.krb-wg/8681 <pre> As Stephen mentioned, we're looking for people who would be interested in helping to contribute to the WG. We'd be interested in finding an energetic third chair. For that position, you'd need to have some existing IETF experience--contributing to WGs, possibly writing documents--and a willingness to learn and particularly to learn IETF process. however, now is a great time to step forward and say that you're interested in what's going on in kitten or Kerberos and would like to help out. I think this set of working groups is really exciting because of the bredth of the application security space we cover. We have some folks who are really looking for light-weight no-crypto mechanisms like sasl-openid. On the other side we have the Kerberos and multi-mech GSS-API platform folks who are looking for mutual authenticationd and phishing defense and who aren't as concerned about mechanism complexity because they have shared infrastructure across a platform. I think we can all learn from each other and do gr</pre> Sam Hartman 2012-09-23T19:15:31 http://comments.gmane.org/gmane.ietf.krb-wg/8669 <pre> Hi all, I've done my review of this. Please treat these along with any other IETF LC comments. I've asked for IETF LC to be started. Thanks, S, - p10, last para, maybe s/should/ought/ if you don't want that as a 2119 should? Even without that being a SHOULD, it seems odd to recommend that the client know about realms, to the extent that it can differentiate between them, in a spec whose purpose is to get rid of per-realm configuration from clients. Is there in fact a missing 2119-level SHOULD here that also says how to do this with no client config? Or, are you really assuming that clients won't make any checks, in which case wouldn't it be better to confess the truth? - If a KDC receives an AS-REQ with no PA-REQ-ENC-PA-REP or canonicalize KDC option then I assume that KDC MUST behave according to 4120. Is that stated explicitly somewhere? Does there need to be any similar statement about TGS-REQs or TGTs (since the new padata type is a MAY for TGS-REQs)? nits: - more examples would help here, the on</pre> Stephen Farrell 2012-09-13T00:46:42 http://comments.gmane.org/gmane.ietf.krb-wg/8667 <pre> The IESG has received a request from the Kerberos WG (krb-wg) to consider the following document: - 'Camellia Encryption for Kerberos 5' &lt;draft-ietf-krb-wg-camellia-cts-01.txt&gt; as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2012-09-26. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961. The new types use the Camellia block cipher in CBC-mode with ciphertext stealing and the CMAC algorithm for integrity protection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-krb-wg-camellia-cts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-krb-wg-ca</pre> The IESG 2012-09-12T18:15:22 http://comments.gmane.org/gmane.ietf.krb-wg/8660 <pre> Hi all, My AD review of this is below. Thanks for a nice and nicely-short document! The only thing that I'd like before I start IETF LC is an answer on the IPR question at the top (or a discussion about that if need be). All the other stuff can be considered along with other IETF LC comments. Cheers, S. - The IPR declaration (#1304) is noted in the write-up but not specifically associated with this draft, so it wouldn't show up so easily for reviewers but I can call that out specifically in the IETF LC message, but there is another issue: that declaration refers for example to things that are required for compliance with a standard. However, the wg are proposing this as informational, so it may be less clear to IETF LC reviewers if the terms in the declaration apply or not. Did the WG consider that difference when deciding to go for informational? (Note: In some cases, when we've told folks who made declarations about this ambiguity they've been happy to modify the language. I don't know if that applie</pre> Stephen Farrell 2012-09-07T13:00:44 http://comments.gmane.org/gmane.ietf.krb-wg/8638 <pre>In recent days it has come to my attention that various client libraries and KDCs imposes a variety of constraints on the use of renewable tickets which restrict their usability. Especially in cross-vendor deployments. Heimdal 1.5.x and earlier clients for example cannot request a renewable service ticket. Only initial TGTs can be renewable. Windows Server 2003 will issue renewable and forwardable TGTs and service tickets but will not renew anything other than an initial TGT. MIT's client libraries only permit renewals of TGTs. Attempts to renew service tickets result in a mismatched server name and ticket being sent to the KDC. It would be useful as guidance to implementers for this working group to come to a consensus on: * which ticket types should be renewable * which ticket types should be renewed by the KDC * the interactions of the renewable flag and other ticket flags * the use of RENEWABLE_OK by clients It is my hope that such guidance when implemented (and preferably backported by v</pre> Jeffrey Altman 2012-08-21T17:32:57 http://comments.gmane.org/gmane.ietf.krb-wg/8637 <pre>RFC 4120 Section 3.3.3 &lt;https://tools.ietf.org/html/rfc4120#section-3.3.3&gt; "Generation of the KRB_TGS_REP Message" specifies that the "expiration time" (aka "endtime") as follows: If the request specifies an endtime, then the endtime of the new ticket is set to the minimum of (a) that request, (b) the endtime from the TGT, and (c) the starttime of the TGT plus the minimum of the maximum life for the application server and the maximum life for the local realm (the maximum life for the requesting principal was already applied when the TGT was issued). If the new ticket is to be a renewal, then the endtime above is replaced by the minimum of (a) the value of the renew_till field of the ticket and (b) the starttime for the new ticket plus the life (endtime-starttime) of the old ticket. In other words, the endtime of the issued service ticket MUST be constrained to a lifetime that is no longer than that of the initial TGT. In practice, I find this constraint to be overly restrict</pre> Jeffrey Altman 2012-08-21T17:21:18 http://comments.gmane.org/gmane.ietf.krb-wg/8635 <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 : An information model for Kerberos version 5 Author(s) : Leif Johansson Filename : draft-ietf-krb-wg-kdc-model-14.txt Pages : 17 Date : 2012-07-31 Abstract: This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-kdc-model-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-kdc-model-14 Internet-Drafts are also available by </pre> internet-drafts< at >ietf.org 2012-07-31T22:15:18 http://comments.gmane.org/gmane.ietf.krb-wg/8625 <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 Options for DHCPv6 Author(s) : Shoichi Sakane Masahiro Ishiyama Filename : draft-sakane-dhc-dhcpv6-kdc-option-17.txt Pages : 19 Date : 2012-07-09 Abstract: This document defines new four options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), options which carry configuration information for Kerberos. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sakane-dhc-dhcpv6-kdc-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-sakane-dhc-dhcpv6-kdc-option-17 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-sakane-dhc-dhcpv6-kdc-option-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ __</pre> internet-drafts< at >ietf.org 2012-07-10T05:26:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.krb-wg