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

From: [email-masked]
Date: Tue, 08 Feb 2011 02:00:01 -0800

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-15.txt
	Pages           : 40
	Date            : 2011-02-08

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-15.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: Simon Josefsson <[email-masked]>
Date: Sun, 20 Feb 2011 21:50:10 +0100

The otp-challenge field is hard coded to a minimum of 8 characters:

         otp-challenge  [7]  OCTET STRING (SIZE(8..MAX)) OPTIONAL,

There are several OTP mechanisms that uses shorter challenges, including
the OATH OCRA mechanism which can use 4 character challenges.

/Simon

---

From: <[email-masked]>
Date: Tue, 22 Feb 2011 10:22:23 -0500

I'll change this to  

otp-challenge  [7]  OCTET STRING (SIZE(1..MAX)) OPTIONAL,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon 
> Josefsson
> Sent: 20 February 2011 20:50
> To: [email-masked]
> Subject: [Ietf-krb-wg] otp-challenge SIZE(8..MAX) in 
> draft-ietf-krb-wg-otp-preauth-15.txt
> 
> There are several OTP mechanisms that uses shorter 
> challenges, including the OATH OCRA mechanism which can use 4 
> character challenges.
> 
> /Simon

---

From: <[email-masked]>
Date: Tue, 22 Feb 2011 10:38:31 -0500

Simon,

I just checked back and the eight octet requirement came from EAP-POTP [RFC-4793].

If I change this to be 1..MAX then the text describing the otp-challenge in section 4.1 will need to be updated as well.

The current text is:

         The otp-challenge is used by the KDC to send a challenge value
         for use in the OTP calculation.  The challenge is an optional
         octet string that SHOULD be uniquely generated for each request
         it is present in, and SHOULD be eight octets or longer when
         present.  When the challenge is not present, the OTP will be
         calculated on the current token state only.  The client MAY
         ignore a provided challenge if and only if the OTP token the
         client is interacting with is not capable of including a
         challenge in the OTP calculation.  In this case, KDC policies
         will determine whether to accept a provided OTP value or not.

The second sentence will need to be updated, would the following be OK?

         The challenge is an optional
         octet string that SHOULD be uniquely generated for each request
         it is present in, and SHOULD be the maximum length supported by 
         the token.

--Gareth

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Feb 2011 17:01:33 +0100

> I just checked back and the eight octet requirement came from EAP-POTP

Interesting.  Good to know the background.

> If I change this to be 1..MAX then the text describing the
> otp-challenge in section 4.1 will need to be updated as well.
>
> The current text is:
>

Good catch, I missed this text.  It works for me, but the final part
seems awkward for tokens that support really long (e.g., 3000
characters) or unlimited length challenges?

/Simon

---

From: <[email-masked]>
Date: Tue, 22 Feb 2011 11:11:34 -0500

> >
> > I just checked back and the eight octet requirement came 
> from EAP-POTP 
> > [RFC-4793].
> 
> Good catch, I missed this text.  It works for me, but the 
> final part seems awkward for tokens that support really long 
> (e.g., 3000

Good point! 

How about compromise:

         The challenge is an optional
         octet string that SHOULD be uniquely generated for each request
         in which it is present.  The challenge and SHOULD be at least 
         eight octets unless challenges of that length are not supported
         by the token.

--Gareth

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Feb 2011 19:26:42 +0100

>          eight octets unless challenges of that length are not supported

That works for me too.

/Simon

---

From: Frank Cusack <[email-masked]>
Date: Fri, 25 Feb 2011 11:02:26 -0800

>          eight octets unless challenges of that length are not supported

I'm not crazy about recommending any specific minimum length.  It also
doesn't seem to add any value to the spec.

But it's fine if that's the way you want to go.  No more arguments here.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg