Subject: [Ietf-krb-wg] WG Last Call: draft-ietf-krb-wg-preauth-framework-12

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 12 Jun 2009 12:24:18 -0400

This note announces the start of a two-week last call within the Kerberos
Working Group on whether to send the following document to the IESG:

Title:           A Generalized Framework for Kerberos Pre-Authentication
Filename:        draft-ietf-krb-wg-preauth-framework-12.txt
Intended Status: Proposed Standard

   Kerberos is a protocol for verifying the identity of principals
   (e.g., a workstation user or a network server) on an open network.

   The Kerberos protocol provides a mechanism called pre-authentication
   for proving the identity of a principal and for better protecting the
   long-term secrets of the principal.

   This document describes a model for Kerberos pre-authentication
   mechanisms.  The model describes what state in the Kerberos request a
   pre-authentication mechanism is likely to change.  It also describes
   how multiple pre-authentication mechanisms used in the same request
   will interact.

   This document also provides common tools needed by multiple pre-
   authentication mechanisms.  One of these tools is a secure channel
   between the client and the KDC with a reply key delivery mechanism;
   this secure channel can be used to protect the authentication
   exchange thus eliminate offline dictionary attacks.  With these
   tools, it is relatively straightforward to chain multiple
   authentication mechanisms, utilize a different key management system,
   or support a new key agreement algorithm.

This last call will expire at 23:59 EDT on Friday, June 26, 2009.

Please review this document and send any comments to the Kerberos Working
Group mailing list, <[email-masked]>, by that date.  The file can be
obtained via

http://www.ietf.org/internet-drafts/draft-draft-ietf-krb-wg-preauth-framework-12.txt

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Jun 2009 12:47:24 -0400

I'm aware of two outstanding comments.
1) An issue raised by Love about  the kdc verified state flag
2) My issue about unknown armor.

I will be sending a third comment today regarding TGS armor.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 12 Jun 2009 12:50:28 -0700

> Intended Status: Proposed Standard

---

> http://www.ietf.org/internet-drafts/draft-draft-ietf-krb-wg-preauth-framework-12.txt

Seems to be a bad link.  Google says:  http://tools.ietf.org/id/draft-ietf-krb-wg-preauth-framework-12.txt
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 12 Jun 2009 16:07:00 -0400

--On Friday, June 12, 2009 12:50:28 PM -0700 "Henry B. Hotz" 
<[email-masked]> wrote:

> Seems to be a bad link.  Google says:
> http://tools.ietf.org/id/draft-ietf-krb-wg-preauth-framework-12.txt

Thanks for noticing this.  The link I posted works, if you take out the 
extra "draft-".

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jun 2009 15:21:56 +0200

> Intended Status: Proposed Standard

My question about intended status of FAST and STARTTLS is still
unanswered:

https://lists.anl.gov/pipermail/ietf-krb-wg/2009-May/007674.html

As far as I understood the discussion at IETF 73 the intention then was
to move forward both as Experimental.  I would prefer to move forward
both as Proposed Standard, but can live with Experimental.  The
arguments that FAST and STARTTLS are exclusive haven't been convincing
to me, thus I think both has merit.

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 15 Jun 2009 16:48:25 -0700

I think I said back then that I supported publishing STARTTLS (as  
experimental, if it helps) as expeditiously as possible.

Perhaps I mis-remember, but I thought the intent was to do both FAST  
and STARTTLS as experimental and promote one or both to standard  
status at a later date.  If that wasn't the intent, let me propose it  
as a compromise.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Jun 2009 18:53:33 -0500

> status at a later date.  If that wasn't the intent, let me propose it  

FAST has much more functionality, such as using host creds to protect
PA-ENC-TIMESTAMP, PA-ENC-TIMESTAMP with channel binding to anon-anon and
anon-not-anon DH PKINIT.  The Start-tls proposal does not.  Ergo I will
support FAST for the Standards-Track.

I don't mind if Start-tls goes on the Standards-Track or not; as long as
you use server certs to authenticate the KDC I think Start-tls is
sufficiently good to be on the Standards-Track, even though it lacks
important features.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Tue, 16 Jun 2009 00:07:50 +0000

It is clear that we need to a solution on the standards tracks. There is no consensus to put starttls on the standards tracks. However FAST has always been on the standards track on the get-go.

The set of features offered by the two documents are sufficiently different that we should consider the two and the status of each independently.

--Larry

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Jun 2009 08:29:47 +0200

Larry Zhu <[email-masked]> writes:

> It is clear that we need to a solution on the standards tracks. There
> is no consensus to put starttls on the standards tracks.

There was consensus to add starttls to the WG charter.  There were no
indication at the time that publication would not use standards track,
since that is the typical status for standards published by WGs.

> However FAST has always been on the standards track on the get-go.

Can you point to a reference?  As far as I can tell, both starttls and
fast have the same amount of support in the WG charter.

> The set of features offered by the two documents are sufficiently
> different that we should consider the two and the status of each
> independently.

I'm fine with that, but as far as I understand the assumption before was
the opposite (hence the efforts to compare the two proposals).

/Simon

> --Larry
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Henry B. Hotz
> Sent: Monday, June 15, 2009 4:48 PM To: Simon Josefsson Cc:
> [email-masked]; Jeffrey Hutzelman Subject: [Ietf-krb-wg] STARTTLS
> (was preauth-framework-12)
>
>> As far as I understood the discussion at IETF 73 the intention then
>> was to move forward both as Experimental.  I would prefer to move
>> forward both as Proposed Standard, but can live with Experimental.
>> The arguments that FAST and STARTTLS are exclusive haven't been
>> convincing to me, thus I think both has merit.
>> /Simon
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Jun 2009 08:34:13 +0200

> support FAST for the Standards-Track.

As far as I can tell, that is supported by
draft-josefsson-krb5starttls-bootstrap.

> sufficiently good to be on the Standards-Track, even though it lacks

The document has explicitly allowed use of server certs since 2004.

What other features are you thinking of?

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Tue, 16 Jun 2009 06:59:38 +0000

>since that is the typical status for standards published by WGs.

This wg also produces informational documents.

>fast have the same amount of support in the WG charter

The most recent one is here:
https://lists.anl.gov/pipermail/ietf-krb-wg/2009-June/007714.html
note that the last call document status is "standards track".

> the opposite (hence the efforts to compare the two proposals).

We ought not to have two solutions for the same thing. Do you think you or anyone else can volunteer to update starttls to match the feature set in fast? If starttls cannot solve critical problems such as auth factor chaining, channel bindings, allowing anonymous channels etc, it should be reasonable to assume that starttls should retire as experimental. Thanks for the push! You can continue to present the case where starttls has its own use cases, therefore to keep it progressing toward the standard tracks go forward.
--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Monday, June 15, 2009 11:30 PM
To: Larry Zhu
Cc: [email-masked]; Jeffrey Hutzelman
Subject: Re: [Ietf-krb-wg] STARTTLS

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Jun 2009 09:16:56 +0200

> note that the last call document status is "standards track".

As far as I can tell, that is a call for consensus and not declaration
of consensus.

> We ought not to have two solutions for the same thing.

I agree.  I don't think FAST and STARTTLS is the same thing.  It seemed
you agree with that in the quoted text above, where you asserted that
the features are different.

> Do you think you or anyone else can volunteer to update starttls to
> match the feature set in fast?

I have posted
http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 to
address some of the feature requests.

However, if you believe we should not have two solutions for the same
thing, it seems pointless to make krb5starttls provide the same features
as FAST?

> If starttls cannot solve critical problems such as auth factor
> chaining, channel bindings, allowing anonymous channels etc, it should
> be reasonable to assume that starttls should retire as
> experimental.

Doesn't FAST solve those issues?  Krb5starttls can be used together with
FAST.  Krb5starttls provides features that FAST doesn't.

You CAN use krb5starttls to implement some if not all of features
provided by FAST, and some are described by
draft-josefsson-krb5starttls-bootstrap-02.  But it isn't clear if that
is a good idea or not.  You appear to be saying that it isn't a good
idea, but also ask that it should be done.

> Thanks for the push! You can continue to present the case where
> starttls has its own use cases, therefore to keep it progressing
> toward the standard tracks go forward.

The case for STARTTLS is described in the document, and includes OpenPGP
authentication against KDCs.  FAST does not support that as far as I can
tell, and that is one of the driving reasons for krb5starttls.

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Tue, 16 Jun 2009 07:36:58 +0000

> As far as I can tell, that is a call for consensus and not declaration

It is not worth quibbling on this though it should be obvious that the intention is to last call a proposed standard document.

> the features are different.

Right, but let's emphasize the difference, not the other way around.

> thing, it seems pointless to make krb5starttls provide the same features

Agreed. Going forward it is more productive for starttls to compliment FAST, not to compete for the overlapped use cases. If there were a window of opportunities to do the later, but that window seems to either have closed already or is closing rapidly.

>FAST.  Krb5starttls provides features that FAST doesn't.

How do we justify the cost of deploy starttls? We need be able to understand the benefits of doing so when we already have fast.

>idea, but also ask that it should be done.

I think it is moot to duplicate the features. This WG needs to build solutions to the deployment problems and we should avoid creating marketing confusions. The situation now is that we have one that is ready so the choice is clear.

>tell, and that is one of the driving reasons for krb5starttls.

It does not seem compelling though. One can use PKINIT and self-signed certificates to achieve the same effect.

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]]
Sent: Tuesday, June 16, 2009 12:17 AM
To: Larry Zhu
Cc: [email-masked]; Jeffrey Hutzelman
Subject: Re: STARTTLS

