Subject: [Ietf-krb-wg] PROTO review of draft-ietf-krb-wg-preauth-framework-08

From: Larry Zhu <[email-masked]>
Date: Tue, 18 Nov 2008 01:12:43 -0800

Here are my review comments for Gareth's OTP document. I compiled these while working on my PROTO write-up.

Most of the suggested changes are editorial. The following comments/issues must be addressed
before the document can be moved forward: a), b), f), i), j), m), o), u) v), z) and aa).
Out of these, I believe inputs from the working group are needed for a) and j).

a) I came to realize that event-based OTP systems are fundamentally different than time-based OTP systems.
Event-based OTP must be used in server-authenticated confidentiality-protected channels unless a zero
knowledge proof protocol is used. Failure to do so will mean that an attacker can pretend to be the KDC,
the attacker can then lure the user to authenticate and then crack the user's OTP based on the
 cipher text provided by the user, at that point the attacker can turn around to authenticate to the
real KDC and impersonate the user.

There is little value in using the event-based OTP values (or hashes) to authenticate the KDC.

The same problem seems to exist for challenge-response based OTP systems.

If the document takes the position that the fast channels must always be server-authenticated,
 then the KDC authentication facility does not seem to be needed.

In either case, I did not find it clear.

b) section 2.1, we have the following text:

   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.

Please consider replacing the above with

   As described above, this document describes a generic system for
   supporting different OTP mechanisms in Kerberos pre-authentication.
   To ensure interoperability, all implementations of this
   specification SHOULD provide a mechanism (e.g. a provider interface) to add
    or remove support for a particular OTP mechanism.

This is because it is not clear by the original text where the framework is removed
or added or just the support for a particular OTP mechanism is added or removed.

c) section 2.3. PIN, acronyms need to be expanded on first use

d) the last paragraph seems disconnected from the rest of the section. Is this
paragraph intentional or just left-over?

e) section 2.4, the following sentence does not parse.

  client SHOULD re-try the authentication using the OTP for the token
   "state" after that used in the failed authentication attempt.

f) section 3.2. the following text is unnecessarily too restrictive since OTP can
be one of many authentication factors.

   If the user is required to authenticate using an OTP then the KDC
   SHALL respond to the initial AS-REQ with a KRB-ERROR containing:

   o  An error code of KDC_ERR_PREAUTH_REQUIRED

   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.

Alternatively, if the OTP mechanism is required as part of an
   authentication set then KDC SHOULD respond with a PA-AUTHENTICATION-
   SET as described in section 6.4 of [ZhHa08].  In this case, the PA-
   OTP-CHALLENGE SHALL be returned within the pa-data of a PA-
   AUTHENTICATION-SET-ELEM

Consider replacing the above with the following:

   If the user is required to authenticate using an OTP then the KDC
   SHALL include a PA-OTP-CHALLENGE in the error reply per [ZhHa08].

g) section 3.5, typo, s/fromy/from/

h) section 3.2, typo, s/an server generated challenge/a server generated challenge/

i) section 3.3, this is related to a), it is not clear to me what is the life time of an event-based OTP.

   It
   is RECOMMENDED that the iteration count used by the client be chosen
   in such a way that it is computationally infeasible/unattractive for
   an attacker to brute-force search for the given OTP within the
   lifetime of that OTP.

j) section 3.4, should we indicate to the client the error conditions so that the client can differentiate them?

 The KDC generates the Client Key and Reply Key as described in
   Section 3.6 from the OTP value using the hash algorithm and iteration
   count if present in the PA-OTP-REQUEST.  However, the client
   authentication MUST fail if the KDC requires hashed OTP values and
   the hashAlg field was not present in the PA-OTP-REQUEST, if the hash
   algorithm identifier or the value of iterationCount included in the
   PA-OTP-REQUEST do not conform to local KDC policy or if the value of
   the iterationCount is less than that specified in the PA-OTP-
   CHALLENGE.

k) section 3.4, is it intentional to allow the encryption type that is not listed in the KDC challenge?

 The authentication MUST fail if the encryption type used by the
   client in the encData does not conform to KDC policy.

