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

From: "Saber Zrelli" <[email-masked]>
Date: Thu, 6 Dec 2007 21:12:54 +0900 (JST)

Hi Chaskiel,

Thank you for your comments,

>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.)

The issues are not quite similar. While issue 5.4 is about "Exposure of Kerberos KDC",
the issue 5.6 is related the usability of Kerberos for network access control. If the
client needs to have Kerberos credentials to gain network access (e.g IPSec using KINK
with a router) then a "dead-lock" situation may occur. The local access network may
allow access to the local KDCs. However roaming users still need a full Internet
connection to reach their home KDCs.

IAKERB may provide an answer to this issue. And this document does not contradict that.

>As far as the trust issue (5.2) is concerned,

Issue 5.2 is about the exposure of the cross-realm operations to "man in the middle
attacks" , it is not about trust.

>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.

Policy assures you that the client will follow a specified trusted path, however, the
policy does not prevent a KDC in the trust path from being corrupted nor does it prevent
the consequences.

The issue 5.2 attempts to highlight the impact of having a corrupted KDC in the trust
path. We think that this issue should be resolved through extensions to the Kerberos
cross-realm protocol.

>
>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).

"rogue TGS" means a corrupted TGS in a valid path.

>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.

This ID is not promoting PKCROSS. But in general, concerning PKI based solutions, IMO
the CA would only sign your KDC certificate. Since you will be the unique owner of the
private key, even the CA can not impersonate your KDC. However this may need further
analysis as you said.

Regards,
Saber Zrelli

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

---

From: Shoichi Sakane <[email-masked]>
Date: Mon, 17 Dec 2007 14:17:31 +0900

Hi All,

About the WGLC of draft-ietf-krb-wg-cross-problem-statement-01.txt,
I would like to update the draft.  At least, I would like to add
a text to clarify that this draft will not enforce new actions to
the WG group according to Chaskiel's comment, AND to add a text
into section 6 according to Love's comment.

And Chaskiel gave me some grammer corrections.  I would like to
adopt it.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg