Subject: [Ietf-krb-wg] Submitted draft 11 of preauthentication framework

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Mar 2009 16:52:10 -0400

I've submitted draft 11.  It contains the conversation clarification I
discussed on list, as well as what I believe to be a complete IANA and
constants section.

Larry and I convinced ourselves that an easy solution to the TGS
binding problem is to checksum the pa-tgs-req encoding rather than the
kdc-req-body encoding in the TGS case.  This draft reflects that,
although confirmation from the WG is needed.  Larry and I still aren't
sure there is an attack in the TGS binding case, but it seemed easier
to fix than to analyze.  

 This draft does not resolve the checksum in the finish message: I
believe that we have had inadequate discussion for me to guess which
way the WG is going.  Or at least I believed that when I worked on the
draft this weekend.

So far I'd summarize the discussion of the finish message as follows.
Everyone who has looked at it thinks the current version is kind of
complicated, although I think people also believe it can be
implemented.  People believe the recursive checksum would be an
improvement.  People who have spent enough time to come to a
conclusion seem to believe that no checksum is required.  No one has
spoken out against the change being too large this late in the
process.

So, my current guess is that we'll end up without the checksum and
presumably with a nonce in the fast_response.  We really need more
discussion though.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Mar 2009 17:16:49 -0400

> way the WG is going.  Or at least I believed that when I worked on the

I agree.

> presumably with a nonce in the fast_response.  We really need more

Yes, we do.  Let's plan to spend some meeting time on this.

-- Jeff

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 10 Mar 2009 14:44:15 +0530

Sam,

>From draft 10,
_____
    PRF+(protocol key, octet string) -> (octet string)

    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
                  pseudo-random( key, 2 || shared-info ) ||
                  pseudo-random( key, 3 || shared-info ) || ...
_____

The pseudo-random() for AES128/256 from RFC 3962 (section 4 Key Generation
from Pass Phrases or Random Data) is as follows:
------
   tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
   key = DK(tkey, "kerberos")

   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
   passphrase and salt, as described in Appendix B.1 to PKCS#5.
-----

So when using AES, pseudo-random function= 
 1. PBKDF2?
Or
 2. SHA-1 HMAC of the passphrase and salt - maybe passphare=key and salt=1
|| shared-info?

Can you please confirm?

Thanks and Regards,
Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 10 Mar 2009 16:18:33 +0530

Sam,

In section "3.2.  Initial Pre-authentication Required Error" - paragraph 3:

____
For each mechanism that is
   offered alone, the KDC includes the pre-authentication type ID of the
   mechanism in the padata sequence returned in the
   KDC_ERR_PREAUTH_REQUIRED error.
____

Does this mean only the pre-auth mechanisms offered alone will be added to
the e-data of the KRB-ERROR? 
I think the KRB-ERROR should contain the pre-authentication type IDs of the
mechanisms that are offered alone as well as that are offered as
authentication sets added in the decreasing preference order. 

Thanks and Regards,
Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 10 Mar 2009 16:59:05 +0530

Sam,

In section " 6.4.  Pre-authentication Set"
_____

   The client sends the padata-value for the first mechanism it picks in
   the pre-authentication set, when the first mechanism completes, the
   client and the KDC will proceed with the second mechanism, and so on
   until all mechanisms complete successfully.  The PA-FX-COOKIE as
   defined in Section 6.3 MUST be sent by the KDC so that the
   conversation can continue if the conversation involves multiple KDCs.
_____

Does this mean that PA-FX-COOKIE should be used only when using multiple
KDCs? I think PA-FX-COOKIE should be used irrespective of number of KDCs so
as to store the state info in case of multiple round trips required for
authentication using an authentication set. 

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Mar 2009 09:44:28 -0400

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

    s> Sam,
    >> From draft 10,
    s> The pseudo-random() for AES128/256 from RFC 3962 (section 4 Key Generation
    s> from Pass Phrases or Random Data) is as follows:
    s> ------
    s>    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
    s>    key = DK(tkey, "kerberos")

    s>    The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
    s>    passphrase and salt, as described in Appendix B.1 to PKCS#5.
    s> -----

    s> So when using AES, pseudo-random function= 
    s>  1. PBKDF2?
    s> Or
    s>  2. SHA-1 HMAC of the passphrase and salt - maybe passphare=key and salt=1
    s> || shared-info?

None of the above.  pbkdf2 requires a pseudo-random function.  Its
specification in PKCS #5 suggests using hmac-sha-1 as that
pseudo-random function.  RFC 3962 section 4 mandates that we take that
recommendation when using PBKDF2.  The pseudo-random function we're
talking about is defined at the end of Page 15 of RFC 3961.

However, there has been discussion in the last week about whether
there is a bug in RFC 3961.  I have proposed that rather than
truncating to a multiple of m, we truncate to the underlying block
size of the block cipher on which e is based.  That is, for AES,
truncate to 128 bits instead of 160 bits.
So, pseudo_random(string) would be
e(h(string)) using the key dk(key,"prf").

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Mar 2009 09:57:54 -0400

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

    Srinivas> Sam,
    Srinivas> In section "3.2.  Initial Pre-authentication Required Error" - paragraph 3:

    Srinivas> ____
    Srinivas> For each mechanism that is
    Srinivas>    offered alone, the KDC includes the pre-authentication type ID of the
    Srinivas>    mechanism in the padata sequence returned in the
    Srinivas>    KDC_ERR_PREAUTH_REQUIRED error.
    Srinivas> ____

    Srinivas> Does this mean only the pre-auth mechanisms offered alone will be added to
    Srinivas> the e-data of the KRB-ERROR? 

A mechanism can be offered alone, offered both alone and as part of an
authentication set, or offered only as an authentication set.

The third group--mechanisms that KDC policy permis only as part of an
authentication set--are not included directly in the e_data.  Instead,
they are only included in the pa-authentication-set elements.

Mechanisms in the first group appear only in the e_data and appear in no pa-authentication-set elements.

Mechanisms in the second group appear both in the e_data and in the
pa-authentication-set elements.

    Srinivas> I think the KRB-ERROR should contain the
    Srinivas> pre-authentication type IDs of the mechanisms that are
    Srinivas> offered alone as well as that are offered as
    Srinivas> authentication sets added in the decreasing preference
    Srinivas> order.

Do you mean that the third group of mechanisms --those only useful in
authentication sets--should be included in e_data?

If so, I think that causes a couple of problems.  First, a client that
does not understand pa-authentication-set might try to use one of
those mechanisms.  Secondly, it's difficult for a client to
distinguish third group (alone and part of an authentication set) from
second group (authentication set).  Also, if the mechanism has
different parameters when used in part of an authentication set it is
difficult to express that.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Mar 2009 09:59:56 -0400

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

    Srinivas> Sam,
    Srinivas> In section " 6.4.  Pre-authentication Set"
    Srinivas> _____

    Srinivas>    The client sends the padata-value for the first mechanism it picks in
    Srinivas>    the pre-authentication set, when the first mechanism completes, the
    Srinivas>    client and the KDC will proceed with the second mechanism, and so on
    Srinivas>    until all mechanisms complete successfully.  The PA-FX-COOKIE as
    Srinivas>    defined in Section 6.3 MUST be sent by the KDC so that the
    Srinivas>    conversation can continue if the conversation involves multiple KDCs.
    Srinivas> _____

    Srinivas> Does this mean that PA-FX-COOKIE should be used only when using multiple
    Srinivas> KDCs? 

No, sorry; that text is unclear.  The cookie should be used all the
time because doing so allows you to write an implementation that
supports multiple KDCs.  The cookie should be used all the time for
the reason you describe.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 11 Mar 2009 11:00:42 +0530

See Below.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: 10 March 2009 19:14
To: Srinivas Cheruku
Cc: [email-masked]
Subject: What is the RFC 3961 PRF for AES?

    s> Sam,
    >> From draft 10,
    s> The pseudo-random() for AES128/256 from RFC 3962 (section 4 Key
Generation
    s> from Pass Phrases or Random Data) is as follows:
    s> ------
    s>    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
    s>    key = DK(tkey, "kerberos")

    s>    The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of
the
    s>    passphrase and salt, as described in Appendix B.1 to PKCS#5.
    s> -----

    s> So when using AES, pseudo-random function= 
    s>  1. PBKDF2?
    s> Or
    s>  2. SHA-1 HMAC of the passphrase and salt - maybe passphare=key and
