Subject: [Ietf-krb-wg] OTP 4-pass nonce

From: [email-masked]
Date: Sun, 17 Jul 2011 14:59:20 -0400 (EDT)

My understanding is that OTP preauth is awaiting another working group
last call.  If I'm wrong and it is already past last call, then this
issue can probably be ignored.

In OTP 4-pass mode, the KDC is supposed to choose a nonce and the
client is supposed to encrypt the nonce in the generated key.  The
draft says:

  In order to allow it to maintain any state necessary to verify the
  returned nonce, the KDC SHOULD use the mechanism described in
  section 5.2 of [RFC6113].

This text suggests that the implementor has a responsibility to ensure
that the nonce used in the request matches the nonce in the challenge.
I don't think that's really necessary--we let the client choose the
value to encrypt in OTP 2-pass mode and in encrypted challenge--and
it's also extremely difficult to ensure when there are multiple KDCs.
A KDC can ensure that the nonce value was generated by the KDC at some
point in the recent past, but cannot prevent replays within a time
window.

So, what is the purpose of the KDC generating a nonce?  What threats
does it prevent, versus just having the client encrypt a timestamp?
Is it unnecessary complexity?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 18 Jul 2011 05:20:19 -0400

The main purpose of the KDC nonce is to allow the KDC to authenticate the client in a way that prevents replay by binding it to the PA-OTP-CHALLENGE.  In the 2-pass mode there is no challenge and so the timestamp is used instead.

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of [email-masked]
> Sent: 17 July 2011 19:59
> To: [email-masked]
> Subject: [Ietf-krb-wg] OTP 4-pass nonce
>

---

From: Greg Hudson <[email-masked]>
Date: Mon, 18 Jul 2011 09:13:09 -0400

On Mon, 2011-07-18 at 05:20 -0400, [email-masked] wrote:
> The main purpose of the KDC nonce is to allow the KDC to authenticate
> the client in a way that prevents replay by binding it to the
> PA-OTP-CHALLENGE.  In the 2-pass mode there is no challenge and so the
> timestamp is used instead.

Why is this a useful binding?

My understanding is that the only purpose of "authenticating" a client
in preauth is making the client prove knowledge of the client secret
before supplying a ciphertext which can be used in an offline attack.
It doesn't matter whether this proof is fresh because an attacker who
has a ciphertext (new or old) already has what you need for an offline
attack.  (FAST, of course, makes it difficult to observe an old
ciphertext without knowing the armor key.)

Securely binding an OTP request to the challenge is very difficult in a
multi-KDC environment.  If there is no interesting benefit to this
binding, I find it harmful to have language in the spec suggesting that
implementors should bend over backwards to do it.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 12:12:45 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Mon, 2011-07-18 at 05:20 -0400, [email-masked] wrote:
    >> The main purpose of the KDC nonce is to allow the KDC to
    >> authenticate the client in a way that prevents replay by binding
    >> it to the PA-OTP-CHALLENGE.  In the 2-pass mode there is no
    >> challenge and so the timestamp is used instead.

    Greg> Why is this a useful binding?

As a matter of process, OTP has reached WG consensus but I don't think
has been sent to the IESG.  I think there was a failed hand-off from
Larry to me on this document.

You can raise this issue in IETF.

Speaking as an individual, I agree that asking implementations to bend
over on this issue has cost.  Please make sure that there is not a
significant security impact before removing the requirement.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Jul 2011 11:24:02 -0500

> does it prevent, versus just having the client encrypt a timestamp?

It can help guarantee freshness (e.g., if the state includes a
timestamp and the KDC generated the nonce).  If the OTP is a
time-based one then perhaps this doesn't matter at all.

Freshness != replay protection.  As you point out, stalessness implies
that replay protection is infeasible.

> Is it unnecessary complexity?

I don't think so.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 18 Jul 2011 12:49:55 -0400

> time-based one then perhaps this doesn't matter at all.

If the goal is to guarantee freshness within a time window, then a much
simpler approach would be to make the nonce a timestamp, or let the
client choose a timestamp.  But the draft states that the nonce must be
chosen randomly.

> > Is it unnecessary complexity?

Well, what is it necessary for?  Let's say there were no nonce at all,
and the client simply encrypted the empty string in the client key.
What would be the resulting threat?  An attacker with visibility into
the FAST channel could replay the encrypted data proving knowledge of
the client key, but wouldn't know the reply key to decrypt the resulting
ticket.  The resulting ticket could be used to brute-force the reply
key, but the attacker already has a ciphertext to do that with.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 13:33:18 -0400

>> time-based one then perhaps this doesn't matter at all.

    Greg> If the goal is to guarantee freshness within a time window,
    Greg> then a much simpler approach would be to make the nonce a
    Greg> timestamp, or let the client choose a timestamp.  But the
    Greg> draft states that the nonce must be chosen randomly.

    >> > Is it unnecessary complexity?

    Greg> Well, what is it necessary for?  Let's say there were no nonce
    Greg> at all, and the client simply encrypted the empty string in
    Greg> the client key.  What would be the resulting threat?  An
    Greg> attacker with visibility into the FAST channel could replay
    Greg> the encrypted data proving knowledge of the client key, but
    Greg> wouldn't know the reply key to decrypt the resulting ticket.
    Greg> The resulting ticket could be used to brute-force the reply
    Greg> key, but the attacker already has a ciphertext to do that
    Greg> with.

I would not be comfortable with this vulnerability with an unlimited
time window.  For auditing and other purposes people assume that preauth
with client authentication implies that the client is freshly
authenticated.

It also seems valuable to have a random nonce so that KDCs can use a
state synchronization mechanism if they have one.

However, I think exploring whether some requirements can be relaxed. For
example allowing a nonce to be valid within a time window.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Mon, 18 Jul 2011 14:20:37 -0400

On Mon, 2011-07-18 at 13:33 -0400, Sam Hartman wrote:
> For auditing and other purposes people assume that preauth

You're right; being able to replay a request at any time to get account
lockout counters to reset would be poor.

> example allowing a nonce to be valid within a time window.

What I'd like, at a minimum, is for the KDC to be allowed to use a
timestamp as the nonce, effectively turning the PA-OTP-ENC-REQUEST (used
in 4-pass) into a PA-ENC-TS-ENC (used in 2-pass).  The KDC could then
ensure freshness without using a cookie.

This change doesn't have any impact on protocol fields and is invisible
to any existing client implementations.  It would be up to the KDC to
encode and decode the timestamp as an octet string.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 19 Jul 2011 11:10:08 -0700

Do any of your comments generalize to the FAST framework or to the Encrypted Challenge FAST factor?

> key, but the attacker already has a ciphertext to do that with.

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 19 Jul 2011 14:32:46 -0400

> Do any of your comments generalize to the FAST framework or to the Encrypted Challenge FAST factor?

Not to the FAST framework.

Encrypted challenge gives a 5-minute freshness guarantee (or better, if
you use a replay cache on the client-supplied ciphertext) without the
use of cookies.

---

From: <[email-masked]>
Date: Tue, 19 Jul 2011 14:52:55 -0400

> encode and decode the timestamp as an octet string.

How about if we relaxed the requirements on the nonce in the PA-OTP-CHALLENGE so that it SHOULD be random?  This would then allow the KDC to use any value.
Would the size constraints still be an issue?

   nonce
      A KDC-supplied nonce value to be encrypted by the client in the
      PA-OTP-REQUEST.  This nonce string MUST be as long as the longest
      key length of the symmetric key types that the KDC supports and
      SHOULD be chosen randomly.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Tue, 19 Jul 2011 15:11:20 -0400

>       SHOULD be chosen randomly.

Technically, the size constraint could be met by padding out the
timestamp to the required length.  However, if we're going to allow
non-random nonces, I don't see the point in mandating a minimum size.
So I advocate relaxing both of those MUSTs to SHOULDs.

