Subject: [Ietf-krb-wg] FW: draft-ietf-krb-wg-otp-preauth-05 - review/feedback

From: [email-masked]
Date: Tue, 19 Aug 2008 09:38:15 -0400

Review comments from CyberSafe on the current OTP pre-auth ID

________________________________

From: Srinivas Cheruku [mailto:[email-masked]] 
Sent: 19 August 2008 14:17
To: Richards, Gareth
Cc: Tim Alsop
Subject: draft-ietf-krb-wg-otp-preauth-05 - review/feedback

Gareth,

I looked into your draft draft-ietf-krb-wg-otp-preauth-05 the entire day
today and here is my feedback/queries etc. Hope this info will help you.

In section 2.3:

   If, following successful validation of a PA-OTP-REQUEST in a AS-REQ,

   the KDC requires that the user changes their PIN then it will include

   a PA-OTP-PIN-CHANGE element in the armored data of the PA-FX-FAST-

   REPLY PA-DATA element of the AS-REP.  This data can be used to return

   a new PIN to the user if the KDC has updated the PIN or to indicate

   to the user that they must change their PIN.

Ideally the PIN change is done by the user, but from above looks like
KDC can change PIN and send the same in the PA-OTP-PIN-CHANGE. Is this
correct?

In which circumstances the KDC would change PIN and let the user know
its new PIN. Do you think changing PIN by KDC is secure enough?

The draft specifies that the kadmin/changepw service ticket should be
returned with recommended ticket lifetime as 1 min in the AS-REP instead
of TGT when PIN change is required. The PIN change should be done using
KPASSWD request similar to Kerberos password change. This addresses the
PIN change by user which is clear enough. But, what should happen when
KDC changes PIN and returns it in PA-OTP-PIN-CHANGE?

When PIN is changed by KDC and returned in PA-OTP-PIN-CHANGE (in AS-REP)
to client, the client implementation should show the new PIN to the user
to use it later or what should happen next - The TGT is not retuned and
kadmin/changepw service ticket is returned - how the user can get the
TGT as the PIN is already changed by KDC and there won't be any KPASSWD
request for PIN change? Should the user use the new PIN in the Kerberos
change password request with his new pin and then use PA-OTP-REQUEST to
get the TGT using the new PIN set by him?

Section 2.4:

   It is possible with time and event-based tokens that the OTP server

   will lose synchronization with the current token state.  If, when

   processing a PA-OTP-REQUEST, the pre-authentication validation fails

   for this reason then the KDC SHALL return a KRB-ERROR message

   containing a PA-OTP-CHALLENGE in the PA-DATA with the "nextOTP" flag

   set.  If this flag is set then the client MUST re-try the

   authentication using the OTP for the token "state" after that used in

   the failed authentication attempt.

The OTP value along with Armor key is used for generating the Client Key
at client and KDC side. The verification of PA-OTP-REQUEST can fail when
using Client key that is different (maybe because of using wrong OTP
value or unsynchronized OTP value) at client side and KDC side. Is this
correct?

So, the pre-authentication can fail due to

 1. using wrong OTP value

 2. using OTP value with lost synchronization.

How can the KDC differentiate between the wrong OTP value and
unsynchronized OTP value? Do you think nextOTP flag should be set when
pre-auth fails due to using wrong OTP value also?

Section 3.2:

   If the OTP is to be generated using an server generated challenge

   then the value of the challenge SHALL be included in the otp-

   challenge field.  If the OTP is to be generated by combining the

   challenge with the token's current state (e.g. time) then the

   "combine" flag SHALL be set.

Can the OTP generated just by using server generated challenge without
the token's current state?

Section 3.3:

   If the "combine" flag is not set

   in the PA-OTP-CHALLENGE then the OTP SHALL be calculated based only

   the challenge and not the internal state (e.g. time or counter) of

   the token.

OTP is just based on challenge and token state is not considered, is
this ok? I am trying to understand why shouldn't the token state be used
always and how could just using the challenge would help. The basic
purpose is to use the token state which is not so now. Is there any
reason behind this?

Do you think it is better off if the PA-OTP-CHALLENGE is treated as
invalid in this case?

   If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE

   that contained hash algorithm identifiers and the OTP value is to be

   used in the key derivation then the client MUST use hashed OTP values

   and MUST select the first algorithm from the list that it supports.

How would I know whether OTP value should be used in the key derivation
or not? Is this based on whether the OTP value is included in the
PA-OTP-REQUEST or not?

>From Section 3.3:

   The client MUST derive the Client Key and Reply Key as described in

   Section 3.6.  In order to support OTP algorithms where the KDC cannot

   obtain the OTP value, the client MAY include the generated value in

   the otp-value field of the response.  However, the client MUST NOT

   include the OTP value in the response unless it is allowed by the

   algorithm profile.  If it is included then the OTP value MUST NOT be

   used in the key derivation.

>From section 3.4:

   If the otp-value field is included in the PA-OTP-REQUEST then the KDC

   MUST use that value in the key generation.  Otherwise, the KDC will

   need to generate or obtain the value.

