Subject: Re: [Ietf-krb-wg] DISCUSS and COMMENT: draft-ietf-krb-wg-preauth-framework

From: Sam Hartman <[email-masked]>
Date: Sat, 15 May 2010 14:17:01 -0400

First, thanks for your review.
There are a couple of cases where I don't propose to make any changes.
However I want to stress that I found your comments incredibly useful!

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> Discuss: I liked this specification, it was very well and
    Jari> carefully written.  I did have a few observations about the
    Jari> text that should probably be dealt with somehow -- look at my
    Jari> comments.

    Jari> I also had one bigger issue that I wanted to discuss before
    Jari> recommending the approval of the specification. Is there some
    Jari> kind of mandatory-to- implement mechanism/factor set? Wouldn't
    Jari> this be necessary to ensure interoperability?

It would be and there is.
It's scattered throughout the document.
Section 3.3:
   client MAY ignore any padata it chooses unless doing so violates a
   specification to which the client conforms.  Clients conforming to
   this specification MUST NOT ignore the padata defined in Section 6.2.
(PA-FX-COOKIE)
Section 6.4:
Conforming implementations MUST
   support Kerberos FAST padata.

Section 6.4.1:
   Conforming implementations MUST implement the
   FX_FAST_ARMOR_AP_REQUEST armor type.  

Section 6.4.6:
   Conforming implementations MUST support the encrypted challenge FAST
   factor.

Section 6.4.3 also contains text that amounts to another requirement
for pa-fx-cookie (section 6.2).

Admittedly it took me a while to find these conformance requirements in
the document and for a while I was worried that we'd missed making
encrypted challenge required.  I'm adding a subsection to the
introduction called "Conformance Requirements" that summarizes the
requirements I've identified above.  I consider this change editorial
because I'm not introducing new requirements.  However, I'd like to ask
you to clear now because I believe the current version of the document
does contain sufficient requirements for interoperability.

    Jari> Comment: Section 1:

    Jari>    Also, problems like combining a key with the long-term
    Jari> secrets or proving the identity of the user are common to
    Jari> multiple mechanisms.

    Jari> Editorial -- proving the identity is not a problem. Maybe this
    Jari> sentence needs to be reformulated.
s/problems/tasks.
Multiple mechanisms must do the same things.

    Jari> Section 1:

    Jari>    The PA-DATA typed hole may be used to carry extensions to
    Jari> Kerberos that have nothing to do with proving the identity of
    Jari> the user or establishing a reply key.

    Jari> Wouldn't an applicability note be appropriate here to specify
    Jari> what kinds of extensions are appropriate?

No, there is a general extensibility guidance section in RFC 4120, and
 the registration requirements in this section describe what we want
 review for.
Part of the answer is that padata is *the big extensibility hole in
 Kerberos*. I can't think of anything that would be too major of a
 change to use it for, but I can think of changes I'd want reviewed
 carefully.  But that's what IANA policies are for.

    Jari> Section 3.1:

    Jari>    The following information is maintained by the client and
    Jari> KDC as each request is being processed:

    Jari>    o ...  o How strongly the identity of the client has been
    Jari> authenticated

    Jari> Isn't there also the need to store the identity that was used
    Jari> in pre-authentication, in case the client has several suitable
    Jari> identities? 
    Jari> Also, I suspect that the client does not really
    Jari> know "how strongly" it has been authenticated. It might be
    Jari> better to say "o What authentication mechanism and identities
    Jari> were used to authenticate the client." Finally, later in the
    Jari> document you talk about optional mechanisms that can indicate
    Jari> successful authentication of the client's identity. Do you
    Jari> need to maintain a record of both what authentication was used
    Jari> and what indication was gotten?

I understand what you're driving at.
I think the WG could spin several more rounds and get better text here,
but I don't think it would be worth the effort.
>From the standpoint of Kerberos, there really only is one identity
involved here: the principal.
An individual pre-authentication mechanism might use other identities
internally, but that's not what this state item is about.
I do think this is a section we'll probably touch on when we go to
draft.

    Jari> Section 3.1:

    Jari>    If a mechanism indicates that the reply is not verified
    Jari> then the client implementation MUST return an error unless a
    Jari> subsequent mechanism verifies the reply.  The KDC needs to
    Jari> track this state so it can avoid generating a reply that is
    Jari> not verified.

    Jari> Who is the client returning an error to, the user, or the KDC?
    Jari> How does the client know that a subsequent mechanism might be
    Jari> verifying something, i.e., when do you know you have failed
    Jari> verification?