As a side point, I find the length requirement a little annoying as an
implementor because it requires preauth mechanisms to have more
visibility into the KDC's crypto library than is natural to provide.
There might be other ways to phrase it, such as saying that the nonce
must be at least as long as the key length of the enctypes the KDC plans
to return in etype-info2 entries (which can be just one entry, since the
KDC knows what enctypes the client supports).

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 19 Jul 2011 10:08:32 +0200

Greg Hudson <[email-masked]> wrote
Mon, 18 Jul 2011 12:49:55 -0400:

| Well, what is it necessary for?  Let's say there were no nonce at all,
| and the client simply encrypted the empty string in the client key.
| What would be the resulting threat?  An attacker with visibility into
| the FAST channel could replay the encrypted data proving knowledge of
| the client key, but wouldn't know the reply key to decrypt the resulting
| ticket.  The resulting ticket could be used to brute-force the reply
| key, but the attacker already has a ciphertext to do that with.

Does "visibility into the FAST channel" mean possession of the FAST
armor key?

In OTP systems where the KDC doesn't know the OTP, an attacker in
possession of the armor key knows both the client and the reply key.
They're the same.

   o  If the OTP value is included in the otp-value of the PA-OTP-
      REQUEST then the two keys SHALL be the same as the Armor Key
      (defined in [ZhHa10]).

---

From: Greg Hudson <[email-masked]>
Date: Tue, 19 Jul 2011 17:10:16 -0400

> Does "visibility into the FAST channel" mean possession of the FAST

Yes.

> possession of the armor key knows both the client and the reply key.

Yes.  In that case the nonce encryption accomplishes nothing, as far as
I can tell.

In the other case (where the OTP figures into the keys), the encrypted
nonce shows possession of the OTP.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Jul 2011 17:34:10 -0400

If we can get two people besides Greg and Gareth to agree to the nonce
text by the time the draft queue opens, Gareth should feel free to fold
in now along with the error change.  Otherwise, or if there are any
objections, please hold off until this change until AD review or IETF
last call comments.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Jul 2011 01:10:40 +0200 (MEST)

Greg Hudson wrote:
> > How about if we relaxed the requirements on the nonce in the
> > PA-OTP-CHALLENGE so that it SHOULD be random?  This would then
> > allow the KDC to use any value.

I'm wondering whether the text should more openly discuss the
rationale / security trade-off that is involved here?

A "SHOULD be chosen randomly" sounds strange to me.
What is it you're looking for?

   1)  uniqueness  (collision-proof)
      a) during short time
      b) essentially forever

   2) non-predictability
      a) low entropy non-predictability
      b) high entropy non-predictability

1a) could be done with a counter
1b) could be done with a timestamp

but when there are multiple potential recipient for (1), then more
sophisticated collision avoidance might be necessary

2b) requires a cryptographically strong random number

Depending on the exact requirements (and length of the nonce),
composing a nonce from subparts to obtain specific characteristics
might be possible.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Jul 2011 01:17:44 +0200 (MEST)

I forgot the description of the security trade-off.

- what would be the consequence of non-uniquness?

- what would be the consequence of predictability?

- how many guesses can an attacker make before the server
  should take defensive measures (e.g. lock-out an account)

- in some situations, account lock-out might be an undesirable
  DoS surface:
    * how easy is it to cause lock-out
    * how large is the burden to overcome the lock-out (on admins and users)?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Jul 2011 11:18:22 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> As a side point, I find the length requirement a little
    Greg> annoying as an implementor because it requires preauth
    Greg> mechanisms to have more visibility into the KDC's crypto
    Greg> library than is natural to provide.  There might be other ways
    Greg> to phrase it, such as saying that the nonce must be at least
    Greg> as long as the key length of the enctypes the KDC plans to
    Greg> return in etype-info2 entries (which can be just one entry,
    Greg> since the KDC knows what enctypes the client supports).

Or simply that it SHOULD be at least 256-bits long.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 20 Jul 2011 12:20:49 -0400

> What is it you're looking for?

KDC implementations may be looking for different levels of assurance:

