Sam Hartman wrote:
>
> Hi, Doug. Jeffrey Altman and I were looking at capaths configuration
> today and we were wondering why you need to duplicate information.
>
> For example we have the following path:
>
> [capaths]
> RAEBURN.ORG = {
> ATHENA.MIT.EDU = .
> DEMENTIA.ORG = ATHENA.MIT.EDU
> SECURE-ENDPOINTS.COM = ATHENA.MIT.EDU
> SECURE-ENDPOINTS.COM = DEMENTIA.ORG
>
> }
>
> That is, we go from RAEBURN.ORG to ATHENA.MIT.EDU to DEMENTIA.ORG to
> SECURE-ENDPOINTS.COM.
>
> Why do we need the line
> secure-endpoints.com = ATHENA.MIT.EDU
You can test configurations using the t_walk_rtree to see what
TGTs would be needed.
(cd src/lib/krb5/krb; make t_walk_rtree)
For example using a krb5.conf with the above example shows:
setenv KRB5_CONFIG /tmp/dee.capath.conf
./t_walk_rtree RAEBURN.ORG SECURE-ENDPOINTS.COM
krbtgt/RAEBURN.ORG at RAEBURN.ORG
krbtgt/ATHENA.MIT.EDU at RAEBURN.ORG
krbtgt/DEMENTIA.ORG at ATHENA.MIT.EDU
krbtgt/SECURE-ENDPOINTS.COM at DEMENTIA.ORG
Without the SECURE-ENDPOINTS.COM = ATHENA.MIT.EDU line
it assumes that RAEBURN.ORG shares keys with DEMENTIA.ORG
./t_walk_rtree RAEBURN.ORG SECURE-ENDPOINTS.COM
krbtgt/RAEBURN.ORG at RAEBURN.ORG
krbtgt/DEMENTIA.ORG at RAEBURN.ORG
krbtgt/SECURE-ENDPOINTS.COM at DEMENTIA.ORG
>
> it seems that the code could infer that line from the previous
> DEMENTIA.ORG line.
It does not work that way today.
>
> I understand that having each path explicitly specified does provide
> more flexibility. But is this flexibility actually desirable?
I think the flexability is desirable. There are situations where two realms
share keys, and would not expect any other realms in a transited path. Yet
a client could get a TGT that would be on the default path.
Assume realms A, B ,C, D where A, B, and C all share keys,
and B and D share keys. So the expected path between A and C is direct.
But A to D would have B in the transited path.
User could get TGT for B at A, by going to D. The user could use the
B at A to get a C at B to get service ticket on C. This would then have B in the
transited field. But since A and C share keys, should this be considered an
attack? Maybe. A and C may only be sharing keys with B so they can get to D.
The end server has no way to know that A and C should never have B in the
transited field other the the capath code.
In your case I think it is needed, as the the code will fall back to using
the DNS based path code, and assume the path DEMENTIA.ORG to RAEBURN.ORG
exists.
>
> Comments in your original 1995 patch suggest that explicit path
> support was added.
Its been 9 years since I actually looked at this. It might be time
to rewrite the code. Note that 1510 was very vague about this,
yet to check the transited path, all the participants need to
agree on what realms can be on the path.
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444