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

From: [email-masked]
Date: Fri, 1 Aug 2008 07:08:42 -0400

Larry,

How about the following change?

Change the nonce values in PA-OTP-CHALLENGE etc from 

      nonce     UInt32,

to

       nonce ::= OCTET STRING

And add the following text for the description of the nonce in section
4.1:

              A KDC-supplied nonce value to be encrypted by the client
              in the PA-OTP-REQUEST.  This nonce MUST be as long as the
		  Client Key and MUST be chosen randomly.

With similar text in section 4.2.

--Gareth 

> 
> > Larry zhu worte:
> > > 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?
> 
> 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.
> 
> > 1. section 1.1. can you provide a reference to "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."
> 
> 
> > 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.
> >
> 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.
> >
> >
> >    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.
> >
> This text was added at the request of the WG.
> 
> 
> > 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.
> >
> 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?
> 
> 
> 
> > 8. section 2.2. please provide forward reference to the structure 
> > definitions in section 4.
> >
> OK, added the references.
> 
> 
> > 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.
> >
> 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 be "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:
> >     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.
> >
> 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
> > is the two-pass variant.
> 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
> 
> >   c. otp-time and otp-value maynot appear at the same time,
> > 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
> 
> 
> 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Wed, 20 Aug 2008 23:50:20 -0700

>                 Client Key and MUST be chosen randomly.
Can you refresh my memory what is the "client key"? why not just use
the RFC4556 language/text.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 01, 2008 4:09 AM
To: Larry Zhu; [email-masked]
Subject: Re: [Ietf-krb-wg] initial review of draft-ietf-krb-wg-otp-preauth-05

Larry,

      nonce     UInt32,

to

       nonce ::= OCTET STRING

--Gareth

---

From: [email-masked]
Date: Thu, 21 Aug 2008 06:44:45 -0400

> Can you refresh my memory what is the "client key"? why not 
> just use the RFC4556 language/text.
> 

The Client Key is a key generated by the client and KDC from the Armor
Key and OTP value that is used by the client to encrypt the nonce value
sent by the KDC in the PA-OTP-CHALLENGE.

I could use the RFC4556 text.  The only reason I changed it was to
clarify that the nonce should be as large as the actual key used.

--Gareth

> > Consider using the PKINIT (RFC4556) style nonce. The following is 
> > cut&pasted from the relevant text of RFC4556:
> >
> no shared 
> > secret between the client and the KDC apart from the OTP 
> seed record.
> >
> > I will add text to section 1.2, raising this issue. Maybe something 
> > along these lines
> >
> > 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 
> > 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?
> >
> >
> >
> > > 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:
> >
> > > 12. section 2.4. It says that the client "MUST" retry. 
> Should it be 
> > > "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.
> > >
> > instead uses the "next-OTP" option.  The client will therefore only 
> > ever be asked for a single value.
> >
> > > 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 DER encoding of the type PrincipalName for the sname 
> > > field in the KDC-REQ message.
> > >
> > 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
> > 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 is the 
> > > two-pass variant.
> > >   c. otp-time and otp-value maynot appear at the same 
> time, so this 
> > > could be a choice.
> > >
> 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.
> >
> >
> > > generated nonce is used otherwise. From the document it 
> is not clear 
> > > to me how this works.
> > >

---

From: [email-masked]
Date: Thu, 21 Aug 2008 08:04:56 -0400

The OTP pre-auth ID needs a registry for OTP algorithm identifiers but
KEYPROV will need a similar registry.  They have specified its
requirements and initial values for OTP algorithms in section 8.4.4 of
draft-ietf-keyprov-portable-symmetric-key-container-05.txt.

Would it be appropriate to include an informal citation to the KEYPROV
I-D and to update the IANA Considerations in the OTP I-D to point to the
new registry?  

--Gareth