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

[Larry Zhu]

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
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Jeffrey Hutzelman]

--On Tuesday, November 18, 2008 01:12:43 AM -0800 Larry Zhu
<lzhu@...> wrote:

>
> 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)

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.
>
>    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].

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.



> 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.

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?
>
>    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.

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).


> Can the KDC include the PA-OTP-PIN-CHANGE before the PIN expires but
> 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?
>
>  If the pin field is present then it
>    contains a PIN value that MAY be used by the user when changing the
>    PIN.

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.

Actually, you quoted the relevant part of 3.4:

>  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.


> 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
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[gareth.richards]

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.
>
> 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.
>

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.

 

> 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.
>

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.

> 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.
>
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.
>
>    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].
>

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


> h) section 3.2, typo, s/an server generated challenge/a
> 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
>    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.
>
>

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?
>
>  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.
>

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?
>
>  The authentication MUST fail if the encryption type used by the
>    client in the encData does not conform to KDC policy.
>
>
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
> that intentional?
>
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?
>
>    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?
>

I would be reluctant to add support for this since I don't think
some OTP servers support it.


> 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]
>
Fixed

> 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')"?
>
>

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?
>
>
>       PA_OTP_CHALLENGE     131;
>
Fixed.  
Also fixed the same error in section 4.2.

> 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.
>

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.


> s) section 4.1, "DER" need to be expanded on first use and
> references should be provided.
>
>
Fixed, also added reference to X690.


> t) section 4.1, the following text does not parse.
>
>
>    the Client Key and MUST be chosen
>       randomly.
>
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?
>
>  If the pin field is present then it
>    contains a PIN value that MAY be used by the user when changing the
>    PIN.
>
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
   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.

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
>    of replay attacks, the KDC must check that the client time used in
>    such a request is later than that used in previous requests.
>
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
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Henry B. Hotz]

gareth.richards@... wrote:

>> 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?
>> >
> 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.

--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@..., or hbhotz@...
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Jeffrey Hutzelman]

--On Thursday, November 20, 2008 06:24:26 AM -0500 gareth.richards@...
wrote:

>> 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?
>>
> I would be reluctant to add support for this since I don't think
> 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
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[gareth.richards]

> >> 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?
> >> >
> > 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
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[gareth.richards]

> >> 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?
> >>
> > I would be reluctant to add support for this since I don't
> think 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.
>

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

--Gareth
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Jeffrey Hutzelman]

--On Friday, November 21, 2008 04:48:55 AM -0500 gareth.richards@...
wrote:

>> >> 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?
>> >>
>> > I would be reluctant to add support for this since I don't
>> think 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.
>>
>
> I suppose this would work but is it really required?  Is it really
> 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
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg