View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009465 | 10000-004: Services | Spec | public | 2024-03-13 09:52 | 2024-04-09 16:05 |
Reporter | Bernd Edlinger | Assigned To | Matthias Damm | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | reopened | ||
Product Version | 1.05.03 | ||||
Fixed in Version | 1.05.04 RC1 | ||||
Summary | 0009465: Incompatible Spec changes regarding RsaEncryptedSecret | ||||
Description | Previously the 1.05 spec chapter "The legacy token secret format defined in 7.41.2.2 is not extensible and provides only encryption but the encrypted data is not signed. It is used together with the USERNAME UserIdentityToken. The password secret exchanged with this format shall not exceed 64 bytes. The EncryptedSecret format defined in 7.41.2.3 provides an extensible secret format together with the definition how the secret is signed and encrypted. It allows for the layout to be updated as new token types are defined or new SecurityPolicies are added." But that was changed recently and looks now like this: "The legacy token secret format defined in 7.41.2.2 is not extensible and provides only encryption but the encrypted data is not signed. If the password exceeds 64 bytes, the EncryptedSecret format shall be used or the clear text password is sent over a SecureChannel that is encrypted. The EncryptedSecret format defined in 7.41.2.3 provides an extensible secret format together with the definition how the secret is signed and encrypted. It allows for the layout to be updated as new token types are defined or new SecurityPolicies are added. The EncryptedSecret format starts with a TypeId, EncodingMask and Length. These values allow a Server to determine how to handle the secret. If these fields are not valid and a USERNAME UserIdentityToken has been provided then the Server may attempt to handle the secret using the legacy token secret format. If these fields are valid but the TypeId is not recognized or not valid for the SecurityPolicy then the Server rejects the UserIdentityToken. " But this is not a good idea, to try to parse the legacy token as it it was a EncryptedSecret because the data is encrypted and might | ||||
Tags | No tags attached. | ||||
Commit Version | 1.05.04 RC | ||||
Fix Due Date | |||||
|
There is no breaking change, only a clarification. The following sentence for legacy token secret format was always in the spec: One of the reasons for introducing the EncryptedSecret was an issue with passwords exceeding the size of 65 bytes. The additional clarifications just define when to use the legacy and when the EncryptedSecret format and how a server can check for the difference. |
|
Okay, I see. |
|
We discussed in Dallas F2F. The non-encrypted case requires a specific byte to be zero followed by a length that must match of the blob. This makes it extremely unlikely that these two payload forms will be confused. In the worst case both formats can be assumed and tried. Agreed to no-fix. |
|
Agreed to no-fix in Dallas F2F. |
|
I got a further request for clarification. It is very likely that the TypeId resolves to a valid NodeId but not a NodeId for the two supported encryption types. |
|
From the wording of the spec I only read there must be a length. |
|
Well, am I right that the 64-byte password limit has the purpose to avoid So we know that a ligitimate Legacy Secret has exactly the length Wouldn't that allow a bullet-proof detection of the encryption format? |
|
Updated text to: |
|
Agreed to changes in web meeting. |
Date Modified | Username | Field | Change |
---|---|---|---|
2024-03-13 09:52 | Bernd Edlinger | New Issue | |
2024-03-18 05:11 | Matthias Damm | Assigned To | => Matthias Damm |
2024-03-18 05:11 | Matthias Damm | Status | new => resolved |
2024-03-18 05:11 | Matthias Damm | Resolution | open => no change required |
2024-03-18 05:11 | Matthias Damm | Note Added: 0020927 | |
2024-03-18 11:42 | Bernd Edlinger | Status | resolved => feedback |
2024-03-18 11:42 | Bernd Edlinger | Resolution | no change required => reopened |
2024-03-18 11:42 | Bernd Edlinger | Note Added: 0020928 | |
2024-03-19 22:12 | Jim Luth | Note Added: 0020952 | |
2024-03-19 22:13 | Jim Luth | Status | feedback => resolved |
2024-03-19 22:13 | Jim Luth | Resolution | reopened => no change required |
2024-03-19 22:13 | Jim Luth | Note Added: 0020953 | |
2024-03-19 22:13 | Jim Luth | Status | resolved => closed |
2024-03-21 12:20 | Matthias Damm | Status | closed => feedback |
2024-03-21 12:20 | Matthias Damm | Resolution | no change required => reopened |
2024-03-21 12:20 | Matthias Damm | Note Added: 0020993 | |
2024-03-27 10:10 | Bernd Edlinger | Note Added: 0021045 | |
2024-03-27 10:10 | Bernd Edlinger | Status | feedback => assigned |
2024-03-28 07:01 | Bernd Edlinger | Note Added: 0021068 | |
2024-04-09 16:05 | Matthias Damm | Status | assigned => resolved |
2024-04-09 16:05 | Matthias Damm | Fixed in Version | => 1.05.04 RC1 |
2024-04-09 16:05 | Matthias Damm | Note Added: 0021098 | |
2024-04-09 16:05 | Jim Luth | Status | resolved => closed |
2024-04-09 16:05 | Jim Luth | Commit Version | => 1.05.04 RC |
2024-04-09 16:05 | Jim Luth | Note Added: 0021099 |