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

From: [email-masked]
Date: Thu, 21 Aug 2008 06:46:11 -0400

Forwarding response from CyberSafe. 

-----Original Message-----
From: Srinivas Cheruku [mailto:[email-masked]] 
Sent: 21 August 2008 11:36
To: Richards, Gareth
Cc: Tim Alsop
Subject: RE: [Ietf-krb-wg] FW: draft-ietf-krb-wg-otp-preauth-05 -
review/feedback

Gareth,

See below:

Thanks,
Srini

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

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
>
>       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.

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?

[Srinivas Cheruku] ok

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.

[Srinivas Cheruku] yes, you are right. There is no need of etype as part
of PA-OTP-REQUEST as the etype is part of EncryptedData as below:

   EncryptedData   ::= SEQUENCE {
           etype   [0] Int32 -- EncryptionType --,
           kvno    [1] UInt32 OPTIONAL,
           cipher  [2] OCTET STRING -- ciphertext
   }

[Srinivas Cheruku]
--Gareth

_______________________________________________
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:53:30 -0400

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

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,

Thanks a lot for the comments.

>       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.

[Srinivas Cheruku] good

>
>       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?
>
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.

>       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?

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.

[Srinivas Cheruku] ok.

>
>       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?

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.

[Srinivas Cheruku] ok.

>
>          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?
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.

>
>       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?
>
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

[Srinivas Cheruku] yep.

>
>       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?
>
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?

>
>       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?
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.

[Srinivas Cheruku] ok.

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.

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

>
>       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.
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?

[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.

>
>       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.
Fixed, thanks.

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

Thanks

--Gareth