Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v3]
On Tue, 10 Aug 2021 16:16:39 GMT, Weijun Wang wrote: >> The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that >> all these names are a bit confusing -but so it is the underlying protocol-. >> I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the >> hopes of suggesting some similarity between S4U2Proxy and S4U2Self and make >> it more clear-. Agree? > > Good! No more comment. Great, thanks. I'll mark this as 'Resolved conversation' and proceed with the push (unless there is any other formality that blocks me) - PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v3]
On Tue, 10 Aug 2021 14:48:08 GMT, Martin Balao wrote: >> Not adding the type is OK, I said it's just to be a little clearer. I think >> you're right about the cname. It's always the one that actually sends the >> request. >> >> What is "the TGS" (in "the TGS is the one")? `clientSvcTicketEnc`? BTW, is >> "client service ticket" a well known name? or we can name it >> "user"-something? > > The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that > all these names are a bit confusing -but so it is the underlying protocol-. > I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the > hopes of suggesting some similarity between S4U2Proxy and S4U2Self and make > it more clear-. Agree? Good! No more comment. - PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v3]
> I'd like to propose a fix for JDK-8270137 [1]. > > This bug is triggered when using a previously stored referral ticket (in the > Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral. > The mistakenly-used referral ticket matched the client and service names but > it was obtained as a result of a non-S4U2Proxy request. In fact, it was the > middle service that got it while trying to determine the backend service > realm in a previous S4U2Proxy communication. The mistakenly-used referral > ticket was not bind to the impersonated user (in other words, it was not > obtained attaching the user's TGS as part of a S4U2Proxy request) and, thus, > must not be used. > > Even when one possible approach to fix this issue could be to be more > selective at the moment of getting referral tickets from the Cache (that is: > do not get anything from the Cache if it's for a S4U2Proxy request), I > decided to go one step further and enhance the Referrals Cache. With this > enhancement, we add more information to the stored referral tickets such as a > footprint of the TGS (in the case of S4U2Proxy requests) or the user > principal (in the case of S4U2Self requests). We now allow to store S4U2Proxy > and S4U2Self referrals tickets but those will be re-used only if there is a > perfect match of the TGS or user principal. As an example, if a middle > service tries to replicate the exact S4U2Self communication for exactly the > same user, cached referral tickets should be okay. With this enhancement, we > increase the use of the Cache and the performance (time, network resources, > etc.). > > The ReferralsTest is enhanced to reflect these new scenarios and now uses > cached S4U2Proxy/S4U2Self referral tickets. > > No regressions observed in jdk/sun/security/krb5. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8270137 Martin Balao has updated the pull request incrementally with one additional commit since the last revision: clientSvcTicket* variables/parameters renamed to userSvcTicket* for clarity. - Changes: - all: https://git.openjdk.java.net/jdk/pull/5036/files - new: https://git.openjdk.java.net/jdk/pull/5036/files/4cb4b3e0..3e6f2db7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5036=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5036=01-02 Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5036.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5036/head:pull/5036 PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v2]
On Tue, 10 Aug 2021 14:08:24 GMT, Weijun Wang wrote: >> Hmm.. in my view, adding the S4U2Type to the key will provide not much value >> other than minor consistency checks (in the form of debug-mode assertions) >> because the assumptions that a key with a non-null 'user' value is of >> S4U2Self type and that a key with a non-null 'clientSvcTicketEnc' value is >> of S4U2Proxy type (as suggested next to the field decl) are safe. The key >> type will not be necessary to make a key unique. One more comment to clarify >> just in case. The clientSvcTicketEnc value is somehow related to the other >> values in the key but it's not a 1 to 1 field mapping. This is because the >> TGS is the one that the user-to-be-impersonated sent to the middle service; >> whilst the cname and sname are related to a middle service ticket. If I'm >> correct, the cname in the key should match the client service ticket sname >> (both of them being the middle service name). > > Not adding the type is OK, I said it's just to be a little clearer. I think > you're right about the cname. It's always the one that actually sends the > request. > > What is "the TGS" (in "the TGS is the one")? `clientSvcTicketEnc`? BTW, is > "client service ticket" a well known name? or we can name it "user"-something? The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that all these names are a bit confusing -but so it is the underlying protocol-. I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the hopes of suggesting some similarity between S4U2Proxy and S4U2Self and make it more clear-. Agree? - PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v2]
> I'd like to propose a fix for JDK-8270137 [1]. > > This bug is triggered when using a previously stored referral ticket (in the > Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral. > The mistakenly-used referral ticket matched the client and service names but > it was obtained as a result of a non-S4U2Proxy request. In fact, it was the > middle service that got it while trying to determine the backend service > realm in a previous S4U2Proxy communication. The mistakenly-used referral > ticket was not bind to the impersonated user (in other words, it was not > obtained attaching the user's TGS as part of a S4U2Proxy request) and, thus, > must not be used. > > Even when one possible approach to fix this issue could be to be more > selective at the moment of getting referral tickets from the Cache (that is: > do not get anything from the Cache if it's for a S4U2Proxy request), I > decided to go one step further and enhance the Referrals Cache. With this > enhancement, we add more information to the stored referral tickets such as a > footprint of the TGS (in the case of S4U2Proxy requests) or the user > principal (in the case of S4U2Self requests). We now allow to store S4U2Proxy > and S4U2Self referrals tickets but those will be re-used only if there is a > perfect match of the TGS or user principal. As an example, if a middle > service tries to replicate the exact S4U2Self communication for exactly the > same user, cached referral tickets should be okay. With this enhancement, we > increase the use of the Cache and the performance (time, network resources, > etc.). > > The ReferralsTest is enhanced to reflect these new scenarios and now uses > cached S4U2Proxy/S4U2Self referral tickets. > > No regressions observed in jdk/sun/security/krb5. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8270137 Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Variable renaming for clarity and unused parameter removed. - Changes: - all: https://git.openjdk.java.net/jdk/pull/5036/files - new: https://git.openjdk.java.net/jdk/pull/5036/files/4260067e..4cb4b3e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5036=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5036=00-01 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5036.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5036/head:pull/5036 PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup
On Tue, 10 Aug 2021 13:45:22 GMT, Martin Balao wrote:
>> src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java
>> line 59:
>>
>>> 57: private byte[] clientSvcTicketEnc; // S4U2Proxy only
>>> 58: ReferralCacheKey (PrincipalName cname, PrincipalName sname,
>>> 59: PrincipalName user, Ticket clientSvcTicket) {
>>
>> It's probably not necessary, but I somehow feel it will be clearer to add
>> S4U2Type into the key. In fact, with all these info it almost looks like the
>> key contains everything in a TGS-REQ (except for the timestamp maybe).
>
> Hmm.. in my view, adding the S4U2Type to the key will provide not much value
> other than minor consistency checks (in the form of debug-mode assertions)
> because the assumptions that a key with a non-null 'user' value is of
> S4U2Self type and that a key with a non-null 'clientSvcTicketEnc' value is of
> S4U2Proxy type (as suggested next to the field decl) are safe. The key type
> will not be necessary to make a key unique. One more comment to clarify just
> in case. The clientSvcTicketEnc value is somehow related to the other values
> in the key but it's not a 1 to 1 field mapping. This is because the TGS is
> the one that the user-to-be-impersonated sent to the middle service; whilst
> the cname and sname are related to a middle service ticket. If I'm correct,
> the cname in the key should match the client service ticket sname (both of
> them being the middle service name).
Not adding the type is OK, I said it's just to be a little clearer. I think
you're right about the cname. It's always the one that actually sends the
request.
What is "the TGS" (in "the TGS is the one")? `clientSvcTicketEnc`? BTW, is
"client service ticket" a well known name? or we can name it "user"-something?
-
PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup
On Mon, 9 Aug 2021 19:54:21 GMT, Weijun Wang wrote:
>> I'd like to propose a fix for JDK-8270137 [1].
>>
>> This bug is triggered when using a previously stored referral ticket (in the
>> Referrals Cache) at the moment of following a S4U2Proxy cross-realm
>> referral. The mistakenly-used referral ticket matched the client and service
>> names but it was obtained as a result of a non-S4U2Proxy request. In fact,
>> it was the middle service that got it while trying to determine the backend
>> service realm in a previous S4U2Proxy communication. The mistakenly-used
>> referral ticket was not bind to the impersonated user (in other words, it
>> was not obtained attaching the user's TGS as part of a S4U2Proxy request)
>> and, thus, must not be used.
>>
>> Even when one possible approach to fix this issue could be to be more
>> selective at the moment of getting referral tickets from the Cache (that is:
>> do not get anything from the Cache if it's for a S4U2Proxy request), I
>> decided to go one step further and enhance the Referrals Cache. With this
>> enhancement, we add more information to the stored referral tickets such as
>> a footprint of the TGS (in the case of S4U2Proxy requests) or the user
>> principal (in the case of S4U2Self requests). We now allow to store
>> S4U2Proxy and S4U2Self referrals tickets but those will be re-used only if
>> there is a perfect match of the TGS or user principal. As an example, if a
>> middle service tries to replicate the exact S4U2Self communication for
>> exactly the same user, cached referral tickets should be okay. With this
>> enhancement, we increase the use of the Cache and the performance (time,
>> network resources, etc.).
>>
>> The ReferralsTest is enhanced to reflect these new scenarios and now uses
>> cached S4U2Proxy/S4U2Self referral tickets.
>>
>> No regressions observed in jdk/sun/security/krb5.
>>
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8270137
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java
> line 59:
>
>> 57: private byte[] clientSvcTicketEnc; // S4U2Proxy only
>> 58: ReferralCacheKey (PrincipalName cname, PrincipalName sname,
>> 59: PrincipalName user, Ticket clientSvcTicket) {
>
> It's probably not necessary, but I somehow feel it will be clearer to add
> S4U2Type into the key. In fact, with all these info it almost looks like the
> key contains everything in a TGS-REQ (except for the timestamp maybe).
Hmm.. in my view, adding the S4U2Type to the key will provide not much value
other than minor consistency checks (in the form of debug-mode assertions)
because the assumptions that a key with a non-null 'user' value is of S4U2Self
type and that a key with a non-null 'clientSvcTicketEnc' value is of S4U2Proxy
type (as suggested next to the field decl) are safe. The key type will not be
necessary to make a key unique. One more comment to clarify just in case. The
clientSvcTicketEnc value is somehow related to the other values in the key but
it's not a 1 to 1 field mapping. This is because the TGS is the one that the
user-to-be-impersonated sent to the middle service; whilst the cname and sname
are related to a middle service ticket. If I'm correct, the cname in the key
should match the client service ticket sname (both of them being the middle
service name).
-
PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup
On Mon, 9 Aug 2021 19:48:24 GMT, Weijun Wang wrote: >> I'd like to propose a fix for JDK-8270137 [1]. >> >> This bug is triggered when using a previously stored referral ticket (in the >> Referrals Cache) at the moment of following a S4U2Proxy cross-realm >> referral. The mistakenly-used referral ticket matched the client and service >> names but it was obtained as a result of a non-S4U2Proxy request. In fact, >> it was the middle service that got it while trying to determine the backend >> service realm in a previous S4U2Proxy communication. The mistakenly-used >> referral ticket was not bind to the impersonated user (in other words, it >> was not obtained attaching the user's TGS as part of a S4U2Proxy request) >> and, thus, must not be used. >> >> Even when one possible approach to fix this issue could be to be more >> selective at the moment of getting referral tickets from the Cache (that is: >> do not get anything from the Cache if it's for a S4U2Proxy request), I >> decided to go one step further and enhance the Referrals Cache. With this >> enhancement, we add more information to the stored referral tickets such as >> a footprint of the TGS (in the case of S4U2Proxy requests) or the user >> principal (in the case of S4U2Self requests). We now allow to store >> S4U2Proxy and S4U2Self referrals tickets but those will be re-used only if >> there is a perfect match of the TGS or user principal. As an example, if a >> middle service tries to replicate the exact S4U2Self communication for >> exactly the same user, cached referral tickets should be okay. With this >> enhancement, we increase the use of the Cache and the performance (time, >> network resources, etc.). >> >> The ReferralsTest is enhanced to reflect these new scenarios and now uses >> cached S4U2Proxy/S4U2Self referral tickets. >> >> No regressions observed in jdk/sun/security/krb5. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8270137 > > src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java > line 90: > >> 88: Credentials creds = serviceCreds( >> 89: KDCOptions.with(KDCOptions.FORWARDABLE), >> 90: ccreds, ccreds.getClient(), sname, client, > > How about we rename `client` to `user` here? Yes, makes sense to me. Will change it > src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java > line 496: > >> 494: */ >> 495: private static void handleS4U2SelfReferral(PAData[] pas, >> 496: PrincipalName user, Credentials oldCeds, Credentials >> newCreds) > > `oldCreds` is useless now. Right - PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup
On Fri, 6 Aug 2021 19:27:30 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8270137 [1].
>
> This bug is triggered when using a previously stored referral ticket (in the
> Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral.
> The mistakenly-used referral ticket matched the client and service names but
> it was obtained as a result of a non-S4U2Proxy request. In fact, it was the
> middle service that got it while trying to determine the backend service
> realm in a previous S4U2Proxy communication. The mistakenly-used referral
> ticket was not bind to the impersonated user (in other words, it was not
> obtained attaching the user's TGS as part of a S4U2Proxy request) and, thus,
> must not be used.
>
> Even when one possible approach to fix this issue could be to be more
> selective at the moment of getting referral tickets from the Cache (that is:
> do not get anything from the Cache if it's for a S4U2Proxy request), I
> decided to go one step further and enhance the Referrals Cache. With this
> enhancement, we add more information to the stored referral tickets such as a
> footprint of the TGS (in the case of S4U2Proxy requests) or the user
> principal (in the case of S4U2Self requests). We now allow to store S4U2Proxy
> and S4U2Self referrals tickets but those will be re-used only if there is a
> perfect match of the TGS or user principal. As an example, if a middle
> service tries to replicate the exact S4U2Self communication for exactly the
> same user, cached referral tickets should be okay. With this enhancement, we
> increase the use of the Cache and the performance (time, network resources,
> etc.).
>
> The ReferralsTest is enhanced to reflect these new scenarios and now uses
> cached S4U2Proxy/S4U2Self referral tickets.
>
> No regressions observed in jdk/sun/security/krb5.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8270137
Looks fine. Some small comments.
src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java
line 90:
> 88: Credentials creds = serviceCreds(
> 89: KDCOptions.with(KDCOptions.FORWARDABLE),
> 90: ccreds, ccreds.getClient(), sname, client,
How about we rename `client` to `user` here?
src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java
line 496:
> 494: */
> 495: private static void handleS4U2SelfReferral(PAData[] pas,
> 496: PrincipalName user, Credentials oldCeds, Credentials
> newCreds)
`oldCreds` is useless now.
src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java
line 59:
> 57: private byte[] clientSvcTicketEnc; // S4U2Proxy only
> 58: ReferralCacheKey (PrincipalName cname, PrincipalName sname,
> 59: PrincipalName user, Ticket clientSvcTicket) {
It's probably not necessary, but I somehow feel it will be clearer to add
S4U2Type into the key. In fact, with all these info it almost look like the key
contains everything in a TGS-REQ (except for the timestamp maybe).
-
Marked as reviewed by weijun (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5036
Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup
On Fri, 6 Aug 2021 19:27:30 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8270137 [1]. > > This bug is triggered when using a previously stored referral ticket (in the > Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral. > The mistakenly-used referral ticket matched the client and service names but > it was obtained as a result of a non-S4U2Proxy request. In fact, it was the > middle service that got it while trying to determine the backend service > realm in a previous S4U2Proxy communication. The mistakenly-used referral > ticket was not bind to the impersonated user (in other words, it was not > obtained attaching the user's TGS as part of a S4U2Proxy request) and, thus, > must not be used. > > Even when one possible approach to fix this issue could be to be more > selective at the moment of getting referral tickets from the Cache (that is: > do not get anything from the Cache if it's for a S4U2Proxy request), I > decided to go one step further and enhance the Referrals Cache. With this > enhancement, we add more information to the stored referral tickets such as a > footprint of the TGS (in the case of S4U2Proxy requests) or the user > principal (in the case of S4U2Self requests). We now allow to store S4U2Proxy > and S4U2Self referrals tickets but those will be re-used only if there is a > perfect match of the TGS or user principal. As an example, if a middle > service tries to replicate the exact S4U2Self communication for exactly the > same user, cached referral tickets should be okay. With this enhancement, we > increase the use of the Cache and the performance (time, network resources, > etc.). > > The ReferralsTest is enhanced to reflect these new scenarios and now uses > cached S4U2Proxy/S4U2Self referral tickets. > > No regressions observed in jdk/sun/security/krb5. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8270137 Thanks for your effort. We tested this patch on our internal environment and it works fine. It definetly makes sense to store Proxy tickets in the cache to reduce network load instead of our proposed "do not use cache for Proxy tickets" approach. - PR: https://git.openjdk.java.net/jdk/pull/5036
RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup
I'd like to propose a fix for JDK-8270137 [1]. This bug is triggered when using a previously stored referral ticket (in the Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral. The mistakenly-used referral ticket matched the client and service names but it was obtained as a result of a non-S4U2Proxy request. In fact, it was the middle service that got it while trying to determine the backend service realm in a previous S4U2Proxy communication. The mistakenly-used referral ticket was not bind to the impersonated user (in other words, it was not obtained attaching the user's TGS as part of a S4U2Proxy request) and, thus, must not be used. Even when one possible approach to fix this issue could be to be more selective at the moment of getting referral tickets from the Cache (that is: do not get anything from the Cache if it's for a S4U2Proxy request), I decided to go one step further and enhance the Referrals Cache. With this enhancement, we add more information to the stored referral tickets such as a footprint of the TGS (in the case of S4U2Proxy requests) or the user principal (in the case of S4U2Self requests). We now allow to store S4U2Proxy and S4U2Self referrals tickets but those will be re-used only if there is a perfect match of the TGS or user principal. As an example, if a middle service tries to replicate the exact S4U2Self communication for exactly the same user, cached referral tickets should be okay. With this enhancement, we increase the use of the Cache and the performance (time, network resources, etc.). The ReferralsTest is enhanced to reflect these new scenarios and now uses cached S4U2Proxy/S4U2Self referral tickets. No regressions observed in jdk/sun/security/krb5. -- [1] - https://bugs.openjdk.java.net/browse/JDK-8270137 - Commit messages: - 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup Changes: https://git.openjdk.java.net/jdk/pull/5036/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5036=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270137 Stats: 89 lines in 3 files changed: 47 ins; 9 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5036.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5036/head:pull/5036 PR: https://git.openjdk.java.net/jdk/pull/5036