salt=1
    s> || shared-info?

[Srinivas Cheruku] thank you for clarifying. I have seen in your draft
pointing to sections from other RFCs. Maybe, you can point to this section
in RFC 3961 instead of just RFC 3961?

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 11 Mar 2009 11:13:24 +0530

Thank you. Maybe you need to change the text in the next draft?

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: 10 March 2009 19:30
To: Srinivas Cheruku
Cc: [email-masked]
Subject: Re: FAST - Pre-authentication Set

    Srinivas> Sam,

    Srinivas>    The client sends the padata-value for the first mechanism
it picks in
    Srinivas>    the pre-authentication set, when the first mechanism
completes, the
    Srinivas>    client and the KDC will proceed with the second mechanism,
and so on
    Srinivas>    until all mechanisms complete successfully.  The
PA-FX-COOKIE as
    Srinivas>    defined in Section 6.3 MUST be sent by the KDC so that the
    Srinivas>    conversation can continue if the conversation involves
multiple KDCs.
    Srinivas> _____

    Srinivas> Does this mean that PA-FX-COOKIE should be used only when
using multiple
    Srinivas> KDCs?

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 11 Mar 2009 12:04:38 +0530

Sam,

In section " 6.5.1.1.  Ticket-based Armors"
____
       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
                   "subkeyarmor", "ticketarmor" )

   The `ticket_key' is the session key from the ticket in the ap-req.
   The `subkey' is the ap-req subkey.  This construction guarantees that
   both the KDC (through the session key) and the client (through the
   subkey) contribute to the armor key.
____

The ticket_key is used instead of ticket_session_key. Maybe you need to
correct this.

_____
   1.  If the client is authenticating from a host machine whose
       Kerberos realm has an authentication path to the client's realm,
       the host machine obtains a TGT by using the host keys.  If the
       client's realm is different than the realm of the local host, the
       machine then obtains a cross-realm TGT to the client's realm as
       the armor ticket.  Otherwise, the host's primary TGT is the armor
       ticket.
_____

There are three cases:
 1. client principal and the host machine principal are from the same REALM.
So, get the TGT for the host machine using the host keys and use this as
armor ticket.
 2. client realm is different host realm and the cross-realm TGT can be got.
So, use cross-realm TGT as armor ticket
 3. Otherwise, the host's primary TGT is the armor ticket. Do you mean that
the case where client realm and host realm might be different and there is
no trust relationship. In this case, the armor ticket(TGT got from host
realm) cannot be decrypted by the client KDC as the client KDC doesn't share
as secret (longterm) key with host and KDC cannot get the ticket_session_key
in the armor ticket as it cannot decrypt it - How can armor key generated by
KDC in this case? I am not thinking straight or confused, please clarify.

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Mar 2009 07:10:11 -0400

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

    s> Sam,
    s> In section " 6.5.1.1.  Ticket-based Armors"
    s> ____
    s>        armor_key = KRB-FX-CF2( subkey, ticket_session_key,
    s>                    "subkeyarmor", "ticketarmor" )

    s>    The `ticket_key' is the session key from the ticket in the ap-req.
    s>    The `subkey' is the ap-req subkey.  This construction guarantees that
    s>    both the KDC (through the session key) and the client (through the
    s>    subkey) contribute to the armor key.
    s> ____

    s> The ticket_key is used instead of ticket_session_key. Maybe you need to
    s> correct this.

I agree that makes things more clear.
Will fix.

    s> _____
    s>    1.  If the client is authenticating from a host machine whose
    s>        Kerberos realm has an authentication path to the client's realm,
    s>        the host machine obtains a TGT by using the host keys.  If the
    s>        client's realm is different than the realm of the local host, the
    s>        machine then obtains a cross-realm TGT to the client's realm as
    s>        the armor ticket.  Otherwise, the host's primary TGT is the armor
    s>        ticket.
    s> _____

    s> There are three cases:
    s>  1. client principal and the host machine principal are from the same REALM.
    s> So, get the TGT for the host machine using the host keys and use this as
    s> armor ticket.

