Subject: Re: [Ietf-krb-wg] I-D Action:draft-ietf-krb-wg-otp-preauth-09.txt

From: <[email-masked]>
Date: Fri, 16 Jan 2009 06:07:17 -0500

Larry,

There are two issues remaining from those you said needed to be resolved
before the OTP pre-auth ID could proceed: j and z.  

> j) section 3.4, should we indicate to the client the error conditions 
> so that the client can differentiate them?
> 
>  The KDC generates the Client Key and Reply Key as described in
>    Section 3.6 from the OTP value using the hash algorithm and 
> iteration
>    count if present in the PA-OTP-REQUEST.  However, the client
>    authentication MUST fail if the KDC requires hashed OTP values and
>    the hashAlg field was not present in the PA-OTP-REQUEST, if the 
> hash
>    algorithm identifier or the value of iterationCount included in the
>    PA-OTP-REQUEST do not conform to local KDC policy or if the value 
> of
>    the iterationCount is less than that specified in the PA-OTP-
>    CHALLENGE.
> 

I am not sure what to do about this issue.  Is there a convention for
communicating different error conditions?

> z) section 6.4, It is not clear how to meet the following requirements

> when there are more than one KDC.
> 
>   To reduce the chance
>    of replay attacks, the KDC must check that the client time used in
>    such a request is later than that used in previous requests.
> 

I think that z has been resolved following the discussion on-line and I
am proposing the following change to section 6.4.

        <t>
          In the 4-pass version of this protocol, the client encrypts
          a KDC generated nonce and so replay can be detected by the
          KDC.  The 2-pass version of the protocol does not involve a
          server nonce but the client instead encrypts a timestamp and
          so is not protected from replay in the same way.  In the
          case of time or event-based tokens, a replayed OTP can be
          detected by the OTP server since they keep track of the last
          used value.
        </t>
        <t>
          However, OTP servers may not be able to detect replay of
          OTPs generated using only a client generated challenge and
          since the KDC would not be able to detect replay in 2-pass
          mode, it is recommended that the use of OTPs generated from
          only a client-generated challenge (that is, not in
          combination with some other factor such as time) should not
          be supported in 2-pass mode.
        </t> 

--Gareth

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 10 December 2008 11:34
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ietf-krb-wg] I-D 
> Action:draft-ietf-krb-wg-otp-preauth-09.txt
> 
> > 
> > >> z) section 6.4, It is not clear how to meet the following 
> > >> requirements when there are more than one KDC.
> > >>
> > >>   To reduce the chance
> > >>    of replay attacks, the KDC must check that the client
> > time used in
> > >>    such a request is later than that used in previous requests.
> > >>
> > > Doesn't the same issue apply to the standard encrypted
> > password method?
> > > How does it resolve this problem?
> > 
> > I think the real issue is how to decide if a replay'ed 
> request should 
> > be rejected (from an attacker) or supported (from 
> error-retry on the 
> > client due to slow response to the first request).  
> Currently replays 
> > are effectively allowed, which violates the "One Time" part of OTP.
> > 
> > I know of no really good way to preserve multiple-KDC 
> redundancy/load 
> > distribution and "One Time" properties simultaneously.  One 
> solution 
> > used with SAM was to forward all OTP requests to a single KDC. 
> > (*bleah*)
> > 
> > I suggest that this issue might be mentioned (perhaps as a security 
> > consideration if some kinds of replay attacks are allowed), but 
> > otherwise be treated as outside the scope of this RFC.  Even if 
> > someone knows a good solution, I think it would deserve its own 
> > document.
> 
> In the case of time or event-based tokens, a replayed OTP 
> would be rejected by the OTP server itself since they keep 
> track of the last used value.  Having the KDC check the 
> timestamp in two-pass mode could help by blocking requests 
> before they reach the OTP server and so could help in DoS 
> attacks but is probably not required for protection against replay.  
> 
> However, there could be an issue with challenge-response 
> tokens if used with client-generated challenges in two-pass 
> mode.  These types of attacks could probably not be blocked 
> by the OTP server or by the KDC if multiple KDCs are used.  
> In that case, I would think that the security considerations 
> should say that this mode should not be supported.
> _______________________________________________
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
> 
> 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg