Subject: [Ietf-krb-wg] proposal for encrypted pa data

From: Larry Zhu <[email-masked]>
Date: Mon, 13 Apr 2009 08:14:22 -0700

At the Kerberos consortium interop event in Redmond, we have been
discussing the evolution of Kerberos and how FAST fits into that
picture.  FAST does a good job of protecting the Kerberos exchange
once you've decided to use FAST.  In addition, FAST provides several
key extensibility points.

However FAST alone is not a complete solution to the authenticated
plaintext problem in Kerberos.  FAST does not provide a secure
mechanism for determining if a KDC supports FAST.  Also, FAST does not
protect the request used to obtain the armor key.  In particular, the
set of enctypes sent by the client to the KDC in the armor key request
is unprotected.

As discussed in the referrals draft, Microsoft has extended the
KDC-REP structure to include encrypted-padata; that is used to provide
protected information about the referral.  We believe that this
mechanism could be used to protect obtaining the armor key and to
securely negotiate FAST.  Testing of a prototype of this approach at
the interop event was very promising and easy to implement for
multiple vendors.  The tricky part is figuring out when the encrypted
padata can be included.  We discuss that below.

Note that this is not a replacement for FAST.  The encrypted padata is
not a good general purpose mechanism for handling pre-authentication;
among other problems, you need to know the reply key before you can
access that information.  In addition, FAST protects the entire
request/response, while our approach for negotiating FAST focuses on
allowing the client to detect modifications.
So, we continue to remain confident in the FAST design and believe
this new mechanism compliments it. Here is the proposal that we would
like to validate with the working group. If we do not have objection,
we (Ken and I) would put the proposal in the next revision of the referrals
draft.

1) The client sends PA-REQ-ENC-PA-REP (149), with an empty pa-data value,
to indicate to the KDC it understands the encrypted-pa-data in the KDC reply
(defined in http://www.watersprings.org/pub/id/draft-ietf-krb-wg-kerberos-referrals-11.txt,
page 16).

2) If the KDC is updated and PA-REQ-ENC-PA-REP is included in the request,
the KDC MUST send PA-REQ-ENC-PA-REP in the encrypted-pa-data, the
PA-REQ-ENC-PA-REP pa-data value contains the checksum computed over the
type AS-REQ in the request. The checksum key is the reply key and the
checksum type is the required checksum type for the encryption type of
the reply key, and the key usage number is KEY_USAGE_AS_REQ (56).

3) KDC that supports PA-REQ-ENC-PA-REP must always set the ticket flag
enc-pa-rep(15) in all the tickets it returns.

4) If the client sends the PA-REQ-ENC-PA-REP in the request, and if the
enc-pa-rep ticket flag is present in the encrypted KDC reply part, the
client MUST reject the reply if no PA-REQ-ENC-PA-REP padata is included
in the encrypted-pa-data.

5) If the KDC supports FAST and the client includes PA-REQ-ENC-PA-REP in
the request, the KDC MUST always include a PA-FX-FAST padata with empty
padata value in the encrypted padata in the KDC reply.

Note that all the numbers in this proposal have been allocated by Tom and
these were used in testing in the interop event.

--Larry

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

---

From: Greg Hudson <[email-masked]>
Date: Mon, 13 Apr 2009 15:42:13 -0400

Does this proposal reopen FAST-protected kinit exchanges to a dictionary
attack?  The first preauth-required error would encrypt its padata in
the reply key, which at that point is the client long-term key.

(Apologies if I have misunderstood.)

---

From: Greg Hudson <[email-masked]>
Date: Mon, 13 Apr 2009 16:06:59 -0400

I believe my confusion is that encrypted padata is only sent as part of
a KDC reply, not as part of a KDC error, so in the case of a
preauth-protected exchange, encrypted padata won't be used until the
reply key is settled.  Sorry for the extra traffic.

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 14 Apr 2009 10:47:46 +0530

[Srinivas Cheruku] This would mean there is another exclusive round trip to
know whether FAST is supported by KDC. Can't we minimize the round-trips
before the client gets the ticket? E.g. a round-trip for FAST negotiation, a
round trip for etype-negotiation/pre-auth, and another for getting ticket.
Can't we combine FAST negotiation along with etype negotiation/pre-auth ?
e.g. can't the PA-FX-FAST data can contain the ETYPE-INFO/2 etc instead of
empty padata? I understand the FAST itself would have securely tunnelled the
pa-data and it would mean again encrypting FAST padata inside
PA-REQ-ENC-PA-REP. Am not sure whether this is good. Any opinions?

---

From: Greg Hudson <[email-masked]>
Date: Tue, 14 Apr 2009 12:34:50 -0400

On Tue, 2009-04-14 at 10:47 +0530, Srinivas Cheruku wrote:
[Larry:]
> padata value in the encrypted padata in the KDC reply.

[Srinivas:]
> PA-REQ-ENC-PA-REP. Am not sure whether this is good. Any opinions?

I don't think this proposal adds another round trip.  It's just adding a
padata value to the initial as-req request, and some encrypted padata
values to the final KDC reply.

Also, FAST does not add any more round trips to a preauth as-req
exchange as far as I know.  It's still as-req -> preauth-required error
-> as-req -> [more-preauth-needed -> as-req]... -> response, just with
more goop in each step.  (The bracketed portion is only present if a
FAST factor requires more than one exchange--no difference from the
pre-FAST world.)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Apr 2009 12:38:14 -0400

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> 5) If the KDC supports FAST and the client includes
    Srinivas> PA-REQ-ENC-PA-REP in the request, the KDC MUST always
    Srinivas> include a PA-FX-FAST padata with empty padata value in
    Srinivas> the encrypted padata in the KDC reply.

    Srinivas> [Srinivas Cheruku] This would mean there is another
    Srinivas> exclusive round trip to know whether FAST is supported
    Srinivas> by KDC. Can't we minimize the round-trips before the
    Srinivas> client gets the ticket? E.g. a round-trip for FAST
    Srinivas> negotiation, a round trip for
    Srinivas> etype-negotiation/pre-auth, and another for getting
    Srinivas> ticket.  Can't we combine FAST negotiation along with
    Srinivas> etype negotiation/pre-auth ?  

client->server: kdc-req: pa-req-enc-pa-rep   to obtain armor ticket
kdc->client: here's your armor ticket; I'm proving I support or do not support FAST
client->kdc: kdc-req: fast(encrypted_challenge)
kdc->client: as_rep fast(encrypted_challenge)

Two round trips, the first of which can be amortized across the life
time of the armor cache.  This assumes the client guesses the salt
correctly and guesses that the principal has a password not OTP or
pkinit.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 15 Apr 2009 10:31:48 +0530

client->server: kdc-req: pa-req-enc-pa-rep   to obtain armor ticket
kdc->client: here's your armor ticket; I'm proving I support or do not
support FAST
[Srinivas Cheruku] clever. I liked the fact that getting armor ticket
combined with knowing kdc supports FAST or not.

Two round trips, the first of which can be amortized across the life
time of the armor cache.  
[Srinivas Cheruku] But, if we are using the same armor ticket from the cache
and want to send another kdc-req later, then we should know whether kdc
supports FAST or not. Maybe we need to cache whether kdc supports FAST or
not somewhere so that we can use FAST with kdc-reqs later using the same
armor ticket.

This assumes the client guesses the salt
correctly and guesses that the principal has a password not OTP or
pkinit.
[Srinivas Cheruku] yes, I understand.

Thanks,
Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 15 Apr 2009 16:38:00 +0530

Sam,

In Section 6.3  Managing States for the KDC, there is a typo cooking instead
of cookie

   A client MAY throw away the state associated with a conversation and
   begin a new conversation by discarding its state and not including a
   cooking in the first message of a conversation.

When pre-auth required and using FAST, we need to add cookie to KRB-ERROR,
otherwise the client may think that KDC wants to terminate the conversation.

So, the PA-FX-COOKIE and PA-FX-FAST will be included in the KRB-ERROR.e_data
and other PA-DATA like ETYPE-INFO(2), PA-FX-ERROR would be added to
KrbFastResponse.padata. - right?

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Apr 2009 08:47:33 -0400

Thanks; typo corrected.

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 17 Apr 2009 12:03:29 +0530

Sam,

The section "6.5.5.  Outer and Inner Requests" describes that the 
 1. outer request contains PA-FX-FAST and PA-FX-COOKIE and all other padata
would be ignored by KDC
 2. AS reponse contains PA-FX-FAST and PA-FX-COOKIE and all other padata are
included in PA-FX-FAST response

Do you think it is better to include PA-FX-COOKIE inside PA-FX-FAST similar
to other padata? e.g. outer request and AS response would contain only
PA-FX-FAST and other padata including PA-FX-COOKIE inside PA-FX-FAST. This
would mean that PA-FX-COOKIE would also be secured similar to other padata.

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Apr 2009 03:52:23 -0400

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> Do you think it is better to include PA-FX-COOKIE inside
    Srinivas> PA-FX-FAST similar to other padata? e.g. outer request
    Srinivas> and AS response would contain only PA-FX-FAST and other
    Srinivas> padata including PA-FX-COOKIE inside PA-FX-FAST. This
    Srinivas> would mean that PA-FX-COOKIE would also be secured
    Srinivas> similar to other padata.

Yes.  The cookie was outside because you needed the cookie to be
outside in order to calculate the finish checksum without some very
complicated compression functions.  However, now that we've removed
the finish checksum, the cookie needs to move inside.

Here's my draft text from 6.5.5 in draft 11.  We'll be posting draft
11 in a couple of days after Larry finishes his edits.

    <section title="Outer and Inner Requests">
      <t>Typically, a client will know that FAST is being used before
      a request containing PA-FX-FAST is sent.  So, the outer AS
      request typically only includes one  pa-data item: PA-FX-FAST.
      The client MAY include additional pa-data, but the KDC MUST
      ignore the outer request body and any padata besides PA-FX-FAST
 if PA-FX-FAST is processed.  In the case of the TGS request, the outer request should include PA-FX-FAST and PA-TGS-REQ.</t>
      <t>When an AS generates a response, all padata besides PA-FX-FAST should be included in PA-FX-FAST.  The client MUST ignore other padata outside of PA-FX-FAST.</t>
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg