Subject: [Ietf-krb-wg] Review of draft-ietf-krb-wg-referrals

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Dec 2008 13:36:41 -0500 (EST)

I'm in the middle of needing to understand the security implications
of referrals, so I decided to read the referrals draft.

First, the draft uses the word trusted as an adjective describing
Kerberos realms.  What does this mean?  I'd recommend clearly defining
trusted Kerberos realm or using other terminology.  The Kerberos
consortium published a paper called "The Role of Kerberos in Modern
Information Systems," that goes into a fair bit of detail discussing
when trust is implied and to what extent.  I'd see if you could align
with that terminology.

Whenever you use the word trusted, I should be able to answer the question of  trusted by whom to do what.

Section 4 is particularly problematic because it claims that issuing a
cross-realm ticket implies a trust relationship.  I think that claim
would be very bad to make in a standards-track document.

I do not understand the concern with U2U and client names.
I suspect this concern has been explained to me in the past or even worse I may have been involved in coming up with it.
I suspect there is a moment of embarrassment in the future.

Section 7:

>   The true principal name of the client, returned in AS-REQ, can be
>   validated in a subsequent TGS message exchange where its value is
>   communicated back to the KDC via the authenticator in the PA-TGS-REQ
>   padata [RFC4120].  However, this requires trusting the referred-to

I don't understand this text.  my confusion starts with a name being
returned in an as-req, but even when I substitute as-rep for as-req, I
am still confused.

pa-server-referral is encrypted in the session key of the resulting
ticket.  However there is a discussion of security problems that would
result if the kdc reply key were used instead.  I don't see why this
applies.  Also, it's not entirely clear what the checksum is over (or
why it is necessary given the choice of encryption key).  When you say
that the padata field is omitted, do you mean that I checksum the
kdc-rep as it will appear with a absent padata sequence?
Is this perhaps an incomplete change based on the session key?

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

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 17 Dec 2008 16:50:49 -0500

Thanks for the comments, Sam.  I haven't had much time to work on this  
draft recently, but I'll try to schedule some soon.

> of referrals, so I decided to read the referrals draft.

Good luck.  Figuring out the security implications and how to address  
them is still one of my biggest issues with it.

> question of  trusted by whom to do what.

Good point.  I've come to dislike vague use of the word in Kerberos  
contexts myself.

> I suspect this concern has been explained to me in the past or even  
> worse I may have been involved in coming up with it.

The main issue I recall is, Alice and Bob chat in the company  
lunchroom and agree to exchange some data later via some P2P system  
with U2U authentication.  Both type in their email ("enterprise")  
names to log in, and that's the info they exchange at the lunch table.  
When an authentication exchange happens in this P2P system, and the  
principal name [email-masked] comes up, is that Alice  
or someone else?  One of the parties gets to send an enterprise name  
to the KDC, but the other just supplies a TGT and gets back something  
encrypted in its session key.  We can include a copy of the alias  
info, to help with this problem, but doing that automatically brings  
up privacy issues.

> returned in an as-req, but even when I substitute as-rep for as-req, I

Yeah, that's phrased badly.

If the client has an updated principal name to use but got it  
insecurely, then sending it in the TGS-REQ (checksummed in the  
authenticator) along with the copy in the encrypted ticket (from the  
KDC, inaccessible to the client) should cause an error  
(KRB_AP_ERR_BADMATCH?) from the KDC if they don't match.

> Is this perhaps an incomplete change based on the session key?

Yes, the padata field being omitted means kdc-rep with that field  
absent.  I'm not certain if the checksum is still needed given the use  
of the returned session key for encryption.

As to the rest ... *sigh*.  I do need to review it all....

Ken