I haven't seen any discussion of my comments. If a new draft addressing these issues were reviewed and submitted early next week, then these could be approved on the next IESG telechat.
On Wed, Nov 01, 2006 at 05:54:58PM -0500, Sam Hartman wrote: > I haven't seen any discussion of my comments. Sorry, replies will be sent soon. > If a new draft addressing these issues were reviewed and submitted > early next week, then these could be approved on the next IESG > telechat. > > > _______________________________________________ > Kitten mailing list > Kitten <at> lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten
At the last IETF meeting, we had a discussion about updating our charter. Based on that discussion, current work, and my impression of where things are going, I've put together an initial proposal, which I've included below. This is in no way set in stone -- it's just a starting point for some discussion, which I hope to have in San Diego. Comments are welcome, both here on the mailing list and during the meeting. It should be noted that we don't actually get to define our own charter. Working group charters are set by the IESG. However, it is likely that the IESG will approve a charter substantially similar to what we propose; thus, this discussion is fairly important. -- Jeff Kerberos over the years has been ported to virtually every operating system. There are at least two open source versions, with numerous commercial versions based on these and other proprietary implementations. Kerberos evolution has continued in recent years, with the development of a new crypto framework, publication of a new version of the Kerberos specification, support for initial authentication using public keys, and numerous extensions developed in and out of the IETF. However, wider deployment and advances in technology bring with them both new challenges and new opportunities, particularly with regard to making initial authentication of users to the Kerberos system both convenient and secure. In addition, several key feature remain undefined. The Kerberos Working Group will advance the state of the core Kerberos specification, produce specifications for missing functionality, and develop extensions to address new needs and technologies related to(Continue reading)
Jeffrey Hutzelman <jhutz <at> cmu.edu> writes: > At the last IETF meeting, we had a discussion about updating our charter. > Based on that discussion, current work, and my impression of where things > are going, I've put together an initial proposal, which I've included > below. This is in no way set in stone -- it's just a starting point for > some discussion, which I hope to have in San Diego. Comments are welcome, > both here on the mailing list and during the meeting. As per earlier discussions of my Kerberos V5 over TLS work, a suggestion for the charter: * Advance a specification to protect Kerberos using TLS, based on draft-josefsson-kerberos5-starttls-02.txt. The latest Shishi release was recently updated to implement that version of the draft. Review and comments on the draft itself are appreciated: http://josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls.txt /Simon
I believe there is a significant need for a Web Proxy protocol for obtaining Kerberos tickets. The question that I have is whether or not this protocol would solve the deployment problems that have resulted in port 88/udp, 88/tcp being blocked by firewalls in the first place. Many of us with operational experience in the academic sector are used to maintaining open access to our KDCs. However, many in the commercial and government sectors refuse to because they want to limit the attacks against their KDCs. They want to prevent DoS attacks, prevent potentially untrusted clients from sending the KDCs a specially crafted request that might be able to take advantage of perhaps yet unknown vulnerability, and even restrict the ability to probe the KDCs for valid principal names. The protocol you describe provides a proxy service but I do not see how it addresses the issues that have lead to the KDC requiring a proxy in the first place. Why would an administrator be willing to deploy this proxy protocol when they are not willing to allow external access to the KDC? One of the things that I have seen a need for is a HTTP proxy for Kerberos requests. Do you foresee your proposed protocol being used within a HTTP exchange? It would be helpful to me if you could explain when you expect this protocol to be used. Jeffrey Altman Liqiang(Larry) Zhu wrote:(Continue reading)
I believe there is a need to allow the user to have better control and auditing over the delegation of credentials. The current method of forwarding a full TGT can lead to compromises in a diverse cross realm environment. The failure to have this control limits the usefulness of Kerberos in such environments, and discourages the deployment of Kerberos across organizations. It is not clear the best way to go about this. It could include policies in the KDC to limit the max times a TGT could be forwarded. For auditing it could include adding a reference to which host was involved in the delegation. One interesting approach might even be to having a user in run their own realm! So all requests for forwarded tickets are routed back to the user's personal realm where the KDC can notify the user. There are many issues with this, and it is not well thought out, but it gives the end user (or his KDC) control over the delegation process. -- -- Douglas E. Engert <DEEngert <at> anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
On Fri, Oct 20, 2006 at 08:39:14AM -0400, Sam Hartman wrote: > These AD comments need to be fixed. However they are rather minor so > I'm going to last call the comments in parallel. > > draft-ietf-kitten-gssapi-domain-based-names : > > * There is no IANA considerations section yet actions (allocation of > an oid) are requested of IANA Actually, the IANA may have no role to play and my note in the I-D may have been incorrect. I cannot find an IANA registry for the 1.3.6.1.5.6 sub-tree. RFC2743 establishes an IANA registry of _service names_ but not of name types. So I wouldn't quite know how to write instructions to IANA about this short of actually writing instructions for establishing the missing registry. We have a separate I-D on IANA registries for the GSS-API, but I don't want this I-D to block on that one. And since the existing name type OIDs have been allocated by Standards Track RFCs I believe the right thing to do is to remove my note about the allocation of this OID. > * Do we really want to recommend _foo._tcp.example.tld instead of just > example.tld? I don't think I care one way or the other. > draft-ietf-kitten-krb5-gssapi-domain-based-names > > What does the following text mean:(Continue reading)
Unfortunately I am unable to attend this IETF and I will be on a plane during the time of the Kerberos working group meeting. I agree with the general feeling that it is time for us to move toward some progress on Kerberos Extensions. In addition to discussion the extensions document itself, I think that we need to come up with a planned course of action regarding the extensions and how we expect them to be viewed/implemented. In particular, is it expect that the extensions document will obsolete RFC4120, or will be be an alternative implementation. Looking at rfc1510ter-03 I can not really tell the answer to the question above. The document is written with an ambiguous intent. The intro states: This document describes a framework which enables backwards-compatible extensions to the Kerberos protocol. Which would indicate to me that this describes the framework for supporting backwards compatible extensions, but it incorporates much of RFC1510. First, shouldn't it instead be providing the compatibility with 4120. And then, wouldn't it be better to focus on the extensions, as it claims is its intent in the introduction. Personally, I would like to see this as a much shorter document with a much cleaner separation between what is extensions, and what is the basic protocol. Thus, this document should extend or update 4120 (I'm(Continue reading)
I support splitting the document into one that is just about extensions. I also found the document unmanageable. The extension document has been the focus of the group for quite some time, it does not help us doing useful and relevant things, if no implementers in the working group has expressed interests implementing the protocol. -----Original Message----- From: owner-ietf-krb-wg <at> mailhost.anl.gov [mailto:owner-ietf-krb-wg <at> mailhost.anl.gov] On Behalf Of Clifford Neuman Sent: Monday, November 06, 2006 10:21 PM To: ietf-krb-wg <at> anl.gov Subject: Kerberos Extensions Unfortunately I am unable to attend this IETF and I will be on a plane during the time of the Kerberos working group meeting. I agree with the general feeling that it is time for us to move toward some progress on Kerberos Extensions. In addition to discussion the extensions document itself, I think that we need to come up with a planned course of action regarding the extensions and how we expect them to be viewed/implemented. In particular, is it expect that the extensions document will obsolete RFC4120, or will be be an alternative implementation. Looking at rfc1510ter-03 I can not really tell the answer to the question above. The document is written with an ambiguous intent. The intro states:(Continue reading)
Nicolas Williams wrote: > On Fri, Oct 20, 2006 at 08:39:14AM -0400, Sam Hartman wrote: >> These AD comments need to be fixed. However they are rather minor so >> I'm going to last call the comments in parallel. >> >> draft-ietf-kitten-gssapi-domain-based-names : >> >> * There is no IANA considerations section yet actions (allocation of >> an oid) are requested of IANA > > Actually, the IANA may have no role to play and my note in the I-D may > have been incorrect. > > I cannot find an IANA registry for the 1.3.6.1.5.6 sub-tree. RFC2743 > establishes an IANA registry of _service names_ but not of name types. > > So I wouldn't quite know how to write instructions to IANA about this > short of actually writing instructions for establishing the missing > registry. We have a separate I-D on IANA registries for the GSS-API, > but I don't want this I-D to block on that one. And since the existing > name type OIDs have been allocated by Standards Track RFCs I believe the > right thing to do is to remove my note about the allocation of this OID. I believe the OID should be allocated by standards action. The IANA allocation reference should be removed. >> * Do we really want to recommend _foo._tcp.example.tld instead of just >> example.tld? > > I don't think I care one way or the other.(Continue reading)
RSS Feed2 | |
|---|---|
1 | |
2 | |
1 | |
9 | |
13 | |
23 | |
21 | |
17 | |
94 | |
8 | |
28 | |
70 | |
149 | |
17 | |
23 | |
69 | |
56 | |
38 | |
84 | |
183 | |
93 | |
165 | |
49 | |
55 | |
32 | |
56 | |
49 | |
43 | |
170 | |
46 | |
83 | |
35 | |
12 | |
99 | |
13 | |
52 | |
16 | |
5 | |
21 | |
36 | |
122 | |
81 | |
44 | |
97 | |
102 | |
56 | |
64 | |
223 | |
24 | |
45 | |
60 | |
63 | |
18 | |
54 | |
140 | |
87 | |
4 | |
2 | |
21 | |
17 | |
32 | |
50 | |
62 | |
54 | |
41 | |
6 | |
52 | |
57 | |
37 | |
42 | |
35 | |
66 | |
13 | |
10 | |
6 | |
19 | |
24 | |
73 | |
46 | |
29 | |
47 | |
26 | |
36 | |
40 | |
42 | |
78 | |
28 | |
109 | |
90 | |
138 | |
84 | |
162 | |
59 | |
58 | |
42 | |
60 | |
175 | |
78 | |
42 | |
57 | |
114 | |
217 | |
52 | |
229 | |
70 | |
76 | |
111 | |
105 | |
95 | |
27 | |
114 | |
69 | |
254 | |
192 | |
113 | |
118 | |
62 | |
59 | |
91 | |
80 | |
47 | |
33 | |
187 | |
170 | |
101 | |
25 | |
21 | |
15 | |
29 | |
13 | |
49 |