l) section 4.1, iterationCount is a INTEGRER, not Int32, is that intentional?

m) section 3.4, with the text below, how does the KDC indicate to the user the
PIN has expired if PA-OTP-PIN-CHANGE is not included?

   If during the authentication process, the KDC determines that the
   user's PIN has expired then it MAY include a PA-OTP-PIN-CHANGE in the
   response as described in Section 2.3.

Can the KDC include the PA-OTP-PIN-CHANGE before the PIN expires but after, say 80% of lifetime has reached?

n) Section 3.6, missing a "." at the end?

     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]

o) section 3.6, base64 does not yield unique encoding. Any characters outside
of the base64 alphabet are to be ignored in
   base64-encoded data. we need to make sure the encoding is unique before hashing.

The fix can be extracting only the base64 alphabets from the encoded data before hashing.

   The value of K2 is then derived from the base64 [RFC2045] encoding
      of this final hash value.

             K2 = string-to-key(Base64(H')||"Krb-preAuth")

Also lower case 'b' in "base4(H')"?

p) section 4.1, an extra ";" at the end?

      PA_OTP_CHALLENGE     131;

r) section 4.1, the following text does not seem to allow the use of hashes of OTP values.

   The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in
   the PA-DATA of a KRB-ERROR when pre-authentication using an OTP value
   is required.

The rest of the document seems to differentiate the hash of OTP values vs
just the OTP values, that can lead to confusions what is supported here.

s) section 4.1, "DER" need to be expanded on first use and references should be provided.

t) section 4.1, the following text does not parse.

   the Client Key and MUST be chosen
      randomly.

u) section 4.2, the OTP service and the OTP length are in the challenge, but
not in the request. How does the KDC figure out which choices the client made? Or does that matter?

v) section 4.4, the following text is unclear. How does the user make use of the
PIN field provided by the KDC?

 If the pin field is present then it
   contains a PIN value that MAY be used by the user when changing the
   PIN.

x) section 6.1, an extra "the" in "the the key generation"

y) section 6.3, it says "as described in Section 3.4", but I could not find relevant
text in section 3.4. This seems to be the only place where it is mentioned that
the KDC should reject too-large iteration counts.

z) section 6.4, It is not clear how to meet the following requirements when there are more than one KDC.

  To reduce the chance
   of replay attacks, the KDC must check that the client time used in
   such a request is later than that used in previous requests.

aa) the example in 8.3 seems wrong. The client asks for a TGT but gets a ticket to the key-change
service instead. This is not allowed by the KDC.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Nov 2008 11:14:26 -0600

--On Tuesday, November 18, 2008 01:12:43 AM -0800 Larry Zhu 
<[email-masked]> wrote:

> Most of the suggested changes are editorial. The following
> comments/issues must be addressed before the document can be moved
> forward: a), b), f), i), j), m), o), u) v), z) and aa)

I'd say (c) and (s) also need to be in that list.

> f) section 3.2. the following text is unnecessarily too restrictive since
> OTP can be one of many authentication factors.
>

It's not clear to me what the problem is here.  Your phrasing is certainly 
more condensed, as it incorporates from ZhHa08 the details about what to do 
when OTP is the only required mech versus when it is part of a set.  But I 
don't think the current text is too restrictive; it says what the KDC MUST 
do when OTP _is_ required, and says nothing about when it is not required.

>    an attacker to brute-force search for the given OTP within the

Presumably it will be clear to whoever is selecting the iteration count. 
The "lifetime" here is not a protocol value; it's just the expected time 
that the password will be usable.  This could be the result of policy 
requiring periodic resets, or even just a user who knows that he 
authenticates at least once a day, and so any given OTP won't be valid for 
longer than a day.

> m) section 3.4, with the text below, how does the KDC indicate to the
> user the PIN has expired if PA-OTP-PIN-CHANGE is not included?
>

