logo_kerberos.gif

Projects/ConstrainedDelegation

From K5Wiki
< Projects
Revision as of 10:54, 22 October 2009 by Lukeh (talk | contribs) (New page: {{project-early}} ==Background== Whilst we've had constrained delegation support in the KDC since 1.7, it has required a proprietary backend that supports validating the Windows PAC. Thi...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


Background

Whilst we've had constrained delegation support in the KDC since 1.7, it has required a proprietary backend that supports validating the Windows PAC. This project provides a constrained delegation implementation that works without the PAC.

Architecture

In constrained delegation, the service passes the KDC a ticket from a user it has authenticated. There is nothing preventing it from forging this ticket. To avoid this attack, Windows verifies the TGS signature in the PAC.

Heimdal implements PAC-less constrained delegation by including an authorization data element containing a checksum over the ticket and delegation path in the TGS key:

KRB5-AUTHDATA-SIGNTICKET INTEGER ::= -17

KRB5SignedPathPrincipals ::= SEQUENCE OF Principal

-- never encoded on the wire, just used to checksum over
KRB5SignedPathData ::= SEQUENCE {
        encticket[0]    EncTicketPart,
        delegated[1]    KRB5SignedPathPrincipals OPTIONAL
}

KRB5SignedPath ::= SEQUENCE {
        -- DERcoded KRB5SignedPathData
        -- krbtgt key (etype), KeyUsage = XXX 
        etype[0]        ENCTYPE,
        cksum[1]        Checksum,
        -- srvs delegated though
        delegated[2]    KRB5SignedPathPrincipals OPTIONAL
}

The checksum is over KRB5SignedPathData, where encticket excludes the KRB5SignedPath authorization data. KRB5SignedPath is wrapped in AD-IF-RELEVANT (it is not relevant to services).

Implementation

CHECK_ALLOWED_TO_DELEGATE

We provide a CHECK_ALLOWED_TO_DELEGATE db_invoke callback for the LDAP backend that authorizes that target service against the krbAllowedToDelegateTo attribute. There is no support for administrating this attribute via kadmin, or for the DB2 backend.

Open issues

  • We could improve the efficiency by peeking inside AD containers instead of decoding them

Status

Code is in the users/lhoward/s4u2proxy branch.