Sam Hartman | 1 Nov 23:54 2006
Picon

Re: AD review comments for the GSS-API domain name specs

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.
Nicolas Williams | 2 Nov 00:11 2006
Picon

Re: AD review comments for the GSS-API domain name specs

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

Jeffrey Hutzelman | 4 Nov 06:12 2006
Picon

Rechartering

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)

Simon Josefsson | 6 Nov 13:43 2006

Re: Rechartering

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

Jeffrey Altman | 6 Nov 16:50 2006

Re: FW: I-D ACTION:draft-zhu-ws-kerb-00.txt

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)

Douglas E. Engert | 6 Nov 17:46 2006

Re: Rechartering

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

Nicolas Williams | 7 Nov 07:05 2006
Picon

Re: AD review comments for the GSS-API domain name specs

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)

Clifford Neuman | 7 Nov 07:20 2006
Picon

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:

   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)

Liqiang(Larry) Zhu | 7 Nov 10:59 2006
Picon

RE: Kerberos Extensions

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)

Jeffrey Altman | 7 Nov 19:43 2006

Re: AD review comments for the GSS-API domain name specs

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)


Gmane