I don't think it does.  I read the quoted text as saying that including 
PA-OTP-PIN-CHANGE is the mechanism for signalling that the PIN is expired, 
and that using that mechanism at all is optional.  The KDC could just as 
easily simply fail the authentication (perhaps with KDC_ERR_PREAUTH_FAILED 
or KDC_ERR_KEY_EXPIRED).

> after, say 80% of lifetime has reached?

Good question.

> o) section 3.6, base64 does not yield unique encoding.

Sure it does.

> Any characters
> outside of the base64 alphabet are to be ignored in
>    base64-encoded data.

... in decoding there of, but that doesn't matter here.  A compliant 
encoder will not generate any such characters.  Saying "encode as base64, 
then hash" is quite sufficient; the first step always produces the same 
output if done correctly.  We've used this in other scenarios where a 
unique encoding is required, such as naming of SASL mechanisms and SSH key 
exchange methods, without needing any additional text.

Recall that the base64 value in question is one which is generated 
immediately before being used, not one which was received from some 
external party.

Perhaps we need test vectors?

> v) section 4.4, the following text is unclear. How does the user make use
> of the PIN field provided by the KDC?
>

Perhaps this is a suggested random PIN the user could use?

> y) section 6.3, it says "as described in Section 3.4", but I could not
> find relevant text in section 3.4. This seems to be the only place where
> it is mentioned that the KDC should reject too-large iteration counts.

> aa) the example in 8.3 seems wrong. The client asks for a TGT but gets a
> ticket to the key-change service instead. This is not allowed by the KDC.

What do you mean, "not allowed by the KDC" ?  Since the KDC is the one 
generating the ticket, clearly it _was_ allowed by the KDC.

Unless you mean, "the KDC is not allowed to do that", in which case, the 
text in section 2.3 contradicts you, by prohibiting the KDC from returning 
a TGT and RECOMMENDing that it return a ticket for the PIN change service.

Incidentally, the text in 2.3 is IMHO not quite sufficient, in that it 
prohibits returning a TGT but does not prohibit returning a ticket for some 
other service, if that was what the client requested.  Recall that there is 
no requirement that initial tickets be for the TGS.

-- Jeff

---

From: [email-masked]
Date: Thu, 20 Nov 2008 06:24:26 -0500

Larry,

Thanks for the review comments, responses are inline.

> 
> Here are my review comments for Gareth's OTP document. I 
> compiled these while working on my PROTO write-up.
> 
> comments/issues must be addressed before the document can be 
> moved forward: a), b), f), i), j), m), o), u) v), z) and aa).
> a) I came to realize that event-based OTP systems are 
> fundamentally different than time-based OTP systems.
> Event-based OTP must be used in server-authenticated 
> confidentiality-protected channels unless a zero knowledge 
> proof protocol is used. Failure to do so will mean that an 
> attacker can pretend to be the KDC, the attacker can then 
> lure the user to authenticate and then crack the user's OTP 
> based on the  cipher text provided by the user, at that point 
> the attacker can turn around to authenticate to the real KDC 
> and impersonate the user.
> 
> 
> If the document takes the position that the fast channels 
> must always be server-authenticated,  then the KDC 
> authentication facility does not seem to be needed.
> 
In section 6.1, it currently says that due to the possibility of MITM
attacks that:

   It is therefore recommended that anonymous PKINIT not be used with
   OTP algorithms that require the OTP value to be sent to the KDC and
   that careful consideration be made of the security implications
   before it is used with other algorithms.

In the case of event-based OTPs, the OTP value is potentially open to
attack until the user has used other values and so they are potentially
more vulnerable that time-based OTPs in the way that you describe.
Higher strength OTPs from connected tokens or combination algorithms
such as time+counter can mitigate these issues.

Maybe I should change the wording of the above paragraph to include some
text regarding the strength of the OTP value.

The final PA-OTP-CONFIRM sent by the KDC in this system is mainly to
confirm that the reply key has been changed successfully as required by
section 4.3 of FAST.

> This is because it is not clear by the original text where 
> the framework is removed or added or just the support for a 
> particular OTP mechanism is added or removed.
> 
I have changed the text.

> c) section 2.3. PIN, acronyms need to be expanded on first use
Fixed in section 1.1