I am confused as section 3.3 says when otp-value is included in
PA-OTP-REQUEST, then it should not be used for key derivation whereas
section 3.4 says that otp-value from PA-OTP-REQUEST must be used in key
generation. Can you please clarify?

Section 3.5:

   The client then uses its generated Reply Key to decrypt the PA-OTP-

   ENC-CONFIRM from the encData of the PA-OTP-CONFIRM.  The client MUST

   fail the authentication process if the nonce value in the PA-OTP-ENC-

   CONFIRM is not the same as the nonce value sent in the PA-OTP-

   REQUEST.

With which error the client should fail the authentication? Is this
error implementation specific?

Section 3.6:

   If the OTP value is binary and the hash value is not used, then K2

   SHALL be derived from the base64 encoding of the OTP value.

             K2 = string-to-key(Base64(OTP)||"Krb-preAuth")

   If the OTP value is not binary and the hash value is not used, then

   K2 SHALL be derived by running the OTP value once through string-to-

   key.

             K2 = string-to-key(OTP||"Krb-preAuth")

I think otp-format determines whether OTP is binary, alphanumeric,
decimal, or hexadecimal. No issues with alphanumeric and binary OTP.
When otp-format is decimal or hexadecimal, then should the OTP value
considered as binary or not binary? 

Section 3.4:

   The authentication MUST fail if the encryption type used by the

   client in the encData does not conform to policy.

How would the KDC know the encryption type used by the client in
PA-OTP-REQUEST(doesn't have etype as one of its fields) in two-pass
variant? 

How can KDC determine that the encryption type used by client is wrong
from encData? 

Maybe, it is better to add etype as one of the fields in PA-OTP-REQUEST
and PA-OTP-CONFIRM.

Section B.2

   In this example, the user has been issued with a hand-held token and

   so none of the OTP generation parameters (otp-length etc) are

   included in the PA-OTP-RESPONSE.  The KDC does not require hashed OTP

   values in the key generation.

I think PA-OTP-REQUEST should be used instead of PA-OTP-RESPONSE.

Thanks,
Srinivas

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

---

From: [email-masked]
Date: Thu, 21 Aug 2008 06:08:18 -0400

Srinivas,

Thanks a lot for the comments.

>	Ideally the PIN change is done by the user, but from above looks
like KDC can change
>     PIN and send the same in the PA-OTP-PIN-CHANGE. 
>     Is this correct?

Yes, this is correct

>	In which circumstances the KDC would change PIN and let the user
know its new PIN. Do 
>     you think changing PIN by KDC is secure enough?

This can be used when the user has forgotten their PIN and the
administrator would set it and put the user in new PIN mode.

Only an issue if the user has not been authenticated or if the tunnel
end point is not the client	 

>	The draft specifies that the kadmin/changepw service ticket
should be returned with 
>     recommended ticket lifetime as 1 min in the AS-REP instead of 
>     TGT when PIN change is required. The PIN change should be done
using KPASSWD request 
>     similar to Kerberos password change. This addresses the PIN 
>     change by user which is clear enough. But, what should happen when
KDC changes PIN and 
>     returns it in PA-OTP-PIN-CHANGE?

In this case, the KDC would return a TGT and the new PIN in the
PA-OTP-PIN-CHANGE.

I will add the following text to the end of section 2.3:

          If the user's PIN has been changed and the KDC is returning
          the new value to the user then no such restrictions are
          required and the KDC SHOULD return a standard TGT.
	 
>	When PIN is changed by KDC and returned in PA-OTP-PIN-CHANGE (in
AS-REP) to client, 
>     the client implementation should show the new PIN to the user to
use it later or 
>     what should happen next - The TGT is not retuned and
kadmin/changepw service ticket 
>     is returned - how the user can get the TGT as the PIN is already
changed by KDC and 
>     there won't be any KPASSWD request for PIN change? Should the user
use the new PIN 
>     in the Kerberos change password request with his new pin and then
use PA-OTP-REQUEST 
>     to get the TGT using the new PIN set by him?
> 

See the answer above.

>	The OTP value along with Armor key is used for generating the
Client Key at client 
>     and KDC side. The verification of PA-OTP-REQUEST can fail when
using Client key 
>     that is different (maybe because of using wrong OTP value or
unsynchronized OTP value) 
>     at client side and KDC side. Is this correct?
>
Yes, if the client used a wrong OTP value then it would not generate the
same Client Key as the KDC and so the KDC would not be able to decrypt
the returned nonce value.

>	How can the KDC differentiate between the wrong OTP value and
unsynchronized OTP value? 
>     Do you think nextOTP flag should be set when pre-auth fails due to
using wrong OTP
>     value also?

Typically, the KDC would try a range of OTP values.  If the client is no
longer synchronised with the KDC (or separate OTP server) then the
matching OTP value would be in some outer window and so out of the
acceptable range.  If the OTP value is incorrect then no matching OTP
value would be found.
	 
>	Can the OTP generated just by using server generated challenge
without the token's
>     current state?
Yes, if the PA-OTP-CHALLENGE contains an otp-challenge and the "combine"
flag is not set.	 

>	OTP is just based on challenge and token state is not
considered, is this ok? 
>     I am trying to understand why shouldn't the token state be used
always and how 
>     could just using the challenge would help. The basic purpose is to
use the token 
>     state which is not so now. Is there any reason behind this?
>
>	Do you think it is better off if the PA-OTP-CHALLENGE is treated
as invalid in this case?

This flexibility is there to allow all of the combinations to be
supported.  Some of the newer tokens will be able to support different
combinations of challenge-response/time/counter and we can't predict
what customers will want to use.
	 
>	How would I know whether OTP value should be used in the key
derivation or not? 
>     Is this based on whether the OTP value is included in the
PA-OTP-REQUEST or not?
The OTP value is not used in key derivation if the OTP algorithm being
used does not allow the KDC to obtain the OTP value.  S/Key is the only
case I know of.  In this situation, the client would instead send the
OTP value to the KDC in the otp-value of the PA-OTP-REQUEST.  The client
therefore either uses the OTP in key derivation or it inludes the value
in the otp-value.  The system used will depend on the algorithm profile.

>	I am confused as section 3.3 says when otp-value is included in
PA-OTP-REQUEST, 
>     then it should not be used for key derivation whereas section 3.4
says that 
>     otp-value from PA-OTP-REQUEST must be used in key generation. 
>     Can you please clarify?
>
This is an error.  The paragraph is section 3.4 should say "If the
otp-value field is included in the PA-OTP-REQUEST then the KDC MUST use
that value.  Otherwise ... .".  I will correct this.  Thanks	 

>	With which error the client should fail the authentication? 
>     Is this error implementation specific?
>
I would welcome some advice from the WG here.  

The problem is that the mutual authentication process has failed since
the Reply Key generated by the client has not successfully decrypted the
nonce that that has been returned by the KDC encrypted with what should
be the same Reply Key.  The client cannot therefore permit the process
to continue and so must abort.  

Are there any standard ways of a client aborting the authentication
process?
	 
>	I think otp-format determines whether OTP is binary,
alphanumeric, decimal, 
>     or hexadecimal. No issues with alphanumeric and binary OTP. When
otp-format 
>     is decimal or hexadecimal, then should the OTP value considered as
binary 
>     or not binary? 
The decimal format is an OTP of the form "12345", hexadecimal would be
of the form "123ABC" and alpahnumeric would be mixed and so all three
should be treated as non-binary.	 

However, this raises a question about the handling of case.  The OTP
value is used as input to string-to-key as shown above and so both the
KDC and client must use the same case of OTP value in order to generate
the same key.  One possibility is for the client to return a flag
indicating what case it used.

>	How would the KDC know the encryption type used by the client in
PA-OTP-REQUEST
>    (doesn't have etype as one of its fields) in two-pass variant? 
>	How can KDC determine that the encryption type used by client is
wrong from encData? 
>	Maybe, it is better to add etype as one of the fields in
PA-OTP-REQUEST and 
>     PA-OTP-CONFIRM.
I was assuming that the KDC could tell from the etype of the
EncryptedData.  If the encData sent by the client containing the
encrypted nonce does not conform to KDC policy then the KDC should fail
the authentication.

Do you think that this won't work?
	 
>	I think PA-OTP-REQUEST should be used instead of
PA-OTP-RESPONSE.
Fixed, thanks.

There are a couple of places in the document where PA-OTP-RESPONSE is
mentioned
	 
Thanks

--Gareth

---

From: Srinivas Cheruku <[email-masked]>
Date: Thu, 21 Aug 2008 11:48:41 +0100

Gareth,

See below:

Thanks,
Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 21, 2008 3:38 PM
To: [email-masked]; [email-masked]
Cc: Tim Alsop; Srinivas Cheruku
Subject: RE: [Ietf-krb-wg] FW: draft-ietf-krb-wg-otp-preauth-05 - review/feedback

Srinivas,

should be returned with
using KPASSWD request
KDC changes PIN and

[Srinivas Cheruku] good

Client Key at client
using Client key

using wrong OTP

[Srinivas Cheruku] ok.

considered, is this ok?
always and how
use the token
as invalid in this case?

[Srinivas Cheruku] ok.

derivation or not?
PA-OTP-REQUEST or not?

PA-OTP-REQUEST,
says that

[Srinivas Cheruku] yep.

alphanumeric, decimal,
otp-format
binary

[Srinivas Cheruku] ok.

[Srinivas Cheruku] yes, better that the client sets otp-format it used in the PA-OTP-REQUEST.

PA-OTP-REQUEST
wrong from encData?
PA-OTP-REQUEST and

[Srinivas Cheruku] I now understand that there is no need of etype in PA-OTP-REQUEST or PA-OTP-CONFIRM as the EncryptedData contains the etype.

Fixed, thanks.

Thanks

--Gareth