Subject: [Ietf-krb-wg] FW: Sean Turner's Discuss on draft-ietf-krb-wg-otp-preauth-19: (with DISCUSS and COMMENT)

From: <[email-masked]>
Date: Fri, 7 Oct 2011 05:59:47 -0400

The following issue was raised by Sean Turner during his review of the OTP pre-auth draft.

I think that this raises a potential issue with the use of otp-length and otp-format as described in my response.

>
> #1) s4.1: Is there something that needs to be said about otp-length if
> the otp-format is different?  That is if it's binary is it the minimum
> # of bytes but if it's one of the other three then it's the number of
> characters?  Characters can be encoded in a variety of ways.  This
> reminds me of the text from RFC 6030 (Encoding there is Format here):
>
>    If
>    the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
>    'ALPHANUMERIC', this value indicates the minimum number of
>    digits/characters.  If the 'Encoding' attribute is set to
>    'BASE64' or 'BINARY', this value indicates the minimum number
>    of bytes of the unencoded value.
>

The otp-length field of the PA-OTP-CHALLENGE allows the KDC to specify the length of the desired OTP for tokens that are capable of generating different lengths and is intended for the case of connected tokens that can produce a longer ("full strength") OTP.  It is essentially the equivalent of the CK_OTP_OUTPUT_LENGTH of PKCS#11 v2.20 Amendment 1 and overrides the default of the token.  The current text describing otp-length in section 4.1 states that it is the length of the generated OTP in octets which was probably written on the assumption that these longer OTP values would be binary, which is not necessarily true.  I agree that this should instead be the number of octets for binary and characters for the other formats.

There does however appear to be an issue.  If a connected token can produce OTPs in multiple formats then the client can include an otp-format field in the PA-OTP-REQUEST to inform the KDC of the format actually used.  However, if a token can produce OTPs in different formats and different lengths then it would seem that the KDC would only be able to specify the length if it also specified the format which it currently cannot do. If it didn't specify the format then how should the client interpret otp-length?

Two changes seem to be required:

1) Add otp-format as an option in the otp-tokenInfo of the PA-OTP-CHALLENGE

2) Change the description of otp-length to depend on the format as you suggest.

--Gareth
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg