[kitten] Updates to IAKERB (Re: Windows Intent to revive and implement) IAKerb draft-ietf-kitten-iakerb-03

[Nico Williams <[e-mail]>]

On Sat, Feb 18, 2023 at 04:56:24AM +0000, Steve Syfuhs (AP) wrote:
> You have captured the exact problem with unknown names. We can extend
> the protocol to solicit an SPN, and it turns out if you're willing to
> look the other way on good protocol manners, this can work today
> within spec. We just lose server auth. This *is* a net-win for
> security still, just not much of one.

OK, so what updates to IAKERB do you need?  If you want to stay
backwards-compatible then we can use the ASN.1 extensibility markers to
add fields to IAKERB-HEADER:

         IAKERB-HEADER ::= SEQUENCE {
             -- Note that the tag numbers start at 1, not 0, which would
             -- be more conventional for Kerberos.
             target-realm      [1] UTF8String,
                -- The name of the target realm.
             cookie            [2] OCTET STRING OPTIONAL,
                -- Opaque data, if sent by the server,
                -- MUST be copied by the client verbatim into
                -- the next IAKRB_PROXY message.
             ...,
             target-name       [3] KerberosPrincipal OPTIONAL,
             ...
         }

Set `target-name` to the empty name to request the acceptor's name (I
know, the empty name can be a legitimate name, but... it really
shouldn't be), and the acceptor should fill it in.

Or maybe:

         IAKERB-HEADER ::= SEQUENCE {
             -- Note that the tag numbers start at 1, not 0, which would
             -- be more conventional for Kerberos.
             target-realm      [1] UTF8String,
                -- The name of the target realm.
             cookie            [2] OCTET STRING OPTIONAL,
                -- Opaque data, if sent by the server,
                -- MUST be copied by the client verbatim into
                -- the next IAKRB_PROXY message.
             ...,
             target-name       [3] CHOICE {
                    request     [0] NULL, -- or BOOLEAN DEFAULT (TRUE)?
                    response    [1] KerberosPrincipal,
                    ...
             }
             ...
         }

if we really want to allow empty names as names.

While we're here we might as well also add a way for the acceptor to
return a TGT for user-to-user auth, why not, where the PDU following the
IAKERB-HEADER would be a Ticket:

         IAKERB-HEADER ::= SEQUENCE {
             -- Note that the tag numbers start at 1, not 0, which would
             -- be more conventional for Kerberos.
             target-realm      [1] UTF8String,
                -- The name of the target realm.
             cookie            [2] OCTET STRING OPTIONAL,
                -- Opaque data, if sent by the server,
                -- MUST be copied by the client verbatim into
                -- the next IAKRB_PROXY message.
             ...,
             target-name       [3] CHOICE {
                    request         [0] NULL,
                    user2user-ok    [1] NULL,
                    response        [2] KerberosPrincipal,
                    ...
             } OPTIONAL
             ...
         }

A request with `user2user-ok` would elicit either a response with the
name, or a response with a Ticket (which bears the name) for user2user.

Nico
--