The error is returned to the user.  You have failed verification if you
get to a point where the conversation is done and the reply has not been
marked as verified.  A conversation is done when you get an AS reply
message or when you get an error and the conditions for whether you
continue from an error discussed in section 6.2 and 3 are not met.

    Jari> Section 3.1:

    Jari>    The KDC SHOULD NOT send data that is encrypted in the
    Jari> long-term password-based key of the principal.  Doing so has
    Jari> the same security exposures as the Kerberos protocol without
    Jari> pre-authentication.  There are few situations where the KDC
    Jari> needs to expose cipher text encrypted in a weak key before the
    Jari> client has proven knowledge of that key, and
    Jari> pre-authentication is desirable.
s/and/and where/

    Jari> There are few situations, and this is not one of them? What
    Jari> does the text part ", and pre-authentication is desirable"
    Jari> mean above? I'm not sure I understand...

You SHOULD NOT expose ciphertext in the long-term key.  That means your
implementation should not do this unless it has a good reason to do so.
The rest of the paragraph is rationale.  If you expose the text in the
long-term key, then you have the same security guarantees as Kerberos
without pre-authentication.  Typically the situations where you want to
do that are situations where pre-authentication is not useful.  If
you're in one of those strange situations--for example Kerberos without
pre-authentication would be sufficiently secure, but you're using
pre-authentication as a way to get some protocol extensibility--then you
have a reason to violate the should.  Help with the wording of this
paragraph would be greatly appreciated: it's been through a couple
rounds in the WG and we're clearly not done yet.

    Jari> Section 3.3:

    Jari>    If a client chooses to ignore a padata it MUST NOT process
    Jari> the padata, allow the padata to affect the pre-authentication
    Jari> state, nor respond to the padata.

    Jari> I.e., if the client chooses to ignore padata then it must
    Jari> ignore padata?

Yes.  This requirement is both attempting to define ignoring padata and
say that you cannot partially ignore padata.

    Jari> Section 4:

    Jari>    In order to avoid this problem, extensions that change core
    Jari> semantics are typically divided into two parts.  The first
    Jari> part proposes a change to the core semantic--for example
    Jari> proposes a new reply key.  The second part acknowledges that
    Jari> the extension is understood and that the change takes effect.

    Jari> Shouldn't this be formulated as a requirement?
The actual requirement is in section 1.5 of RFC 4120 and is restated in
the paragraph before the one you quote. This is guidance to mechanism
designers on one way to approach this particular implication of the
requirement.  I don't think we have enough experience here to make this
normative.

    Jari> Section 4.3:

    Jari>    In the case of this facility it will likely be the case for
    Jari> both sides to know that the facility is available by the time
    Jari> that the new key is available to be used.

    Jari> Only likely, not certain? Perhaps you should explain the
    Jari> conditions under which this works correctly.
I think I do: both sides need to indicate support for the extension
 before it affects state.

Whether this is true depends on your message flow.  Typically to replace
the reply key you have at least a full round trip involved or the KDC is
the one replacing the reply key and the client requests the mechanism
that will do this.
If you design a mechanism where you can replace the reply key in a half
round trip and where you'll do so before the other side has indicated
support, you'll know that you've done that.

    Jari> Section 5.1:

    Jari>    An early design goal of Kerberos Version 5 [RFC4120] was to
    Jari> avoid encrypting more of the authentication exchange that was
    Jari> required.

    Jari> Should this be s/more ... that/more ... than/?
Yes, fixed.

    Jari> Section 6.4.2:

    Jari>    This checksum MUST be a keyed checksume and it is included
    Jari> in order to bind the FAST padata to the outer request.

    Jari> s/checksume/checksum/
Thanks.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 May 2010 19:06:16 +0300

Thanks for your response. I have cleared my Discuss, though of course I 
also look forward to the new document revision with the changes that you 
mentioned.

Jari