Re: [kitten] Murray Kucherawy's No Objection on draft-ietf-kitten-krb-spake-preauth-11: (with COMMENT)

[Greg Hudson <[e-mail]>]

On 1/18/24 10:16, Murray Kucherawy via Datatracker wrote:
> In Section 12, we're telling the Designated Experts that an I-D counts as a
> specification, even if it is never published as an RFC.  But an I-D can expire.
>   Are we OK with having an IANA registry with an entry that claims as its
> authoritative specification an expired I-D?

I assume this comment is not intended to be actionable by the draft 
editors, as the situation will be rectified if the draft advances to 
RFC.  The IANA Kerberos preauthentication registry contains references 
to numerous expired drafts besides this one.

> Section 12.2.2 appears to have four registrations all run together.  Could we
> separate them somehow, either with line breaks or with subsections?

I will add subsections.

> Section 4.1: Why is this only a SHOULD?  Is it OK if I do something different?

Per this and Roman's comment, I will add the parenthetical "(unless 
configuration indicates otherwise)".

> Section 4.3: Same question.

I will change this to a MUST.

> 9.  Hint for Authentication Sets
> 
> Why MAY and not SHOULD?

I will change this to SHOULD.  (To provide a little context, 
pre-authentication sets from RFC 6113 have never been implemented to my 
knowledge.)

> Phrasing around MUST NOT and must only could be clearer, and is possibly the
> reason for the MAYs?

I don't understand this comment.  The sentence "A KDC MUST NOT include a 
PA-SPAKE-HINT message directly in a pa-value field" is trying to 
forestall the potential implementation error of placing a PA-SPAKE-HINT 
in the pa-value field of a SPAKE pa-data element, rather than in a 
pre-authentication set.

> 10.2 Unauthenticated Plaintext
> 
>> Second factor
>     types MUST account for this when specifying the semantics of the data
>     field.
> 
> It's not clear (to me) how to comply with this MUST, an example of citation
> might help.

The following sentence ("Second factor data in the challenge should not 
be included in user prompts...") is an example of accounting for the 
lack of initial integrity protection on the second-factor challenge.  I 
will add "In particular," at the beginning of that sentence to make that 
more clear.

> In 10.4
> 
> Several SHOULD's that maybe ought to be MUSTs?

I think there might be other methods to address cookie replay attacks in 
a KDC implementation, or to mitigate the risk of falling back to 
encrypted timestamp in a client.

> It would be nice to see clearer recommendations on achieving forward secrecy,
> and on rotating the cookie.

SPAKE pre-authentication provides forward secrecy against 
post-compromise of the principal long-term key (typically a user 
password), but does not help against post-compromise of the KDC's own 
krbtgt keys.  I don't really anticipate KDC implementations trying to 
achieve forward secrecy against the latter threat.  Accordingly, I will 
remove the sentence talking about rotating the cookie encryption key.