Re-read [capaths]

Discovery

[capaths] does not have the same meaning in JDK and the rest of the world (See references at the bottom).

In JDK, each line describes a relation and one needs to consult multiple relations to create a path. In the rest of the world, each line itself is a path.

So, suppose shared keys are between A and B, B and C, and, C and D. For a client in A, in order to visit a service in D, it needs A -> B -> C -> D.

In JDK, the capaths is written as

A = {
   B = .     # I can go B directly
   C = B     # To go C, I need to go B first
   D = C     # To go D, I need to go C first
}

In the rest of the world, it's

A = {
   B = .    # I can go B directly
   C = B    # To go C, I need to go B. Done
   D = B C  # To go D, I need to go B and then C. Done
}

and the last line is often written into multiple lines

D = B
D = C

although this becomes not so clear.

Difference

When a sub-tag has multiple values (either on a single line or multiple lines), it is interpreted differently.

A = {
   B = C D
}

• For the rest of the world, it's a series of realms that the client needs to walk thru to the server. The client in A needs to go to C and then D to reach B
• For Java, it's a list of alternatives that can lead to the server. In order for a client A to go to B, it must reach C or D first.

and the Java way is wrong.

Fix

There will be a behavior change anyway, but we must preserve as much as we can. That is to say, if there are no sub-tags with multiple values, we should still be able to recognize our old format. If there are, we should treat it correctly like the rest of the world.

Here is a way to unify the two different designs. For

cRealm = {
   sRealm = A ... B
}

"A ... B" should be regarded as a (possibly partial) path from cRealm to sRealm.

The key point here is the "possibly partial" modifier. By partial, it means the path could be only the tail, i.e. you need to find zero or more realms "C ... D" to build the full path "C ... D A ... B", where C directly shares keys with cRealm.

Now, the rest of the world always gives the full path, and JDK gives the shortest-available partial path. Unified.

How to build the full path then? Given the previous example

A = {
   B = .     # I can go B directly
   C = B     # To go C, I need to go B first
   D = C     # To go D, I need to go C first
}

From D = C, we get partial path for A to D as C -> D. Here A cannot directly go to C, so we start building. We have C = B, we have a partial path for A to C as B -> C. Merging the partial paths give a longer path from A to D being B -> C -> D. B = . shows B is a direct link, and we have the full path.

There are still some rules:

1. . can only appear in a single-valued sub-tag
2. No loops
3. No dups in multiple values of the same subtag
4. Neither cRealm nor sRealm can appear in path

If any rule is broken, the output is undefined. The current implementation is that the value is ignored.

And, the Hierarchy Case

The hierarchy algorithm is also wrong: When two realms have completely no common components, Java now regards it as a direct link. However, the correct path should go down to the last component of cRealm, and then go up from the last component of sRealm to the full sRealm.

For example, a path from A.COM to B.ORG will be A.COM -> COM -> ORG -> B.ORG.

References

• http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/capaths.html
• https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Setting_Up_Cross_Realm_Authentication.html