Subject: [Ietf-krb-wg] review of draft-ietf-krb-wg-otp-preauth-02.txt

From: Larry Zhu <[email-masked]>
Date: Sun, 27 Jan 2008 22:17:00 -0800

As an individual, I have the following comments.

0) overall, I think the document needs to populate with more details so that it is implementable. For example, on page 9, currently it does not say what encoding is applied to sname before applying the hash function. Some additional nits are: it encodes etype as INTEGER, but RFC4120 says INT32; I do not understand why otp-length is an INTEGER, not Int32. I understand these comments would make more sense when the document gets closer to publication.

1) the document should provide normative references describing the OTP algorithms and how re-synchronization works or define the algorithms. The ID attempts to define a method that works with any OTP system, it would be helpful to test if it works with the OTP defined in RFC2289. This can be illustrated as an example protocol implementation. At minimal, it should specify which types of OTP systems are expected to work with this protocol. If the reader wants to find out more about OTP systems, this document should provide the reference to point the reader how to find out more.

2) section 2, the use of "INITIAL" ticket is not consistent with RFC4120. I believe the intention of the author is to allow the user to obtain an "initial" service ticket to the PIN change service with an expired PIN but the current text does not seem to be clear on that.

3) section 3.6, it is not clear to me why an iteration of hash operations are applied. It probably helps to explain this if the implementation need to pick a value for the iterationCount.

4) Key usage values must be described in the main body of the text, currently the values are mentioned in the ASN.1 comments only.

5) The ID calls into string-to-key() but does not specify the value of the iteration count. The text does mention that the salt and additional parameters for string-to-key will be as defined in section 3.1.3 of [RFC4120]. Does this imply the iteration count of the OTP is the same as the user password? This could be a rather counter-intuitively in the cases the KDC cannot know the OTP value or the degree of unpredictability of the OTP.

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

---

From: "Richards, Gareth" <[email-masked]>
Date: Mon, 28 Jan 2008 11:38:00 -0000

> 
> 0) overall, I think the document needs to populate with more 
> details so that it is implementable. For example, on page 9, 
> currently it does not say what encoding is applied to sname 
> before applying the hash function. Some additional nits are: 
> it encodes etype as INTEGER, but RFC4120 says INT32; I do not 
> understand why otp-length is an INTEGER, not Int32. I 
> understand these comments would make more sense when the 
> document gets closer to publication.
> 

I have updated section 3.6 to state that the sname in 

H = hash(sname|nonce|OTP) 

Is the byte values of the UTF-8 encoding of the KDC's principal name.
Would this clear that up.

I have fixed the error where etype was encoded as an INTEGER and I have
made otp-length an Int32 as suggested.

> 1) the document should provide normative references 
> describing the OTP algorithms and how re-synchronization 
> works or define the algorithms. The ID attempts to define a 
> method that works with any OTP system, it would be helpful to 
> test if it works with the OTP defined in RFC2289. This can be 
> illustrated as an example protocol implementation. At 
> minimal, it should specify which types of OTP systems are 
> expected to work with this protocol. If the reader wants to 
> find out more about OTP systems, this document should provide 
> the reference to point the reader how to find out more.
> 
I am not sure about this issue since, as you point out, I have been
trying to make the ID independent of the particular OTP method.  How
about if I stated that the system is designed to work with time-based,
challenge-response, event-based and RFC2289 OTP algorithms?  

To clarify things I could add an appendix with example exchanges similar
to Appendix B of RFC4793.

> 2) section 2, the use of "INITIAL" ticket is not consistent 
> with RFC4120. I believe the intention of the author is to 
> allow the user to obtain an "initial" service ticket to the 
> PIN change service with an expired PIN but the current text 
> does not seem to be clear on that.
> 
Yes, the recommendation is that if PIN change is required and a PIN
change service is used, that the KDC should return a ticket for that
service with the "initial" flag set rather than returning a TGT.  I will
try and clarify this.   

> 3) section 3.6, it is not clear to me why an iteration of 
> hash operations are applied. It probably helps to explain 
> this if the implementation need to pick a value for the 
> iterationCount.
> 
The iterationCount is used to harden the OTP value used in the key
generation by making it computationally more expensive to crack the OTP
value.  The idea is that the OTP Server (or KDC) can dictate a minimum
value for this iterationCount and the client can either select that or a
higher value.  

