PKINIT and instance principals.

[Dr. Greg Wettstein]

Good morning, I hope this note finds everyone's day going well.

We wanted to bounce this issue off the Kerberos development community
to find out if we are dealing with a regression in the Kerberos PKINIT
code or misinterpretation of the issue on our part.

We maintain the Hurdo package which implements Kerberos credential
authenticated sudo support over OpenSSH. The package can be found at
the following URL:

ftp://ftp.hurderos.org/pub/Hurdo/Hurdo-0.3.0.tar.gz

This package implements support for authenticating a sudo privilege
escalation with a short lived Kerberos service ticket sent over an
OpenSSH local message channel. It provides a framework for using
Kerberos to authenticate sudo requests without the risk of horizontal
privilege escalation in the event of a compromised host. It includes
support for propagating the requests through bastion or 'jump' hosts.

Version 0.3 has full support for PKINIT but in our testing of
'instance' principals of the following form:

sudo/***@REALM

kinit returns the following error:

Client name mismatch while getting initial credentials.

We have confirmed that this persists through the 1.14.4 Kerberos
release.

With debug enabled in the pkinit.so pre-authentication module we have
traced the problem to the verify_client_san() function which ends up
trying to compare the following two principals:

sudo\/***@REALM

sudo/***@REALM

Which obviously fails.

Examining the certificate in DER form indicates the principal name is
encoded as sudo/***@REALM as is desired. It appears something goes
wrong in the following function:

pkinit_crypto_openssl:crypto_retrieve_X509_sans()

Which generates the 'backslash protected' instance principal from the
Subject Alternate Name supplied principal in the pre-authentication
certificate.

We will keep tracing this but wanted to verify that this was not some
intentionally desired behavior by the Kerberos developers. If so was
there a decision to deny use of instance principals for PKINIT?

We will look forward to any reflections the development community may
have. Including a patch if someone else has managed to run into
this... :-)

Have a good week.

Greg

As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
PH: 701-281-1686
FAX: [phone] EMAIL: ***@enjellic.com
------------------------------------------------------------------------------
"So you got your butt kicked by an 'old' guy.

Before you taunted him did it ever cross your mind that the $1200
Schmoelke aero-bars he was laying on and the $900 Rocket7 cycling
shoes he was wearing might mean that the $10,000 custom bike frame he
was riding might be used for more than transportation to the Dairy
Queen each night for a Dilly Bar?"
-- Dr. G.W. Wettstein
Resurrection

[Greg Hudson]

Post by Dr. Greg Wettstein
Examining the certificate in DER form indicates the principal name is

I'm not sure this is correct. An AnotherName of type KRB5PrincipalName
is defined by RFC 4556 to be of type KRB5PrincipalName:

KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}

and PrincipalName is defined by RFC 4120 as:

PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}

If in the DER you are seeing a name-string containing a length-1
sequence containing the string "sudo/UID", that is a single-component
principal, which unparses to "sudo\/***@REALM" as you saw.

(It would certainly be simpler to create PKINIT certificates using
OpenSSL if RFC 4556 had used unparsed principal names instead of
ASN.1-encoding them. But that ship sailed long ago.)

To correctly generate a multi-component principal name in the
certificate using an OpenSSL extensions file, the SEQUENCE of principal
components needs to contain separate elements for each principal. In
http://web.mit.edu/kerberos/krb5-latest/doc/admin/pkinit.html you can
see this being done in the extensions file for the KDC certificate, and
you can apply something similar for client certificates. Our
documentation in this area could be improved; we have an open issue at:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=7940
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev