fast and patypes in KRB-ERROR

Sam Hartman hartmans-ietf at MIT.EDU
Thu May 14 19:46:11 EDT 2009


[I think these points need to be considered in a broader context than just the MIT implementation.
I think I've included enough context.]

>>>>> "Srinivas" == Srinivas Cheruku <Srinivas.Cheruku at CyberSafe.com> writes:


    Srinivas> 2.  PA-FX-COOKIE (not sure why this is required ??
    Srinivas> anyway, I think MIT uses some dummy cookie)

Per discussion on the ietf-krb-wg list, a KDC confirming to the
pre-auth framework should include a cookie whenever it wants to
continue a conversation.  This should becomes a must if FAST is being
used.  I *think* that's in the current draft, but it is definitely in
my working copy.  Larry and I had some internal slowness; I'll be
publishing a new version quite shortly.

    Srinivas> I think it might be good to include
    Srinivas> PA-ENCRYPTED-CHALLENGE also when user principal requires
    Srinivas> pre-authentication.

    Srinivas> This would means that fast enabled kinit can do the
    Srinivas> following:

    Srinivas> 1.  kinit can send a non-fast request to KDC

    Srinivas> 2.  KDC replies with KRB-ERROR containing the above
    Srinivas> pa-types along with PA-ENCRYPTED-CHALLENGE (for user
    Srinivas> principals having pre-auth required set)

    Srinivas> 3.  kinit can check for PA-FX-FAST and
    Srinivas> PA-ENCRYPTED-CHALLENGE and send a fast request
    Srinivas> containing pa-enc-challenge padata.

    Srinivas> 4.  KDC sends tgt using FAST on successful
    Srinivas> authentication

    Srinivas> I know that MIT kinit doesn't support this behaviour but
    Srinivas> other vendors can support this.  Any advice or issues
    Srinivas> you foresee?

Probably this is more of an IETF issue than an MIT issue.  My concern
about doing this is that the negotiation of which fast factors are
supported would be unprotected.

Consider a client with the policy: * prefers fast with OTP, but will
fall back to FAST with encrypted challenge.

I think you have a relatively weak password, so it is in my interest
to get you to fall back to encrypted challenge.  I delete OTP from the
initial unprotected error.




More information about the krbdev mailing list