> 4) Key usage values must be described in the main body of the 
> text, currently the values are mentioned in the ASN.1 comments only.
> 
OK

> 5) The ID calls into string-to-key() but does not specify the 
> value of the iteration count. The text does mention that the 
> salt and additional parameters for string-to-key will be as 
> defined in section 3.1.3 of [RFC4120]. Does this imply the 
> iteration count of the OTP is the same as the user password? 
> This could be a rather counter-intuitively in the cases the 
> KDC cannot know the OTP value or the degree of 
> unpredictability of the OTP.
> 
The intention was the proposal would not alter the way that
string-to-key functions but have the paramaters either be the default of
the cipher suite or those given by the sk2params of the PA-ETYPE-INFO2.
The iteration count for the OTP would be specified by the client in the
PA-OTP-REQUEST while that for string-to-key would come from the
s2kparams.

---

From: Larry Zhu <[email-masked]>
Date: Mon, 28 Jan 2008 09:51:56 -0800

> Would this clear that up.

UTF8 alone does not guarantee a unique encoding, think of normalization rules in unicode. It would be a lot easier to say you hash over the DER encoding of the ANS.1 type as it appears in the AS-REQ message. This allows you get around the messy I18N issues in Kerberos. Take a look at RFc4556 and pay attention to the language used in the description of the KDF.

> PA-OTP-REQUEST while that for string-to-key would come from the

Sure how does the client discover the s2kparams if it does not already know it? Once I can understand the abstraction model, I may be able to provide more intelligent comments than this.

> value for this iterationCount and the client can either select that or a

Why not use PBKDF2 here?

> to Appendix B of RFC4793.

That would help. If there are public literatures on each of the systems, it would help to include the references. That would help me understand the draft and the protocol.

> service with the "initial" flag set rather than returning a TGT.  I will

You are requesting a service ticket to the PIN change service, not the TGT, right?

It is important to let the PIN change service always requires a service ticket with "initial" bit. This way, someone who walks over to an unlocked workstation does not get the ability to change the PIN, she has to present the existing PIN (in order to get the "initial" ticket) if she wants to change the PIN.
--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richards, Gareth
Sent: Monday, January 28, 2008 3:38 AM
To: Larry Zhu; [email-masked]
Subject: Re: [Ietf-krb-wg] review of draft-ietf-krb-wg-otp-preauth-02.txt

OK

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 28 Jan 2008 13:46:50 -0500

--On Sunday, January 27, 2008 10:17:00 PM -0800 Larry Zhu 
<[email-masked]> wrote:

> 1) the document should provide normative references describing the OTP
> algorithms and how re-synchronization works or define the algorithms. The
> ID attempts to define a method that works with any OTP system, it would
> be helpful to test if it works with the OTP defined in RFC2289. This can
> be illustrated as an example protocol implementation. At minimal, it
> should specify which types of OTP systems are expected to work with this
> protocol. If the reader wants to find out more about OTP systems, this
> document should provide the reference to point the reader how to find out
> more.

Hm.  A normative reference is not required, since no particular OTP 
mechanism need be understood or implemented in order to implement this 
extension.  Thus, any references to descriptions of specific mechanisms 
would be informative.  However, I agree with Larry that it would be good to 
demonstrate that it is possible to use this extension with the RFC2289 
mechanism.  It also might not hurt to look at RFC4226, which describes an 
OTP mechanism with somewhat different properties.

However, this raises another issue.  Any implementation of this 
specification (client or KDC) will support only specific OTP mechanisms. 
That means that in order to insure interoperability, we must have at least 
one mandatory-to-implement OTP mechanism.  I'm inclined to suggest using 
the one defined in RFC2289.

> 5) The ID calls into string-to-key() but does not specify the value of
> the iteration count

Per RFC3961, string-to-key does not take an iteration count argument.  It 
requires a "string-to-key parameters" argument, which is an octet string 
whose meaning is enctype-specific.  For the AES enctypes defined in 
RFC3962, this happens to be an iteration count; for other enctypes it may 
have other meanings or do nothing at all.