> d) the last paragraph seems disconnected from the rest of the 
> section. Is this paragraph intentional or just left-over?
> 
This paragraph is covering the case where the user's PIN has been
changed by the OTP Server/KDC and a PA-OTP-PIN-CHANGE is returned with
the new PIN value.  In this case it is OK for the KDC to return the TGT
as usual.

>    "state" after that used in the failed authentication attempt.
The full sentence is:

   If this flag is set then the
   client SHOULD re-try the authentication using the OTP for the token
   "state" after that used in the failed authentication attempt.
 
It is stating that if the "nextOTP" flag is set then the client should
attempt to authenticate a second time using an OTP value generated by
the token in its "next" state.  E.g. next time interval or counter
value.

> f) section 3.2. the following text is unnecessarily too 
> restrictive since OTP can be one of many authentication factors.
> 
I was trying to be explicit here about what is required when OTP
authentication is required on its own or part of a set. 

> g) section 3.5, typo, s/fromy/from/
Fixed

> server generated challenge/
Fixed

> i) section 3.3, this is related to a), it is not clear to me 
> what is the life time of an event-based OTP.
> 
>    It
As Jeff said in his reply, this is really just meant to mean that the
iteration count should be such that it is infeasable to break the OTP
value within the time that that OTP value could be used.  Maybe I should
remove the last part of that sentence.
	
	It is RECOMMENDED that the iteration count used by the client 
 	be chosen in such a way that it is computationally 
	infeasible/unattractive for an attacker to brute-force search 
	for the given OTP.

> j) section 3.4, should we indicate to the client the error 
> conditions so that the client can differentiate them?
> 
I'll need WG input on this one.

> k) section 3.4, is it intentional to allow the encryption 
> type that is not listed in the KDC challenge?
> 
If the authentication is using the 2-pass model then the PA-OTP-REQUEST
would not be sent in response to a KDC challenge and so the idea was
that
the KDC would need to compare the encryption type used by the client 
against a local policy.

> l) section 4.1, iterationCount is a INTEGRER, not Int32, is 
No, I'll change it in sections 4.1 and 4.2.

> m) section 3.4, with the text below, how does the KDC 
> indicate to the user the PIN has expired if PA-OTP-PIN-CHANGE 
> is not included?
> 
> Can the KDC include the PA-OTP-PIN-CHANGE before the PIN 
> expires but after, say 80% of lifetime has reached?
> 
I would be reluctant to add support for this since I don't think 
some OTP servers support it.

>          then the value shall be the output of nameprep [RFC3491] as
Fixed

> o) section 3.6, base64 does not yield unique encoding. Any 
> characters outside of the base64 alphabet are to be ignored in
I agree with Jeff here, wouldn't this only be a potential issue if we
were decoding?

> p) section 4.1, an extra ";" at the end?
Fixed.  
Also fixed the same error in section 4.2.

> The rest of the document seems to differentiate the hash of 
> OTP values vs just the OTP values, that can lead to 
> confusions what is supported here.
> 
How about if I change this to:

          The PA_OTP_CHALLENGE padata type is sent by the KDC to the
          client in the PA-DATA of a KRB-ERROR when OTP
pre-authentication
          is required.

> references should be provided.
Fixed, also added reference to X690.

>    the Client Key and MUST be chosen
Fixed

> u) section 4.2, the OTP service and the OTP length are in the 
> challenge, but not in the request. How does the KDC figure 
> out which choices the client made? Or does that matter?
> 
The idea behind the otp-service in the PA-OTP-CHALLENGE is to help the
client to locate the OTP key to use.  Once the key is found, it is
identified in the PA-OTP-REQUEST using the otp-keyID.  If a token has
multiple OTP keys then each key could be labeled by a service
representing the service for which it should be used. The assumption was
that there would be a one-to-one mapping.  If this is not the case then
it would be required in the PA-OTP-REQUEST.

