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

From: [email-masked]
Date: Fri, 5 Dec 2008 03:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kerberos Working Group of the IETF.

	Title           : OTP Pre-authentication
	Author(s)       : G. Richards
	Filename        : draft-ietf-krb-wg-otp-preauth-09.txt
	Pages           : 36
	Date            : 2008-12-05

The Kerberos protocol provides a framework authenticating a client
using the exchange of pre-authentication data.  This document
describes the use of this framework to carry out One Time Password
(OTP) authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-otp-preauth-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: [email-masked]
Date: Fri, 5 Dec 2008 06:55:16 -0500

The new version of the has the changes made following Larry's recent
review and discussions with Henry.

There are still a couple of review comments that haven't been resolved:

> 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.
> 
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.
> 
Doesn't the same issue apply to the standard encrypted password method?
How does it resolve this problem?

--Gareth

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 05 December 2008 11:45
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ietf-krb-wg] I-D Action:draft-ietf-krb-wg-otp-preauth-09.txt
> 
> The Kerberos protocol provides a framework authenticating a 
> client using the exchange of pre-authentication data.  This 
> document describes the use of this framework to carry out One 
> Time Password
> (OTP) authentication.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 05 Dec 2008 13:33:40 -0800

> 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.
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: [email-masked]
Date: Wed, 10 Dec 2008 06:34:01 -0500

> 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