> The text does mention that the salt and additional
> parameters for string-to-key will be as defined in section 3.1.3 of
> [RFC4120]. Does this imply the iteration count of the OTP is the same as
> the user password?

No.  It implies the salt and string-to-key parameters used to derive K2 
will be derived in the fashion described in RFC4120 section 3.1.3; that is, 
from preauth data such as PA-PW-SALT, PA-ETYPE-INFO, etc, or using the 
default values for salt as described in RFC4120 section 4 and for 
string-to-key parameters as defined by the particular enctype.

The OTP iteraction count has nothing to do with the iteration count encoded 
in the string-to-key parameters of the AES enctypes defined in RFC3962.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 28 Jan 2008 12:11:40 -0800

> the one defined in RFC2289.

 From an IETF policy standpoint I understand.  However any real  
deployment of this protocol is likely to only support an  
institutionally-mandated OTP mechanism.  I don't think you can/should  
mandate that all institutions that want to use any OTP with Kerberos  
must/should support e.g. RFC2289, and that would seem to be implied.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Jan 2008 14:17:14 -0600

> must/should support e.g. RFC2289, and that would seem to be implied.

Any RFC aiming for Proposed Standard or better has to specify a set of
implementation requirements such that any two implementations be able to
interop on basic functionality.

We could require implementation of any one OTP, but we should require
implementation of an OTP for which there are specifications that can be
normatively referenced.  Also, we should require implementatio of an OTP
that most implementors can implement (think IPR).

I think that means, here, that an OTP that is on the Internet Standards
Track should be REQUIRED to implement, such as RFC2289.

This does not mean that other OTPs cannot be implemented, nor that
interop with a *deployed* OTP is unlikely should that OTP not be the
required-to-implement OTP.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 28 Jan 2008 16:03:14 -0500

> must/should support e.g. RFC2289, and that would seem to be implied.

Not at all.  As always, the requirement is that implementations support it, 
not that operators deploy it.  The idea is that anyone who wants to can 
take an off-the-shelf KDC and an array of off-the-shelf clients and get 
working OTP.  In practice, I would expect many implementations to support 
some means of plugging in OTP mechansims.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 28 Jan 2008 13:12:27 -0800

> required-to-implement OTP.

I think you're saying that the implementation must be interoperable,  
but a specific deployment may not be, if the institution chooses not  
to deploy the guaranteed-interoperable mechanism.  I accept that as  
being the best that the IETF can do in practice.

Is it appropriate to say that implementations SHOULD provide a plug- 
in interface to allow proprietary mechanisms to be added?  Is there a  
way to make such a statement so that it encourages interoperability  
of extension mechanisms rather than just providing a non- 
interoperable extension?  I forsee a rathole and you can tell me to  
shut up now.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Jan 2008 15:16:29 -0600

> being the best that the IETF can do in practice.

Correct.

> in interface to allow proprietary mechanisms to be added?  Is there a  

I think so.

> interoperable extension?  I forsee a rathole and you can tell me to  

I think we can have SHOULD-have-a-pluggable-interface text.  We could
even say nothing about what the plug-in interfaces should look like
abstractly (though I would prefer having an abstract interface, mostly
as a tool to help review the spec itself).  But we can't require that
there be useful plug-ins for any one implementation.  And on some
systems the very notion of plug-in may not be applicable (so we can't
REQUIRE it).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 30 Jan 2008 10:36:00 -0000

I just wanted to make sure that I have captured the consensus regarding
specifying OTP mechanisms.

1. From the start, I have tried to make the I-D independent of OTP
mechanisms (e.g. the time-based SecurID, the counter-based HOTP (RFC
4226), RFC2289 and challenge-response tokens) and I think it was agreed
that it should remain this way.  However, it should state that it is
designed to work with different OTP mechanisms and give informational
references when possible.

2. To support interoperability, there should be at least one mandatory
to implement OTP mechanism and the most likely contender is RFC2289.

3. In order to allow mechanisms to be added, the I-D should state that
any implementations SHOULD support a pluggable interface.

4. Finally, to help clarify things, it would help if the I-D contained
example exchanges similar to Appendix B of RFC4793.

I think that captures what was discussed.

--Gareth