| Subject: | KDC-REQ-BODY server name isn't optional for user-to-user TGS requests |
Per RFC 4120 section 5.4.1, the KDC-REQ-BODY sname field is optional
and "may only be absent when the ENC-TKT-IN-SKEY option is specified.
If the sname is absent, the name of the server is taken from the name
of the client in the ticket passed as additional-tickets." The realm
field (applying to both cname and sname) is mandatory.
If the sname is omitted in an incoming KDC-REQ-BODY for a TGS
request, our ASN.1 decoder hack (decode_kdc_req_body) throws out the
realm (or applies it to the client if one is present, but for a TGS
request it generally won't be). This makes it hard to set up the KDC
realm state; we could pull the realm from second_ticket[0]->server-
process_tgs_req(), because request->server is NULL and that causes
setup_server_realm() to return NULL.
It is not clear that we need to fix this problem. Fixing it would be
somewhat difficult, because we would have to figure out how to
preserve the kdc-req-body realm field in a kdc_req structure with no
client and no server. It would also be somewhat risky, as there are
at least 28 uses of request->server in the KDC code and many of them
don't handle null values.
and "may only be absent when the ENC-TKT-IN-SKEY option is specified.
If the sname is absent, the name of the server is taken from the name
of the client in the ticket passed as additional-tickets." The realm
field (applying to both cname and sname) is mandatory.
If the sname is omitted in an incoming KDC-REQ-BODY for a TGS
request, our ASN.1 decoder hack (decode_kdc_req_body) throws out the
realm (or applies it to the client if one is present, but for a TGS
request it generally won't be). This makes it hard to set up the KDC
realm state; we could pull the realm from second_ticket[0]->server-
Show quoted text
>realm but we would be omitting a sanity check to do so. At present
we fail just after the call to setup_server_realm() in process_tgs_req(), because request->server is NULL and that causes
setup_server_realm() to return NULL.
It is not clear that we need to fix this problem. Fixing it would be
somewhat difficult, because we would have to figure out how to
preserve the kdc-req-body realm field in a kdc_req structure with no
client and no server. It would also be somewhat risky, as there are
at least 28 uses of request->server in the KDC code and many of them
don't handle null values.