The otp-length can be sent by the KDC to the client to support the case
where the user's token can generate OTP values of different lengths.
For example, the standard length values when disconnected but longer
values when connected.  The otp-length value is not required in the
PA-OTP-REQUEST as the OTP Server can iterate through the possible values
but it would make its job easier.  On the other it could also provide
information to an attacker since it would allow the attacker to target
shorter OTP values.  I am therefore a bit reluctant to add it.

> v) section 4.4, the following text is unclear. How does the 
> user make use of the PIN field provided by the KDC?
> 
This is to allow for the case where the user must change their PIN and
the KDC has generated a PIN that could be used.  The user may use this,
suggested, PIN or select their own.

> x) section 6.1, an extra "the" in "the the key generation"
Fixed

> y) section 6.3, it says "as described in Section 3.4", but I 
> could not find relevant text in section 3.4. This seems to be 
> the only place where it is mentioned that the KDC should 
> reject too-large iteration counts.
> 
Section 3.4 says that:

   However, the client

The idea is that the KDC must fail any authentication requests where the
iterationCount specified by the client does not conform to the local
policy.  That is, if it is too small or too large.

> z) section 6.4, It is not clear how to meet the following 
> requirements when there are more than one KDC.
> 
>   To reduce the chance
Doesn't the same issue apply to the standard encrypted password method?
How does it resolve this problem.

> aa) the example in 8.3 seems wrong. The client asks for a TGT 
> but gets a ticket to the key-change service instead. This is 
> not allowed by the KDC.
> 
I thought this was allowed.

--Gareth

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 20 Nov 2008 09:43:45 -0800

> some OTP servers support it.

If the KDC doesn't return PA-OTP-PIN-CHANGE, then it returns what it 
would have returned for an ordinary expired password.

The KDC MAY return PA-OTP-PIN-CHANGE prior to actual PIN expiration 
based on local policy and OTP mechanism capabilities.

-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Nov 2008 11:44:00 -0600

> some OTP servers support it.

Why not define the format of PA-OTP-PIN-CHANGE such that the KDC can 
indicate how much life is left, in some combination of seconds or number of 
uses or fraction of total lifetime.  For OTP mechanisms where the KDC can 
tell a PIN will expire soon, the KDC MAY report that; for those which don't 
support it, it just won't get reported until the PIN actually expires.

-- Jeff

---

From: [email-masked]
Date: Fri, 21 Nov 2008 04:46:08 -0500

> >> > indicate to the user the PIN has expired if PA-OTP-PIN-CHANGE is 
> >> > not included?
> >> >
> >> >    user's PIN has expired then it MAY include a 
> PA-OTP-PIN-CHANGE 
> >> > in the
> >> > Can the KDC include the PA-OTP-PIN-CHANGE before the PIN expires 
> >> > but after, say 80% of lifetime has reached?
> >> >
> > I would be reluctant to add support for this since I don't 
> think some 
> > OTP servers support it.
> 
> If the KDC doesn't return PA-OTP-PIN-CHANGE, then it returns 
> what it would have returned for an ordinary expired password.
> 
> The KDC MAY return PA-OTP-PIN-CHANGE prior to actual PIN 
> expiration based on local policy and OTP mechanism capabilities.
> 

Are you suggesting a change in the text for section 3.4?  
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: [email-masked]
Date: Fri, 21 Nov 2008 04:48:55 -0500

> indicate to the 
> PA-OTP-PIN-CHANGE in 
> >> the
> Why not define the format of PA-OTP-PIN-CHANGE such that the 
> KDC can indicate how much life is left, in some combination 
> of seconds or number of uses or fraction of total lifetime.  
> For OTP mechanisms where the KDC can tell a PIN will expire 
> soon, the KDC MAY report that; for those which don't support 
> it, it just won't get reported until the PIN actually expires.
> 

I suppose this would work but is it really required?  Is it really
necessary to complicate the protocol in this way?

--Gareth

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Nov 2008 23:58:33 -0600

> necessary to complicate the protocol in this way?

I have no particular opinion; I was simply suggesting a way to achieve what 
Henry wants on servers that can do it, without breaking those that can't. 
The question of whether the extra complexity is warranted is up to you and 
to the working group.

-- Jeff