1. A KDC might only care that preauthentication proves that the client
already has access to a ciphertext encrypted in the client secret (to
avoid giving out dictionary-attackable ciphertexts to clients which
don't already have them).

2. A KDC might want to ensure that every successful preauthentication
corresponds to an action by a recent legitimate client (say, within the
last five minutes).

3. A KDC might want to ensure that every successful preauthentication
corresponds to a unique action by a legitimate client.

For case (1), there are no particular requirements on the nonce.  For
case (2), a timestamp works well.  For case (3), there are a couple of
options.  You could ignore the nonce and just use a replay cache on the
ciphertext provided by the client (which, due to confounders, will be
different for each separate action).  Or you could provide a random
nonce and use cookies to ensure that the OTP request contains a
ciphertext for the same nonce as in the request--but again, you'll need
something akin to a replay cache to ensure that cookies aren't reused.
In either case, you have to worry about multiple KDCs.

MIT krb5 tends to care at the level of (2) for existing
preauthentication mechanisms, which is why I'm advocating to allow the
use of a timestamp.

There are some other factors inherent in FAST and OTP which may prevent
some replays.  First (keeping in mind that the encrypted nonce is only
meaningful in the case where the OTP contributes to the client and reply
keys), the KDC might tell the OTP server that the OTP value has been
used, preventing a replay using the same client key.  Second, the keys
at issue derive from the armor key, which (for ticket armor) necessarily
changes whenever an authenticator expires, I think.  That gives a
freshness guarantee of five minutes.

To answer your question as stated, I believe what the draft is looking
for is uniqueness over a long time period (although uniqueness over a
short period may be sufficient if you make assumptions about FAST armor
key validity).  A counter could work, but only if synchronized over
multiple KDCs (perhaps by dividing up the counter space) and only if the
counter is durable across KDC restarts.  A timestamp could work, but
only if you can guarantee that the KDC clock advances for each request.

> what would be the consequence of non-uniquness?

If two OTP challenges used the same nonce within the time window of the
validity of an armor key, and the second challenge went out to an
attacker, the attacker could replay the request for the first challenge.
This could succeed in generating a ticket if the KDC is for some reason
unable to prevent reuse of OTP values within a time window.  The
attacker would be unable to decode the ticket, but the mere fact of
issuance could result in resetting lockout failure counters.

> how many guesses can an attacker make before the server

Account lockout can be specified and implemented independently of
individual preauth mechanisms, and has been.  All you need is a generic
concept of preauth verification failure.

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Jul 2011 20:47:56 +0200 (MEST)

Greg Hudson wrote:
> [very helpful and elaborate response omitted]

I'm sorry for having been unclear.

I would have been just fine with a somewhat more compact rationale
that could be added to the document, to outline the
requirements/expectations/assumptions behind that paragraph.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Jul 2011 16:21:19 -0400

Greg> On Tue, 2011-07-19 at 19:10 -0400, Martin Rex wrote:
    >> A "SHOULD be chosen randomly" sounds strange to me.  What is it
    >> you're looking for?

    Greg> KDC implementations may be looking for different levels of
    Greg> assurance:

    Greg> 1. A KDC might only care that preauthentication proves that
    Greg> the client already has access to a ciphertext encrypted in the
    Greg> client secret (to avoid giving out dictionary-attackable
    Greg> ciphertexts to clients which don't already have them).

Speaking very much as an individual, I think this is too weak and would
prefer that we avoid standardization of mechanisms that only give this
guarantee.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 21 Jul 2011 12:07:38 +0530

Greg, Gareth,

What about using the combination of timestamp and random nonce e.g. first 4
bytes of timestamp + 16 bytes of random nonce?
So the nonce string will be 20 bytes and it can used to check all the 3
points?

Thanks,
Srini

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Greg Hudson
Sent: Wednesday, July 20, 2011 9:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] OTP 4-pass nonce

1. A KDC might only care that preauthentication proves that the client
already has access to a ciphertext encrypted in the client secret (to avoid
giving out dictionary-attackable ciphertexts to clients which don't already
have them).

2. A KDC might want to ensure that every successful preauthentication
corresponds to an action by a recent legitimate client (say, within the last
five minutes).

For case (1), there are no particular requirements on the nonce.  For case
(2), a timestamp works well.  For case (3), there are a couple of options.
You could ignore the nonce and just use a replay cache on the ciphertext
provided by the client (which, due to confounders, will be different for
each separate action).  Or you could provide a random nonce and use cookies
to ensure that the OTP request contains a ciphertext for the same nonce as
in the request--but again, you'll need something akin to a replay cache to
ensure that cookies aren't reused.
In either case, you have to worry about multiple KDCs.

MIT krb5 tends to care at the level of (2) for existing preauthentication
mechanisms, which is why I'm advocating to allow the use of a timestamp.

There are some other factors inherent in FAST and OTP which may prevent some
replays.  First (keeping in mind that the encrypted nonce is only meaningful
in the case where the OTP contributes to the client and reply keys), the KDC
might tell the OTP server that the OTP value has been used, preventing a
replay using the same client key.  Second, the keys at issue derive from the
armor key, which (for ticket armor) necessarily changes whenever an
authenticator expires, I think.  That gives a freshness guarantee of five
minutes.

To answer your question as stated, I believe what the draft is looking for
is uniqueness over a long time period (although uniqueness over a short
period may be sufficient if you make assumptions about FAST armor key
validity).  A counter could work, but only if synchronized over multiple
KDCs (perhaps by dividing up the counter space) and only if the counter is
durable across KDC restarts.  A timestamp could work, but only if you can
guarantee that the KDC clock advances for each request.

If two OTP challenges used the same nonce within the time window of the
validity of an armor key, and the second challenge went out to an attacker,
the attacker could replay the request for the first challenge.
This could succeed in generating a ticket if the KDC is for some reason
unable to prevent reuse of OTP values within a time window.  The attacker
would be unable to decode the ticket, but the mere fact of issuance could
result in resetting lockout failure counters.

> how many guesses can an attacker make before the server should take 
> defensive measures (e.g. lock-out an account)

Account lockout can be specified and implemented independently of individual
preauth mechanisms, and has been.  All you need is a generic concept of
preauth verification failure.

---

From: <[email-masked]>
Date: Fri, 22 Jul 2011 06:37:56 -0400

Originally, the nonce in the PA-OTP-CHALLEGE was simply a value provided by the KDC that the client returns encrypted.  The current requirements on the size and randomness came about during the review of v-05 when it was suggested by Larry that the same restrictions be imposed as those in PKINIT (RFC4556).  I wouldn't want to relax these constraints without checking with him first.

--Gareth

> From: Greg Hudson [mailto:[email-masked]]
> Sent: 19 July 2011 20:11
> To: Richards, Gareth
> Subject: RE: [Ietf-krb-wg] OTP 4-pass nonce
> 
> > How about if we relaxed the requirements on the nonce in the PA-OTP-
> CHALLENGE so that it SHOULD be random?  This would then allow the KDC
> to use any value.

---

From: Greg Hudson <[email-masked]>
Date: Fri, 22 Jul 2011 10:17:13 -0400

On Fri, 2011-07-22 at 06:37 -0400, [email-masked] wrote:
> Originally, the nonce in the PA-OTP-CHALLEGE was simply a value
> provided by the KDC that the client returns encrypted.  The current
> requirements on the size and randomness came about during the review
> of v-05 when it was suggested by Larry that the same restrictions be
> imposed as those in PKINIT (RFC4556).  I wouldn't want to relax these
> constraints without checking with him first.

I see.  In RFC 4556, the nonce is chosen by the client (who can more
easily maintain state across the conversation), and I believe the length
restriction is to ensure that DH key reuse is not cryptographically
weaker than picking a new DH secret.  Those considerations do not seem
to apply to OTP, where the encrypted nonce has an authentication
strength determined by the client key enctype.  So, this is kind of a
confusing bit of standards cut-and-paste to me.  Larry, can you comment?

This brings us to:

> What about using the combination of timestamp and random nonce

I'm fine with this if we're willing to assume there isn't much pain in
changing the spec.  If we go in this direction, I suggest making
PA-OTP-ENC-REQUEST look like:

  PA-OTP-ENC-REQUEST ::= SEQUENCE {
    nonce           [0] OCTET STRING OPTIONAL,
    timestamp       [1] KerberosTime,
    usec            [2] Microseconds OPTIONAL
    ...
  }

and make the encData field of PA-OTP-REQUEST always be an encrypted
PA-OTP-ENC-REQUEST.  In 2-pass the nonce wouldn't be supplied.

Incidentally, section 3.6 refers to "the nonce generated by the client".
But the client doesn't generate a nonce; either it gets one from the KDC
(4-pass) or it doesn't have one (2-pass).  If I had to implement that
part of the draft as it stands, I would assume that using hashed token
values is impossible in 2-pass, and that I should ignore the "generated
by the client" clause in 4-pass.

---

From: Linus Nordberg <[email-masked]>
Date: Fri, 22 Jul 2011 17:15:32 +0200

Greg Hudson <[email-masked]> wrote
Fri, 22 Jul 2011 10:17:13 -0400:

| Incidentally, section 3.6 refers to "the nonce generated by the client".
| But the client doesn't generate a nonce; either it gets one from the KDC
| (4-pass) or it doesn't have one (2-pass).  If I had to implement that
| part of the draft as it stands, I would assume that using hashed token
| values is impossible in 2-pass, and that I should ignore the "generated
| by the client" clause in 4-pass.

There are two.  See section 4.2. for the client generated one.

   nonce
      This field MUST be present if and only if a hash of the OTP value
      was used as input to string-to-key (see Section 3.6) and MUST
      contain nonce value generated by the client and used in the
      generation of hashed OTP values as described in Section 3.6 .
      This nonce string MUST be as long as the longest key length of the
      symmetric key types that the client supports and MUST be chosen
      randomly.

---

From: <[email-masked]>
Date: Fri, 22 Jul 2011 12:03:37 -0400

> confusing bit of standards cut-and-paste to me.  Larry, can you

I agree that the client nonce restrictions from RFC4556 don't seem to apply here but I will have to defer to Larry.

> PA-OTP-ENC-REQUEST.  In 2-pass the nonce wouldn't be supplied.
This makes sense to me and would simplify things as well since the client would always use the same type of structure rather than a PA-ENC-TS-ENC in 2-pass mode.

> by the client" clause in 4-pass.

If hashed OTP values are used then the client must generate a random value to be included along with the OTP value and the KDC's realm name in the hash calculation.  This value is included in the nonce element of the PA-OTP-REQUEST in both the 2-pass and 4-pass modes.  The KDC then uses this value to generate the same client key as described in section 3.4.

---

From: Greg Hudson <[email-masked]>
Date: Fri, 22 Jul 2011 12:50:42 -0400

On Fri, 2011-07-22 at 12:03 -0400, [email-masked] wrote:
> If hashed OTP values are used then the client must generate a random
> value to be included along with the OTP value and the KDC's realm name
> in the hash calculation.  This value is included in the nonce element
> of the PA-OTP-REQUEST in both the 2-pass and 4-pass modes.  The KDC
> then uses this value to generate the same client key as described in
> section 3.4.

Thanks for the clarification.  I had erroneously assumed that the nonce
in the PA-OTP-REQUEST was a mirror of the KDC nonce.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Jul 2011 08:10:01 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> If we can get two people besides Greg and Gareth to agree to
    Sam> the nonce text by the time the draft queue opens, Gareth should
    Sam> feel free to fold in now along with the error change.
    Sam> Otherwise, or if there are any objections, please hold off
    Sam> until this change until AD review or IETF last call comments.

At this point my preference is that OTP be submitted without any changes
for the 4-pass nonce text: we're not done with that discussion.  I'll
flag it as an issue that will likely come up in IETF last call.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg