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

From: [email-masked]
Date: Wed, 20 Aug 2008 04:32:37 -0400

More comments from CyberSafe
 
--Gareth

________________________________

From: Srinivas Cheruku [mailto:[email-masked]] 
Sent: 20 August 2008 06:02
To: Richards, Gareth
Cc: Srinivas Cheruku; Tim Alsop
Subject: RE: draft-ietf-krb-wg-otp-preauth-05 - review/feedback

Gareth,

I have one more comment, but I am not sure whether it will help you as I
am sending this comment late.

PA-OTP-CHALLENGE

I think instead of having single etype in this, it is better to use a
etype list (sequence of etypes) similar to 

supportedHashAlg   SEQUENCE OF AlgorithmIdentifier

PA-OTP-REQUEST

This should contain etype along with the hashAlg so that the KDC can
know the etype used by the client.

Having etype list in PA-OTP-CHALLENGE and PA-OTP-REQUEST would mean that
the KDC and client can support n number of etypes and they can choose
the best supported and also the etype would be exchanged successfully.

Having etype in PA-OTP-REQUEST would aid in KDC knowing the etype used
by the client and it can generate the Client and Reply Key accordingly.
I think this would simplify the process in case of 2-pass to the etype.

Thanks,
Srini

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2008 7:08 PM
To: [email-masked]
Cc: Srinivas Cheruku; Tim Alsop
Subject: FW: draft-ietf-krb-wg-otp-preauth-05 - review/feedback

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:33 -0400

Srini,

Thanks for the comments.

>	PA-OTP-CHALLENGE
>
>	I think instead of having single etype in this, it is better to
use a etype list (sequence of etypes) similar to 
>	This should contain etype along with the hashAlg so that the KDC
can know the etype used by the client.
>
>	Having etype list in PA-OTP-CHALLENGE and PA-OTP-REQUEST would
mean that the KDC and client can support n number of 
>     etypes and they can choose the best supported and also the etype
would be exchanged successfully.
>
>	Having etype in PA-OTP-REQUEST would aid in KDC knowing the
etype used by the client and it can generate the Client 
>     and Reply Key accordingly. I think this would simplify the process
in case of 2-pass to the etype.

I can see that having the sequence of etypes would allow for flexibility
in a similar way to selecting the hash algorithm.  Do others in the WG
think it worth making this change?

I am not sure if there is a need to put the etype in the PA-OTP-REQUEST
since I would think that the encryption type used by the client is
encoded in the EncryptedData.

--Gareth