Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
draft-ietf-kitten-pkinit-alg-agility-08
Yes
(Benjamin Kaduk)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 04 and is now closed.
Warren Kumari
No Objection
Comment
(2019-03-05 for -05)
Not sent
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.
Benjamin Kaduk Former IESG member
Yes
Yes
(for -04)
Unknown
Adam Roach Former IESG member
(was Discuss)
No Objection
No Objection
(2019-03-06 for -05)
Sent
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.
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -05)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -06)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -05)
Not sent
Ben Campbell Former IESG member
No Objection
No Objection
(2019-03-05 for -05)
Sent
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".
Deborah Brungard Former IESG member
No Objection
No Objection
(for -05)
Not sent
Eric Rescorla Former IESG member
No Objection
No Objection
(2019-03-13 for -06)
Sent
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.
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -06)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -05)
Not sent
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -06)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -05)
Not sent