Agreed.

    s>  2. client realm is different host realm and the cross-realm TGT can be got.
    s> So, use cross-realm TGT as armor ticket

Interesting.  Here, I think we have the first case where two
implementers have interpreted the spec differently in a way that would
cause an interop problem.  If the client's realm is client.example.com
I'll get krbtgt/[email-masked].  I will use
cross realm TGTs to obtain that.

I think the spec permits either interpretation.

    s>  3. Otherwise, the host's primary TGT is the armor ticket. Do you mean that
    s> the case where client realm and host realm might be different and there is
    s> no trust relationship. 

Calling an authentication path a trust relationship is an AD
architectural issue.  Kerberos implies very little trust with an
authentication path.

    s> In this case, the armor ticket(TGT got from host
    s> realm) cannot be decrypted by the client KDC as the client KDC doesn't share
    s> as secret (longterm) key with host and KDC cannot get the ticket_session_key
    s> in the armor ticket as it cannot decrypt it - How can armor key generated by
    s> KDC in this case? I am not thinking straight or confused, please clarify.

The first sentence says that if there is an authentication path then the host should obtain a TGT in its realm.  The second sentence describes case 2.  The third sentence (otherwise) describes case 1.
There is no case 3 in this part of the text.

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 11 Mar 2009 17:01:03 +0530

The first sentence says that if there is an authentication path then the
host should obtain a TGT in its realm.  The second sentence describes case
2.  The third sentence (otherwise) describes case 1.
There is no case 3 in this part of the text.
[Srinivas Cheruku] thanks for explaining. Now, I can interpret what you
mean.

We use host keys to get the TGT. So, the host
principal=host/<host-fqdn>@REALM or can this be any other service principal
e.g. armor/<host-fqdn>@REALM which is available in the host keytab?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Mar 2009 07:47:02 -0400

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

    Srinivas> We use host keys to get the TGT. So, the host
    Srinivas> principal=host/<host-fqdn>@REALM or can this be any other service principal
    Srinivas> e.g. armor/<host-fqdn>@REALM which is available in the host keytab?

I don't think anything constraints what principal you can use.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 11 Mar 2009 19:02:58 +0530

Sam,

Is there any constraint that FAST can be used only with AES or it can be
used with RC4, DES also?

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Mar 2009 09:41:15 -0400

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

    Srinivas> Sam,
    Srinivas> Is there any constraint that FAST can be used only with AES or it can be
    Srinivas> used with RC4, DES also?

It can certainly be used with RC4 and DES.  You will of course have to
implement the appropriate pseudo-random for RC4 and DES.

I think the PRF for RC4 is hmac-md5, and RFC 3961 gives the PRF for DES.

---

From: Tim Alsop <[email-masked]>
Date: Wed, 11 Mar 2009 13:47:08 +0000

Sam,

I think Srinivas asked this question because the draft mentions (by way of example) support for ETYPE-INFO2, but does not mention ETYPE-INFO. Our understanding is that ETYPE-INFO2 is used by AES and DES/RC4 use ETYPE-INFO.

Thanks,
Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: 11 March 2009 13:41
To: Srinivas Cheruku
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] FAST - supported etype

    Srinivas> Sam,

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Mar 2009 09:56:44 -0400

>>>>> "Tim" == Tim Alsop <[email-masked]> writes:

    Tim> Sam,
    Tim> I think Srinivas asked this question because the draft mentions (by way of example) support for ETYPE-INFO2, but does not mention ETYPE-INFO. Our understanding is that ETYPE-INFO2 is used by AES and DES/RC4 use ETYPE-INFO.

Please see RFC 4120 page 25.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 12 Mar 2009 10:03:50 +0530

Srinivas> Sam,
    Srinivas> Is there any constraint that FAST can be used only with AES or
it can be
    Srinivas> used with RC4, DES also?

I think the PRF for RC4 is hmac-md5, and RFC 3961 gives the PRF for DES.
[Srinivas Cheruku] Thanks. I think the PRF to be used with various
encryption types is not clear in the draft. Can you please add/change text
so that this is clear?

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 12 Mar 2009 10:42:09 +0530

[Srinivas Cheruku] Sorry for stretching this discussion. I want to make sure
that I understand the PRFs to be used with various etypes like DES, RC4 and
AES correctly, I have listed them below:

1. des-md5/des-cbc, the PRF used would be "des-cbc(md5(input-string),
ivec=0)"

2. RC4 - from RFC 4757 - section 5.  Encryption Types
____

   The pseudo-random operation [RFC3961] for both enctypes above is
   defined as follows:

           pseudo-random(K, S) = HMAC-SHA1(K, S)

   where K is the protocol key and S is the input octet string.
   HMAC-SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the
   20-octet digest.
____
 So, do we need to use hmac-sha1 as PRF for RC4?

3. AES - as you said in another email

pseudo-random function    tmp1 = H(octet-string)
                          tmp2 = truncate tmp1 to multiple of m -- truncate
to key block size and not m.
                          PRF = E(DK(protocol-key, prfconstant),
                                  tmp2, initial-cipher-state)

   The "prfconstant" used in the PRF operation is the three-octet string
   "prf".

Also, please specify the HMAC (H) to be used with AES, Is this hmac-sha1?

Thanks and Regards,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Mar 2009 06:19:35 -0400

Srinivas> Sam,
    Srinivas> it can be

    Srinivas> It can certainly be used with RC4 and DES.  You will of course have to
    Srinivas> implement the appropriate pseudo-random for RC4 and DES.

    Srinivas> I think the PRF for RC4 is hmac-md5, and RFC 3961 gives the PRF for DES.
    Srinivas> [Srinivas Cheruku] Thanks. I think the PRF to be used with various
    Srinivas> encryption types is not clear in the draft. Can you please add/change text
    Srinivas> so that this is clear?

No.  No, the definition of a pseudo-random function for an encryption
type is a attribute of the specification of that encryption type and
falls out of RFC 3961.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Tue, 24 Mar 2009 11:42:55 -0700

>Also, please specify the HMAC (H) to be used with AES, Is this hmac-sha1?

The AES prf does not invoke any HMAC operation. Otherwise please point me to where you need the HMAC(H).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Srinivas Cheruku
Sent: Wednesday, March 11, 2009 10:12 PM
To: 'Sam Hartman'
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] FAST - supported etype

Thanks and Regards,
Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 25 Mar 2009 10:07:51 +0530

Larry,

There was another thread where I asked Sam to clarify the PRF to be used
with AES and his reply from the other thread as follows:
_______________

    s> Sam,

None of the above.  pbkdf2 requires a pseudo-random function.  Its
specification in PKCS #5 suggests using hmac-sha-1 as that pseudo-random
function.  RFC 3962 section 4 mandates that we take that recommendation when
using PBKDF2.  The pseudo-random function we're talking about is defined at
the end of Page 15 of RFC 3961.

However, there has been discussion in the last week about whether there is a
bug in RFC 3961.  I have proposed that rather than truncating to a multiple
of m, we truncate to the underlying block size of the block cipher on which
e is based.  That is, for AES, truncate to 128 bits instead of 160 bits.
So, pseudo_random(string) would be
e(h(string)) using the key dk(key,"prf").

___________

>From end of page 15 of RFC3961, there is H being used. H is not HMAC?

So, am confused now as to what to use as PRF for AES. Please clarify.

Thanks,
Srini

-----Original Message-----
From: Larry Zhu [mailto:[email-masked]] 
Sent: 25 March 2009 00:13
To: Srinivas Cheruku; 'Sam Hartman'
Cc: [email-masked]
Subject: RE: [Ietf-krb-wg] FAST - supported etype

>Also, please specify the HMAC (H) to be used with AES, Is this hmac-sha1?

The AES prf does not invoke any HMAC operation. Otherwise please point me to
where you need the HMAC(H).

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Srinivas Cheruku
Sent: Wednesday, March 11, 2009 10:12 PM
To: 'Sam Hartman'
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] FAST - supported etype

Thanks and Regards,
Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Mon, 30 Mar 2009 15:33:47 +0530

Larry,

AES uses sha1 as the hash algorithm and dont use any HMAC for PRF. Sorry, I
got confused seeing H in the definition

e.g. "pseudo-random function    tmp1 = H(octet-string)" from RFC 3961

Thanks,
Srini

-----Original Message-----

Thanks and Regards,
Srini