Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
draft-ietf-kitten-pkinit-alg-agility-08

I reviewed this, but much of it is outside my area of expertise, so trusting the AD.
I did not validate any of the test vectors, etc.

Thanks to everyone who has worked on this over the past several years, and
thanks to the authors for a timely response to my earlier discuss concerns.
I am leaving the original text of my discuss below for historical reasons,
as it pertains to a larger problem that would ideally be addressed by future
work.

---------------------------------------------------------------------------

I can see in
https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26
that the OID 1.3.6.1.5.2 has been reserved for Kerberos v5 objects (a
reservation that appears to have been copied out of RFC 1700). I also see that
RFC 4556 uses 1.3.6.1.5.2.3 and defines three nodes (.1, .2, and .3) underneath
it. Try as I might, I can't find any plausibly authoritative registry that
tracks the reservation of 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1,
1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3.

This document then defines the use of 1.3.6.1.5.2.3.6. How do we know that "6"
is free? How will future specifications know that "6" is no longer available?

This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2,
1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms.
Assuming this list continues to be added to, how will future specifications
avoid collisions?

I have a similar question about 1.3.6.1.5.2.4.5.1.

I think my confusion stems from the fact that I was under the impression that
everything under 1.3.6.1 was managed by IANA -- at least, that's my reading of
RFC 1155.

To be clear: if I understand the situation correctly, I recognize that there
may be a bigger problem here that is beyond the remit of this document to
solve; however, I think it would be reasonable to not make the existing problem
worse. In particular -- and again, I may simply be confused here -- I would
expect this document to at least ask IANA to create a table at
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps
track of the children of 1.3.6.1.5.2.3.6.

---------------------------------------------------------------------------

§4:

>  When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
>  as described in Section 3.2.2 of [RFC4556], implementations
>  conforming to this specification can OPTIONALLY send back a list of

The term "OPTIONALLY" is not defined in RFC 2119, although I believe the
intention of this passage is to make a normative statement consistent with the
RFC 2119 definition of "MAY" / "OPTIONAL". Unfortunately, we only get an
auxiliary verb and an adjective from RFC 2119... no adverbs. Please rephrase to
use "OPTIONAL" or "MAY".

---------------------------------------------------------------------------

§5:

>  When the client's X.509 certificate is rejected and the
>  KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
>  described in Section 3.2.2 of [RFC4556], implementations conforming
>  to this specification can OPTIONALLY send a list of digest algorithms

Same comment as above.

Hi, thanks for this work. I only have a couple of editorial comments:

- Abstract and Introduction: Please expand PKINIT on first mention in both the abstract and body.

§4: "... implementations conforming to this specification can OPTIONALLY send back a list of supported CMS types ..."

OPTIONALLY is not a defined keywords. I suggest changing "... can OPTIONALLY ..." to "MAY"
Plural disagreement between "implementations" and "a list".

IMPORTANT
I think this document would benefit greatly from describing the
downgrade properties of each of the axes on which algorithms
can be negotiated against various forms of compromise in the
digest function.

The relevant case is one in which the client and KDC both support
one weak and one strong algorithm. Can the attacker either

(1) force them to complete a handshake with a weak algorithm
or
(2) convince one side that the other side supports a weak algorithm
and then interpose itself as that side.

Specifically it would be useful to know which attacks are possible
with a collision attack versus a preimage attack (though this
can sometimes be hard to know).


Here is one case of a potential real downgrade attack (though not a
very powerful one).

The client sends a KRB-REQ signed with algorithm A, the attacker
forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some
weaker algorithm. This causes the client to retry with that weaker
algorithm. Is this attack detectable? It's not clear to me how (though
it maybe could be if the message were folded into the transcript).

OTOH, I don't think that the equivalent attack on the cert signer
algorithms is necessarily very useful because presumably the certs are
public already. OTOH, it might force the client into using some weaker
key.


I'm having a little trouble following the point in S 3. Is the idea
that the paChecksum is always SHA-1 and you don't add a way to negotiate
it, so you are instead folding the information into the KDF? If so,
I think we need to work through the chain of logic here. As I understand
it, the paRequest is included in the AuthPack, which is signed. So
presumably the idea is that the AuthPack is signed with SHA-256
but because paChecksum is SHA-1, the binding is weak, right? But
can you safely send a SHA-256 signature to a KDC which you have
never talked to before? Can't you just get downgraded by the attack
I describe above? Can you help unpack this for me?


MINOR
I wish you were using HKDF, but I don't think this is a dealbreaker.