Subject: [Ietf-krb-wg] initial review of draft-ietf-krb-wg-otp-preauth-05

From: Larry Zhu <[email-masked]>
Date: Mon, 28 Jul 2008 17:20:52 -0700

In the process of evaluating if this document is ready for WGLC, I have complied my review comments. I would like to submit these comments as an individual.

1. section 1.1. can you provide a reference to "challenge-response" based OPT systems?

2. section 1.1. a discussion at Dublin today suggested replace-reply-key is vulnerable to MITM if the armor is obtained via anonymous PKINIT without KDC authentication. Sam will provide an explanation to the list. The fix this, consider replacing replying-reply-key with strengthen-reply-key.

3. Section 1.2. the 4-pass variant does not work if the user is not required to provide preauthentication data. This seems to be a requirement that needs to call out.

4.section 1.2. the text says "This variant can be used in cases
   where the client can determine in advance that OTP pre-authentication
   is supported by the KDC and which OTP key should be used.". is there any deployment necessity to support cases where the client has a OTP token but does not know if the KDC supports OTP? This document provides a lot of options and that might be an interop testing challenge. If we can remove one of the variants, it would be nice. Need to ask the input from the group.

5. section 1.2. consider replacing "message" with preauth data since the data sent is not a separate message.

6.section 2.1. it is entirely unclear to me what does this section add to the document and how does it help to achieve interop.

   As described above, this document describes a generic system for
   supporting different OTP mechanisms in Kerberos pre-authentication.
   However, to ensure interoperability, all implementations of this
   specification SHOULD provide a mechanism for OTP mechanism support to
   be added or removed.

need input from the working group.

7. section 2.2. consider replace OLD:
   "it will respond with a KRB-ERROR message containing a PA-OTP-CHALLENGE in the PA-DATA.
   With NEW:
    it will respond with a KRB-ERROR message containing a PA-OTP-CHALLENGE in the PA-DATA within Kerbeoros FAST tunnel.

8. section 2.2. please provide forward reference to the structure definitions in section 4.

9. section 2.2. consider replace OLD:
In both cases, on receipt of a PA-OTP-REQUEST, the KDC generate the
   same keys as the client
with NEW:
In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the
   keys in the same way as the client does.

10. section 2.3, first paragraph. Need to guard against MITM if the armor is obtained via anonymous PKINIT without KDC authentication.
11. section 2.4. I would like to see a sentence or two to explain how this helps. For example the text from section 7.4 of rfc4226 would serve the purpose.

12. section 2.4. It says that the client "MUST" retry. Should it be "SHOULD"?

13. section 2.5. if the server wants the client to try the next two OTPs, should it just sends two ERROR messages in a row. Explicitly state that would allow the client correctly expect how many error it prepares to process.

14. section 3.4, last paragraph. missing a dot at the end.

15. section 3.6. the sname encoding. It would be easier to take the encoding from the Kerberos message. Consider replace OLD:
    sname is the UTF-8 encoding of the KDC's fully qualified domain
         name.  If the domain name is an Internationalized Domain Name
         then the value shall be the output of nameprep [RFC3491] as
         described in [RFC3490]
 with NEW:

sname is the DER encoding of the type PrincipalName for the sname field in the KDC-REQ message.

16. section 4. Nonce field is too short. Currently it is 4 bytes long.

17. typos. s/ tunnelled/ tunneled/, s/theme/them/

18. protocol issues: a. encData of PA-OTP-REQUST probably should be a "CHOICE".
  b. it is not clear to me how to fill the nonce field if it is the two-pass variant.
  c. otp-time and otp-value maynot appear at the same time, so this could be a choice.

19. section 5 needs to be rewritten to conform with IANA requirements.

20. OTPFormat is not defined in the main body of the document.

21. in the 4-pass variants, this seems to rely on a cookie. The document need to explain how does the KDC verify the KDC generated nonce is used otherwise. From the document it is not clear to me how this works.

Now as the protocol shepherd, I think the document overall is ready to be reviewed. I am starting a WGLC shortly on this document.

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

---

From: [email-masked]
Date: Tue, 29 Jul 2008 12:17:44 -0400

Larry,

Thanks for the comments.

> "challenge-response" based OPT systems?
OK, I will try and find one.

> 2. section 1.1. a discussion at Dublin today suggested 
> replace-reply-key is vulnerable to MITM if the armor is 
> obtained via anonymous PKINIT without KDC authentication. Sam 
> will provide an explanation to the list. The fix this, 
> consider replacing replying-reply-key with strengthen-reply-key.
> 
I don't think strengthen-reply-key will work since there is no shared
secret between the client and the KDC apart from the OTP seed record.

> 3. Section 1.2. the 4-pass variant does not work if the user 
> is not required to provide preauthentication data. This seems 
> to be a requirement that needs to call out.
> 
I will add text to section 1.2, raising this issue. Maybe something
along these lines

	"Note that this variant can only be used for users that
          require pre-authentication."

>    is supported by the KDC and which OTP key should be 
> used.". is there any deployment necessity to support cases 
> where the client has a OTP token but does not know if the KDC 
> supports OTP? This document provides a lot of options and 
> that might be an interop testing challenge. If we can remove 
> one of the variants, it would be nice. Need to ask the input 
> from the group.
> 
The two-pass mode is primarily intended to reduce the number of round
trips required by the full four-pass mode.  But to carry out the
two-pass exchange,  the client must know the OTP key used by a user and
the iteration count, hash algorithm and encryption type required by the
KDC.  Typically a user will only have one OTP token and the client could
be pre-configured with the other configuration parameters,
alternatively, the client can carry out an initial four-pass exchange
and cache the results, allowing to carry out two-pass exchanges from
then on.  

> 5. section 1.2. consider replacing "message" with preauth 
> data since the data sent is not a separate message.
> 
OK, changed.

> 6.section 2.1. it is entirely unclear to me what does this 
> section add to the document and how does it help to achieve interop.
> 
> 
This text was added at the request of the WG.

>     it will respond with a KRB-ERROR message containing a 
> PA-OTP-CHALLENGE in the PA-DATA within Kerbeoros FAST tunnel.
> 
Isn't it more that the PA-OTP-CHALLENGE will be returned within the
pa-value of a PA-AUTHENTICATION-SET-ELEM within the PA-DATA of a
KRB-ERROR?

> structure definitions in section 4.
OK, added the references.

>    keys in the same way as the client does.
OK, made change.

> 10. section 2.3, first paragraph. Need to guard against MITM 
> if the armor is obtained via anonymous PKINIT without KDC 
> authentication.
I will need to wait until the issue in FAST has been resolved.

> 11. section 2.4. I would like to see a sentence or two to 
> explain how this helps. For example the text from section 7.4 
> of rfc4226 would serve the purpose.
> 
How about this:

          It is possible with time and event-based tokens that the OTP
          server will lose synchronization with the current token
          state.  For example, event-based tokens may drift since the
          counter on the token is incremented every time the token is
          used but the counter on the server is only incremented on a
          successful authentication.  Similarly, the clocks on
          time-based tokens may drift.

> 12. section 2.4. It says that the client "MUST" retry. Should 
It is a MUST since the authentication will not succeed unless the "next"
token value is used.

> 13. section 2.5. if the server wants the client to try the 
> next two OTPs, should it just sends two ERROR messages in a 
> row. Explicitly state that would allow the client correctly 
> expect how many error it prepares to process.
> 
The current ID does not support sending multiple OTPs in a single
request to handle re-synchronisation (which is optional in RFC4226) but
instead uses the "next-OTP" option.  The client will therefore only ever
be asked for a single value.

> 14. section 3.4, last paragraph. missing a dot at the end.
Fixed.

> 15. section 3.6. the sname encoding. It would be easier to 
> take the encoding from the Kerberos message. Consider replace OLD:
The value of sname has to be something that is known both by the client
and the OTP server so that they can both use the values when generating
the hashed OTP values.  The OTP server could be used by more than KDCs
and so I was trying to avoid using a value that is too Kerberos
specific; hence the FQDN.   The DER encoding of the PrincipalName used
for the sname in the KDC-REQ would add Kerberos specifics to the
potential protocol used between the KDC and the OTP server.

> 16. section 4. Nonce field is too short. Currently it is 4 bytes long.
I used the UInt32 type used for nonce values in RFC4120.  What would you
suggest?

> 17. typos. s/ tunnelled/ tunneled/, s/theme/them/
Fixed.

> 18. protocol issues: 
>   a. encData of PA-OTP-REQUST probably should be a "CHOICE".
The encData in the PA-OTP-REQUEST is an EncryptedData that will contain
an encrypted PA-OTP-ENC-REQUEST if the client is working in 4-pass mode
or an encrypted PA-ENC-TS-REQ in 2-pass mode.  I am not sure if this
needs to be a CHOICE since the type of element encrypted in the encData
is determined by the form of the protocol being useed.

>   b. it is not clear to me how to fill the nonce field if it 
The client fills the nonce in the PA-OTP-REQUEST with a randomly
generated value in both the 2 and 4-pass modes.  The value provided by
the client is then returned encrypted by the KDC in the PA-OTP-RESPONSE

> so this could be a choice.
It is not use otp-time and otp-value, is more that otp-time and
otp-counter are redundant if otp-value is present in the PA-OTP-REQUEST.
The client can provide values for otp-time and otp-value to help the KDC
generate the same OTP value as the client.  If it instead provides the
KDC with the OTP value, it does not need to provide them but it does no
harm if it does. 

> 19. section 5 needs to be rewritten to conform with IANA requirements.
What is wrong with it?

> 20. OTPFormat is not defined in the main body of the document.
It is described in sections 3.3 and 4.2 and appears in the ASN.1 of the
Appendix.

> 21. in the 4-pass variants, this seems to rely on a cookie. 
> The document need to explain how does the KDC verify the KDC 
> generated nonce is used otherwise. From the document it is 
> not clear to me how this works.
> 
Yes, I was assuming that the KDC would include a PA-FX-COOKIE in its
responses to maintain any state it requires.  How about this text for
the second paragraph of section 3.2?

          The PA-OTP-CHALLENGE SHALL contain a random nonce value to
          be returned encrypted in the client response and the
          encryption type to be used by the client.  In order to allow
          it to maintain any state necessary to verify the returned
          nonce, the KDC SHOULD use the mechanism described in section
          6.3 of [ZhHa08].
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Thu, 31 Jul 2008 03:16:13 -0700

[email-masked] wrote:

> Larry zhu worte:

Consider using the PKINIT (RFC4556) style nonce. The following is cut&pasted from the relevant text of RFC4556:

       This nonce string MUST be as long as the
       longest key length of the symmetric key types that the client
       supports.  This nonce MUST be chosen randomly.
Let me know if this is not clear.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 29, 2008 9:18 AM
To: Larry Zhu; [email-masked]
Subject: Re: [Ietf-krb-wg] initial review of draft-ietf-krb-wg-otp-preauth-05

Larry,

Thanks for the comments.

OK, changed.

OK, made change.

How about this:

Fixed.

Fixed.

What is wrong with it?