Difference between revisions of "Projects/ConstrainedDelegation"

Revision as of 11:30, 22 October 2009

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

libkrb5

New types and encoders are added for the delegation path. Unfortunately, the ASN.1 library appears to have forced the use of a container type for a SEQUENCE of principals.

typedef struct _krb5_delegatee {
    krb5_principal principal;
} krb5_delegatee;

typedef struct _krb5_ad_signedpath_data {
    krb5_enc_tkt_part enc_tkt_part;
    krb5_delegatee **delegated;
} krb5_ad_signedpath_data;

typedef struct _krb5_ad_signedpath {
    krb5_enctype enctype;
    krb5_checksum checksum;
    krb5_delegatee **delegated;
} krb5_ad_signedpath;

Note: krb5_ad_signedpath_data represents data to be checksummed, krb5_ad_signedpath is what is actually encoded and sent on the wire. The enctype field in the latter is a hint to which TGS key to use, but presently this is unused in our implementation.

Constants are added for the signed path AD type and the checksum key usage:

#define KRB5_KEYUSAGE_AD_SIGNEDPATH            -21
#define KRB5_AUTHDATA_SIGNTICKET    -17

I have kept this aligned with Heimdal so that, when using the HDB bridge, a mixed realm of Heimdal and MIT KDCs should interoperate with constrained delegation.

KDC

Note: some changes were imported from the HDBBridge branch to speed implementation.

Changes are briefly summarised as follows:

• We now correctly filter out known KDC issued AD elements when copying authorization data from the TGT.
• A new authdata handler, handle_signedpath_authdata(), is added, which supports the verification and generation of the signed data path. We assert this is last in the list of handlers, because the checksum validation algorithm requires the last element in the ticket authorization data to be the signed path.
• The authorization data handlers are now called immediately before the ticket is encrypted, for the purpose of checksumming.

Apart from that, we're fortunate that the authorization data handler interface is sufficiently flexible to avoid any other changes to the KDC.

KDB

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
• What is the interaction of the ticket checksumming with FAST?

Status

Code is in the users/lhoward/s4u2proxy branch.