I have posted

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Jun 2009 09:45:30 +0200

> certificates to achieve the same effect.

How would that work?  The assumption is that the KDC has a list of
trusted OpenPGP keys that maps to Kerberos usernames.  I don't see how a
KDC would be able to authenticate a self-signed certificate against the
OpenPGP web of trust.

/Simon

---

From: Larry Zhu <[email-masked]>
Date: Tue, 16 Jun 2009 07:48:47 +0000

> KDC would be able to authenticate a self-signed certificate against the

I do not quite understand the use case here but then this could be an opportunity for starttls to shine.

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Tuesday, June 16, 2009 12:46 AM
To: Larry Zhu
Cc: [email-masked]; Jeffrey Hutzelman
Subject: Re: [Ietf-krb-wg] STARTTLS

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Jun 2009 09:52:48 -0400

>>>>> "Larry" == Larry Zhu <[email-masked]> writes:

    Larry> It is clear that we need to a solution on the standards
    Larry> tracks. There is no consensus to put starttls on the
    Larry> standards tracks. However FAST has always been on the
    Larry> standards track on the get-go.  The set of features offered
    Larry> by the two documents are sufficiently different that we
    Larry> should consider the two and the status of each
    Larry> independently.

I think Simon has the history more correct.  I think we discussed
moving FAST from standards track to experimental either at Dublin or
the IETF before that.

Since then FAST has gained significant implementation experience and I
believe spec clarity.  As such, I support publishing FAST on the
standards track.

I'll admit that when I was evaluating starttls most recently, I was
considering it for the informational/experimental track.  I'll have to
go back and read it for standards track.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Jun 2009 11:40:22 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    >> starttls has its own use cases, therefore to keep it
    >> progressing toward the standard tracks go forward.

    Simon> The case for STARTTLS is described in the document, and
    Simon> includes OpenPGP authentication against KDCs.  FAST does
    Simon> not support that as far as I can tell, and that is one of
    Simon> the driving reasons for krb5starttls.

Simon, I see no text in the document that shows how you would use
starttls to provide client authentication to the KDC.

If that is within scope for the current draft, I probably have
additional concerns regarding spec clarity for standards track.

If you are saying you could build that on top of starttls but the
current spec does not do so I agree.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Tue, 16 Jun 2009 18:37:30 +0000

I would like to clarify that my recent comments on starttls are opinions expressed as an individual.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Jun 2009 08:52:15 -0400

I'm running a bit behind, but I hope to have a version of the
preauthentication framework draft responsive to last call comments
received (and to the discussion of those comments) ready before the
Stockholm draft cutoff.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Sat, 27 Jun 2009 00:29:03 -0400

Sorry, still catching up on stuff; others have already made comments
similar to what I would have written.

In Appendix A, we should note that single-DES random-to-key is
"distribute 56 bits into high-7-bits of 8 octets and generate parity",
analagous to what the single-DES string-to-key does.

Should this document state that it updates RFC 3961 and RFC 3962?  Or
are we going to separately publish errata for those?

I'm not sure what Greg's observation about the "->" notation in
Section 6.1 is.  Perhaps using notation such as

    KRB-FX-CF1: (UTF-8 string, UTF-8 string) -> (UTF-8 string)
    KRB-FX-CF(x, y) = x || y

    KRB-FX-CF2: (protocol key, protocol key, octet string,
                 octet string)  ->  (protocol key)

    octet-string-1 = PRF+(K1, pepper1)
    octet-string-2 = PRF+(K2, pepper2)
    KRB-FX-CF2(K1, K2, pepper1, pepper2) =
            random-to-key(octet-string-1 ^ octet-string-2)

using the usual

    f: domain -> codomain
    f(x) = y

mathematical notation is better, making a distinction between
right-arrow and equals.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Sat, 27 Jun 2009 13:30:35 -0400

> Section 6.1 is.  Perhaps using notation such as

The text is:

       KRB-FX-CF2(protocol key, protocol key, octet string,
                 octet string)  ->  (protocol key)

       PRF+(K1, pepper1) -> octet-string-1
       PRF+(K2, pepper2) -> octet-string-2
       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
              random-to-key(octet-string-1 ^ octet-string-2)

So, in the first line we have a signature and the remaining lines are a
definition.  I am okay with the overloading of "->" there, although I am
also fine with using different notation as Tom suggests.

However, in the definition itself, -> is also used inconsistently.  In
the middle two lines, we have "assign the value of the left-hand
expression to the variable name on the right" and in the last line, we
have "define the function KRB-FX-CF2 with these arguments to be value of
the expression on the right".  So in four lines, we use -> to mean three
very different things.  It is only from context that the meaning is made
clear.

---

From: Ken Raeburn <[email-masked]>
Date: Sat, 27 Jun 2009 15:46:10 -0400

> are we going to separately publish errata for those?

For correcting errors, I think errata make more sense.

Ken