Subject: [Ietf-krb-wg] Protection of client name in referral request

From: Sam Hartman <[email-masked]>
Date: Fri, 28 Jan 2011 14:46:19 -0500

As discussed at IETF 79, I'm working on the referrals document.

One of the long-standing open issues with refferals has been what
security attacks are in scope and what attacks are out of scope.

The FAST negotiation proposal Larry made at
https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007593.html will
provide protection of the request between the client and KDC.

In the AS request, nothing currently protects the client name returned
to the client from the KDC.  That is, an attacker can modify the name
that the client thinks it was authenticated as.  The attacker can
probably also substitute a ticket.  It might even be possible for the
attacker to substitute in a ticket for the name that the attacker
modified the request to claim.

This attack is not possible if the client uses FAST or starttls.

I'm wondering how serious of an issue this is for clients attempting to
obtain a ticket to use as a fast armor ticket.

Here are the things that limit the value of this attack:

1) At least in principle a client can obtain an armor ticket without
setting the  canonicalize flag. If the canonicalize flag is not set,
then  the client can discard a response with a changed client name.

2) Changing the returned client name only creates a DOS. When the name
fails to match what is in an authentication header a server will reject
the ticket. Similarly, changing the ticket to one with a different
session key creates a DOS because the service will reject the ap-req.

It's relatively easy to fix: we can copy some or all of the unencrypted
data into a enc-padata.
My question is whether given fast and starttls we need to solve this
problem yet again.

My recommendation is that we not address this problem again.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Fri, 28 Jan 2011 15:20:38 -0500

> then  the client can discard a response with a changed client name.

Would you expect it to be common to use the canonicalize flag when
getting an initial ticket for armor?  I wouldn't.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 28 Jan 2011 16:27:32 -0500

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Fri, 2011-01-28 at 14:46 -0500, Sam Hartman wrote:
    >> 1) At least in principle a client can obtain an armor ticket
    >> without setting the canonicalize flag. If the canonicalize flag
    >> is not set, then the client can discard a response with a changed
    >> client name.

    Greg> Would you expect it to be common to use the canonicalize flag
    Greg> when getting an initial ticket for armor?  I wouldn't.

For some implementations, yes.
I would not expect it to be common for MIT Kerberos.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg