Subject: [kitten] Authentication indicator - Do we need client indicator ?

From: Simo Sorce <[email-masked]>
Date: Wed, 18 Feb 2015 10:56:55 -0500

Reading the draft I am wondering if we also need a "Client Indicator"
Auth Data definition (in this draft or a separate draft).

In AD-CAMMAC we mention that if the KDC want to make sure to bind the
CAMMAC to a specific client principal, then this need to be done with
data embedded into an AD within CAMMAC, but in AD-CAMMAC we specify no
AD type to do that.

I had not thought that we'd care about this binding in Auth Indicator
work, but I see S4U2Proxy is mentioned there, so perhaps we actually
do ?

Would it be bad to define a new AD-CLIENT-INDICATOR data type as part of
this RFC ?

The AD would be defined as:
 AD-CLIENT-INDICATOR ::= SEQUENCE {
	principal 	[0] PrincipalName
	realm		[1] Realm
}

The client indicator would be optional, but if it is included in a
CAMMAC the KDC MUST verify that the client in the ticket including the
CAMMAC matches the indicator.

The AD Auth indicator security considerations would mention that if
support for things like S4U2Proxy is desired and no other AD element in
the CAMMAC ties the CAMMAC to a specific principal, then
AD_CLIENT_INDICATOR SHOULD be used, and the KDC SHOULD deny a S4U2
operation (or perhaps simply omit the CAMMAC from the resulting ticket)
if AD-CLIENT-INDICATOR is missing.

Comments ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Greg Hudson <[email-masked]>
Date: Wed, 18 Feb 2015 11:14:05 -0500

> data embedded into an AD within CAMMAC, but in AD-CAMMAC we specify no

CAMMACs are already bound to a client principal name.  You are probably
thinking of the final paragraph of the security considerations, which
refers to the service principal name.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 18 Feb 2015 11:21:58 -0500

> refers to the service principal name.

Doh! Ok, and Auth Indicator doesn't care about Service Principal Names.

So ... nevermind :)

Simo.