fast and patypes in KRB-ERROR
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> This would means that fast enabled kinit can do the
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> 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