Difference between revisions of "Projects/SignedPathNamingExts"
(New page: {{project-rel|1.9}} ==Background== Implement a mechanism for exposing the constrained delegation transited services path via GSS naming extensions. ==Architecture== ==Implementation== ...) |
|||
| Line 3: | Line 3: | ||
==Background== |
==Background== |
||
| − | Implement a mechanism for exposing the constrained delegation |
+ | Implement a mechanism for exposing the constrained delegation path via GSS naming extensions. |
==Architecture== |
==Architecture== |
||
| Line 12: | Line 12: | ||
No support for the transited services encoding in [MS-PAC] is yet provided, because that would require an NDR interpreter within the krb5 runtime. This would be more suitably implemented as a third-party plugin. |
No support for the transited services encoding in [MS-PAC] is yet provided, because that would require an NDR interpreter within the krb5 runtime. This would be more suitably implemented as a third-party plugin. |
||
| + | |||
| + | ==Open issues== |
||
| + | |||
| + | It's impossible to mark this attribute as authenticated because the delegation path is signed with the TGS key, which the GSS acceptor does not have. A KDC that supports KRB5_AUTHDATA_SIGNTICKET will reject such user-submitted authorization data, but the acceptor has no in-band knowledge of what kind of KDC issued the ticket. |
||
| + | |||
| + | Interestingly this would not be an issue with the [MS-PAC] delegation path, because it is also signed with the acceptor key. |
||
==Status== |
==Status== |
||
Revision as of 12:27, 8 May 2010
Background
Implement a mechanism for exposing the constrained delegation path via GSS naming extensions.
Architecture
Implementation
A new authorization data naming extensions backend is added in src/lib/krb5/krb/s4u_authdata.c. This maps the "delegated" member of krb5_ad_signedpath (KRB5_AUTHDATA_SIGNTICKET) to the urn:constrained-delegation:transited-services attribute.
No support for the transited services encoding in [MS-PAC] is yet provided, because that would require an NDR interpreter within the krb5 runtime. This would be more suitably implemented as a third-party plugin.
Open issues
It's impossible to mark this attribute as authenticated because the delegation path is signed with the TGS key, which the GSS acceptor does not have. A KDC that supports KRB5_AUTHDATA_SIGNTICKET will reject such user-submitted authorization data, but the acceptor has no in-band knowledge of what kind of KDC issued the ticket.
Interestingly this would not be an issue with the [MS-PAC] delegation path, because it is also signed with the acceptor key.
Status
Code is in the users/lhoward/signedpath-naming-exts branch.
