Thanks for the review. I am working on an update to address this feedback; here are answers where the feedback asked questions. On 5/25/22 12:56, Barry Leiba via Datatracker wrote:> Clients and KDCs MUST implement the > edwards25519 group, but MAY choose not to offer or accept it by > default. > > How can one tell, externally, whether edwards25519 is not implemented, or > simply is being refused? One cannot tell from the another endpoint. The goal of this mandatory-to-implement provision is to ensure that any two SPAKE preauth implementations can be configured to interoperate. This is similar to analagous requirements in TLS (RFC 5246 section 9 and 8446 section 9.2), although those document stop at mandating implementation. > Upon receipt of this AS-REQ, a KDC which > requires pre-authentication and supports SPAKE SHOULD reply with a > KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty > PA-SPAKE PA-DATA element > > SHOULD? Why might it not? What happens if it doesn’t? (So, why isn’t it > MUST, and how can an implementor decide whether it’s OK not to?) A principal might be configured to require specific pre-authentication mechanisms. Or a principal might have no associated long-term keys, in which case only preauth mechanisms like PKINIT or FAST OTP (which do not use long-term keys) can be offered. > I do wonder, in Section 10.5, why “client implementations SHOULD provide a > configuration option to disable encrypted timestamp on a per-realm basis”, > rather than having encrypted timestamp disabled by default, and saying that > they MAY provide an option to enable it on a per-realm basis. Keep in mind > that I’m not an expert here, so please just tell me if it’s obvious that that > can’t work, or some such. That feels ambitious for a SHOULD. In an optimistic future it might eventually make sense to disable encrypted timestamp by default, but I don't think a client implementation could reasonably do so in the short or medium term. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
