Subject: [Ietf-krb-wg] WG Last Call: draft-ietf-krb-wg-cross-problem-statement-01.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 25 Nov 2007 00:17:46 -0500 (EST)

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

Title:           Problem statement on the cross-realm operation of
                 Kerberos
Filename:        draft-ietf-krb-wg-cross-problem-statement-01.txt
Intended Status: Informational

   There are some issues when the cross-realm operation of the Kerberos
   Version 5 [RFC4120] is employed into actual specific systems.  This
   document describes some examples of actual systems, and lists
   requirements and restriction of the operation in such system.  Then
   it describes issues when we apply the cross-realm operation to such
   system.

Due to the upcoming IETF meeting, this last call is extended to three
weeks instead of the usual two.  It will expire at 23:59 EDT on Friday,
Dec. 14, 2007.

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-ietf-krb-wg-cross-problem-statement-01.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: Chaskiel M Grundman <[email-masked]>
Date: Mon, 26 Nov 2007 17:28:49 -0500

> Kerberos Working Group on whether to send the following document to the

I didn't realize this was happening so soon. I suppose I should 
comment......

(I'll also point out that if the purpose of this document was to get people 
to talk about cross realm issues, then it appears to have not succeeded)

If the working group and IESG approves this document,  what does it mean? 
Does it mean that we think that it really is a problem that cross-realm 
transactions require doing more than one encryption operation on the client 
(5.5)? That it makes sense to firewall off the kdc port (and use another 
kdc as a proxy) (5.4)? (Issue 5.6 (client network access to remote home 
kdcs), which is similar to 5.4, can be addressed by using IAKERB in the 
authentication protocol for the network gateway, once iakerb happens.)

As far as the trust issue (5.2) is concerned, I think that it is really 
about policy, not about the protocols. If you want to trust principals from 
a foreign realm to access your services, you need to make sure there is a 
trusted path between the realms. if you don't have a path you can trust, 
then you need to issue credentials directly to the foreign users.

In my opinion, the referenced SPECCROSS paper overstates the problem. In 
particular:

"Any rogue TGS can impersonate a client C anywhere outside
of C's realm, even if C has never contacted this TGS. This
dishonest TGS TI can make up a ticket for a 'next hop' and
spoof C's sending a request using this ticket. C does not need
to be involved, and not even to exist if the end-server doesn't
know C in the first place."

is not quite true. Only a TGS that is along a valid path from C's realm to 
the server's realm can impersonate the client. TGS's that are not along 
such a path would end up with tickets whose TRANSITED field contains a bad 
path, and would be rejected by any proper application server (or by one of 
the legitimate kdcs between the rogue and the server's realm, if they are 
so configured).

Finishing and deploying PKCROSS doesn't solve this problem, it only moves 
it. In a hypothetical PKCROSS world, the certificate authorities that are 
used to establish trust between realms can impersonate any client in any 
realm that they are the basis for trust with. I believe that such an entity 
could even conduct a MITM attack and learn the session key, but I don't 
have the right background to try and prove it.

Thinking about this has caused me to realize something unfortunate: There 
is no way for a client to be reassured about the path a cross-realm ticket 
acquisition has taken. The application server can use the 
transited-policy-checked ticket flag, because that is set by a kdc in its 
home realm, but the client has to be able to do all the checking itself, 
because the kdc it ultimately trusts doesn't get to see the path.

P.S. There are some english grammar issues with this document. If it would 
be useful, I could help with them, or it could be decided that this can be 
left to the rfc editor, since they will mess with grammar anyway.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Nov 2007 17:50:39 -0500 (EST)

> to talk about cross realm issues, then it appears to have not succeeded)

Well, the point is to write down what we think the issues are, which
hopefully will lead to discussion and solutions for at least some of them.

> (5.5)?

It means we think it's a problem that affects some classes of clients.
It does not mean we think that problem should be solved at all costs.

More specifically, approval and publication of this document does _not_
mean that this working group is automatically tasked with solving each of
the issues mentioned.  Some of them may be resolved "for free" as a result
of existing work; others won't, and adding work items to solve them is not
within the scope of our current charter.  What is in scope is discussing
the problems themselves and evaluating approaches; in my mind this means
we can consider proposals for solutions, consider which problems we think
are important enough to work on even in the absence of a well-baked
proposal, and then ask for a charter update to work on those items.

> That it makes sense to firewall off the kdc port (and use another
> kdc as a proxy) (5.4)?

Hm; I don't think that's what that says.  I read it to say that
firewalling off the KDC doesn't scale, if you have cross-realm
associations, because you have to make holes for every foreign realm.
Maybe some clarification is called for here?

I'm not going to reply to your other comments at the moment.
But I hope other people do.

-- Jeff

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 29 Nov 2007 11:48:57 +0900

Hi Chaskiel,
(I apologize to you, if you mind that I call you like that.)

> If the working group and IESG approves this document,  what does it mean? 

Jeff> More specifically, approval and publication of this document does _not_
Jeff> mean that this working group is automatically tasked with solving each of
Jeff> the issues mentioned.

I believe that writing down the issues leads to the discussion.
And as Jeff mentioned, even if IESG approves this document, we
should think what should be necessary, and what we produce to
solve the problem, as well as which problem we should make the
item of this WG.

> be useful, I could help with them,

Thank you very much for your suggestion.  It will be definitely helpful
for me anytime.  I definitely appreciate you!