Subject: Re: [Ietf-krb-wg] Draft agenda for IETF 71

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 03 Mar 2008 13:48:57 -0500

--On Thursday, February 28, 2008 04:35:39 PM -0500 Sam Hartman 
<[email-masked]> wrote:

>>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>
>     Jeffrey> --On Thursday, February 28, 2008 04:10:36 PM -0500 Sam
>     Jeffrey> Hartman
>     Jeffrey> <[email-masked]> wrote:
>
>     >> I have a preference for starttls as informational or
>     >> experimental but am not currently sure how strong that
>     >> preference is.
>
>     Jeffrey> Why?  _______________________________________________
>
>
> Ah.  As I think about this question I realize I have a strong
> objection to decoupling the status of starttls from the mandatory to
> implement for 5.3.
>
> I think that if starttls is not going to be the 5.3 mandatory to
> implement then:
>
> * It should block on that mandatory to implement
>
> * It should not be standards track.
>
> Doing anything else seems like it would confuse things.
>
>
> My preference would be to publish as info/exp now and move to standards
> track if we decide to make it the mandatory to implement.

Given the pace of 5.3, I don't think it's reasonable to block STARTTLS on 
5.3; in fact, that's exactly why we're having this conversation.  I think 
it would be reasonable to do as you suggest, and publish STARTTLS as 
informational now and upgrade it if we make it mandatory.  I also think it 
would be reasonable to publish STARTTLS and preauth/FAST at the same time, 
if preauth is almost done and we don't hold up either document for 5.3.

Note that I don't think publishing STARTTLS as experimental is the right 
thing because as far as I know, no one has an actual experiment in mind.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 04 Mar 2008 13:23:50 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> --On Thursday, February 28, 2008 01:26:29 PM -0500 Jeffrey Hutzelman 
> <[email-masked]> wrote:
>
>> --On Thursday, February 28, 2008 11:17:47 AM +0100 Simon Josefsson
>> <[email-masked]> wrote:
>>
>>> When I approached an AD about publishing this document a long time ago,
>>> it was suggested that I try to move this forward in the KRB-WG.  The
>>> document have benefited from review of the KRB-WG (thanks!), but it has
>>> taken a long time to get a yes/no whether to adopt the document.
>>
>> I believe we agreed to adopt this document as a WG item quite some time
>> ago.  It appears as part of one of our charter items(*), and as a
>> milestone.  It doesn't appear that the tools are treating this draft as a
>> working-group draft, which is an oversight I will correct shortly.

Thanks.

>>> The
>>> protocol is deployed, and I think it would be useful to document this
>>> for the community.
>>
>> I think we all agree on that.  This document has been blocked primarily
>> because we have been waiting to determine its intended status; we cannot
>> send it along to the IESG without knowing this.  In turn, one input to
>> that  determination is whether we want to proceed with a direction for
>> the next  Kerberos specification in which STARTTLS will be
>> mandatory-to-implement.

I don't see why STARTTLS needs to be mandatory to implement.
Implementers who care about it can implement it, others can ignore it.

>> Discussion on the preferred approach for the next Kerberos specification
>> would be welcome, as would direct discussion of the intended status of
>> the  STARTTLS document.
>
> Looking at our charter in more detail, it seems to me that maybe we're 
> including too many dependencies...
>
> The charter includes the following item:
>
>  * Develop extensions which reduce or eliminate exposure of Kerberos
>    clients' long-term keys to attack and enable the use of alternate
>    mechanisms for initial authentication. This task will comprise the
>    following items:
>    - A model and framework for preauthentication mechanisms
>    - A mechanism for providing a protected channel for carrying
>      preauthentication data and/or a reply key between a Kerberos
>      client and KDC, within the KDC_REQ/KDC_REP exchange.
>    - Support for One-Time Passwords
>    - Support for hardware authentication tokens
>    - Support for using TLS to secure communications with Kerberos KDCs.
>
>
> So, it is clear that we have agreed to do both the FAST and TLS work.

I'm with you so far.

> It seems clear that support for at least one of these will be REQUIRED
> in Kerberos 5.3.

I don't understand that conclusion.  What is Kerberos 5.3 in this
context?  My understanding is that it refers to this charter item:

* Prepare and advance a specification for an updated, backward-
  compatible version of the Kerberos version 5 protocol which supports
  non-ASCII principal and realm names, salt strings, and passwords;
  insures that those portions of the protocol which are not encrypted
  are nonetheless authenticated whenever possible; and enables future
  protocol revisions and extensions.

I don't see why finishing that work item, or even deciding how it should
be done, needs to delay STARTTLS further.

The krb5.3 document could eventually decide to depend on STARTTLS, or it
could just as well depend on FAST, or do something else.  I don't see
how any of those choices affect STARTTLS.  I understand that once krb5.3
work proceeds, it may be useful to enhance the STARTTLS protocol to
support something krb5.3-specific, but that seems like something that
can be part of a revised version of STARTTLS.  Or a new Kerberos over
TCP extension that is similar to the current STARTTLS document.

> It becomes clearer to me every day that we can separate the question
> of which one (or both) will be REQUIRED from the question of whether
> we will take the use of FAST or STARTTLS to indicate support for
> Kerberos 5.3, and that we probably should do so.

I think kerberos 5.3 could specify its own mechanism to indicate support
for the extension.

> Otherwise, I want to talk about those issues, with an eye toward being able 
> to begin a WGLC on STARTTLS before the end of March.

That would be swell!

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 05 Mar 2008 16:37:12 -0500

>   protocol revisions and extensions.

Kerberos 5.3 (formally, "Kerberos V Specification 3") is the next revision 
of the Kerberos protocol specification, which will succeed RFC4120.  It 
does indeed correspond to the charter item you quote.

That item essentially requires us to solve the authenticated cleartext 
problem; there is also a work item which focuses on protecting the AS 
exchange, which is the problem that STARTTLS solves.  The assumption we've 
been following is that some solution to protecting the AS exchange will be 
REQUIRED for implementations of Kerberos 5.3.

> be done, needs to delay STARTTLS further.

It doesn't.  However, if support for STARTTLS will be REQUIRED for 
implementations of Kerberos 5.3, then STARTTLS will need to be Standards 
Track.  However, Sam points out that we if we want, we can publish STARTTLS 
as an Information or Experimental RFC now and later change its status to 
Proposed Standard if we want to upgrade it and make it REQUIRED for 
Kerberos 5.3.

So, if we decide to publish STARTTLS now as Informational and upgrade it if 
necessary, we can proceed without deciding whether it will be REQUIRED for 
Kerberos 5.3.  Would you object (or anyone) to doing this?

Similarly, we can proceed without deciding whether STARTTLS will be 
REQUIRED for Kerberos 5.3 if we decide to publish it as a Proposed Standard 
in either case.  Would you (or anyone) object to doing this?

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 5 Mar 2008 23:03:00 +0100

On 5 mar 2008, at 22.37, Jeffrey Hutzelman wrote:

> Kerberos 5.3 (formally, "Kerberos V Specification 3") is the next  
> revision of the Kerberos protocol specification, which will succeed  
> RFC4120.  It does indeed correspond to the charter item you quote.
>
> That item essentially requires us to solve the authenticated  
> cleartext problem; there is also a work item which focuses on  
> protecting the AS exchange, which is the problem that STARTTLS  
> solves.  The assumption we've been following is that some solution  
> to protecting the AS exchange will be REQUIRED for implementations  
> of Kerberos 5.3.

Ok.

> implementations of Kerberos 5.3, then STARTTLS will need to be  
> Standards Track.  However, Sam points out that we if we want, we  
> can publish STARTTLS as an Information or Experimental RFC now and  
> later change its status to Proposed Standard if we want to upgrade  
> it and make it REQUIRED for Kerberos 5.3.
>
> So, if we decide to publish STARTTLS now as Informational and  
> upgrade it if necessary, we can proceed without deciding whether it  
> will be REQUIRED for Kerberos 5.3.  Would you object (or anyone) to  
> doing this?
>
> REQUIRED for Kerberos 5.3 if we decide to publish it as a Proposed  
> Standard in either case.  Would you (or anyone) object to doing this?

I don't understand the rationale behind publishing it as  
informational/experimental.  It seems it could be proposed standard  
from the start.  I would prefer this way forward.  Since  
informational status has been suggested a few times, I'd like to  
understand what the reasons for preferring that approach could be.

/Simon