Subject: [kitten] Clarification on draft-williams-kitten-krb5-pkcross-02

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Tue, 10 Jun 2014 02:02:38 +0000

Moving this here because it seemed more appropriate.

On the [email-masked]<mailto:[email-masked]> list, Nico said:

my idea is to use TGS anyways, but with a PKINIT pre-auth instead of PA-TGS, and with a "cross-realm"
certificate

But in the draft I see that step 4 of the protocol is:

Request a TGT from the destination realm using PKINIT [RFC4556<http://tools.ietf.org/html/rfc4556>].

The draft seems to be saying to me that Step 4 is to initiate an AS exchange with the destination realm using PKINIT. If I understand your comment correctly, the crux of your idea is to have the client initiate a TGS exchange with the destination realm using alternative padata. Can you clarify this situation for me? :)

Thanks,
Bryce

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Jun 2014 21:45:35 -0500

On Mon, Jun 9, 2014 at 9:02 PM, Nordgren, Bryce L -FS
<[email-masked]> wrote:
> The draft seems to be saying to me that Step 4 is to initiate an AS exchange
> with the destination realm using PKINIT. If I understand your comment
> correctly, the crux of your idea is to have the client initiate a TGS
> exchange with the destination realm using alternative padata. Can you
> clarify this situation for me? J

As I wrote the I-D you'd use an AS exchange, but I do believe a TGS
would be better, if only because it'd be weird to have an AS-REP issue
a non-INITIAL ticket or a ticket with non-empty transit path, or a
ticket for client and service principals with different realms.  But,
really, aside from that, the choice of PA, and the outermost tag, (and
any other nit-y things I might be forgetting) the two KDC exchanges
are the same.

The thing to expect is that the KDC recognizes the request as a
PKCROSS request because it uses PKINIT pre-auth with a client cert
from an issuer a) not corresponding to any of the KDC's realms, b) for
which the KDC can work out a realm name [see below] or which has a
Kerberos name SAN that the KDC can authorize the issuer to.  The the
KDC would figure out the client principal's realm name and the transit
path, and write it all into a non-INITIAL ticket.

For the transit path we already have "X.500 style" realm naming and
transit path compression.  For the client principal's realm name we
could also use an X.500 style realm name if a DOMAIN style realm name
cannot be figured out.

This should be straightforward to implement, except for the part about
X.500 style realm naming: I doubt any current Kerberos implementation
has support for it, the transit path compression part in particular.
Note that libraries too need X.500 style realm naming support for
transit path validation -- I have not looked at what this takes, but
it might be easy as long as you don't expect hierarchical transit path
support for X.500.  Mapping DNs to DOMAIN style names would be best
whenever possible, but this requires having decent trust anchors.
(I'm assuming that PKINIT implementations already check that only
configured issuers are permitted to issue certs for the realm's client
principals.)

Finally, we should want an option for stuffing the entire cert (and
cert chain) into an authz-data element of the issued ticket, possibly
at the KDC's discretion, possibly at the client's request.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 09 Jun 2014 23:41:42 -0400

On 06/09/2014 10:45 PM, Nico Williams wrote:
> ticket for client and service principals with different realms.

The TGS-REQ path is already too complicated.  The KDC already has to
deal with at least five cases:

1. Traditional TGS requests to get a service ticket using a TGT
2. Ticket modification requests (of TGTs or service tickets)
3. User-to-user authentication (session key from second ticket)
4. S4U2Self (issue ticket for client specified by padata)
5. S4U2Proxy (issue ticket for client specified by second ticket)

Cases 4 and 5 aren't the IETF's doing, of course, but that doesn't mean
we can reasonably avoid supporting them.  I'd probably rather add a
third type of KDC request than add a sixth variant of TGS which uses the
AS-REQ preauth machinery and doesn't use a header ticket.  (An AS-REQ
variant might still be a reasonable option; I haven't reviewed the draft
in enough detail to have a strong opinion about that.)

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Jun 2014 23:03:50 -0500

On Mon, Jun 9, 2014 at 10:41 PM, Greg Hudson <[email-masked]> wrote:
> ...

I find adding a new request type that will differ mostly only as to
the application tag and pre-auth choice a bit silly.  There's a cost
to it too: dissectors for things like Wireshark and Netmon won't know
about the new requests, even though the new request will be so like
the old.

The main reason to separate these at all is for separation of
services, which for Kerberos is really mostly about class of service /
load balancing -- give higher priority to TGS requests than to PKINIT.
TGS requests are usually fast: it's all symmetric key crypto, while
PKINIT AS requests are slower due to the PK crypto.

At a high-level we have:

 - has PA-TGS -> TGS
 - has x-realm PKINIT -> new thing
 - anything else -> AS

Separation of service should have been done by using [optionally]
different port numbers, not different tag numbers.

Thinking of it this way this, I'd rather use AS for this and not a new
request type, due a) to the fact that we already have slow AS
requests, but not slow TGS requests, b) AS req

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Jun 2014 23:06:56 -0500

Sent too soon.  To complete that sentence:

Thinking of it this way this, I'd rather use AS for this and not a new
request type, due a) to the fact that we already have slow AS
requests, but not slow TGS requests, b) AS requests are generally less
frequent than TGS requests, c) I'd rather not have to update
dissectors for Wireshark, snoop, tcpdump, Netmon, and so on.
[Ab]Using AS for this means we can more easily separate class of
service.

We should still have different SRV RRset labels for each service (AS,
TGS, PKCROSS).

Nico
--