Skip to Content.
Sympa Menu

assurance - RE: [Assurance] Renewing an Expired authentication secret: 4.2.4.3

Subject: Assurance

List archive

RE: [Assurance] Renewing an Expired authentication secret: 4.2.4.3


Chronological Thread 
  • From: Eric Goodman <>
  • To: "" <>
  • Subject: RE: [Assurance] Renewing an Expired authentication secret: 4.2.4.3
  • Date: Mon, 14 Jan 2013 17:15:31 +0000
  • Accept-language: en-US

I figured the use of “expired” meant something else. That’s clear enough for me; I guess the question is whether it’s worth clarifying in the text. Ironically, I wasn’t confused about it until I saw Jeffrey’s original question.

 

--- Eric

 

From: [mailto:] On Behalf Of David Walker
Sent: Saturday, January 12, 2013 9:31 PM
To:
Subject: Re: [Assurance] Renewing an Expired authentication secret: 4.2.4.3

 

I guess this all depends on how one defines "expire."  I was thinking of expiration of a credential as being when its password exceeds the lifetime used in the entropy calculations.  If, on the other hand, you force a password change before the end of the entropy lifetime, then I would agree that a subsequent password change would reset the clock (i.e., renew the credential), assuming that that password change occurs before the end of its entropy lifetime.

David

On Fri, 2013-01-11 at 23:52 +0000, Eric Goodman wrote:

Hmm…

 

Typically a user will not change their password until it has actually expired and the system forces them to do so, human nature being what it is. E.g., if my login service tells me my password has expired (not "is going to" but "has") and forces me to reset it immediately, the language below seems to indicate that my account is no longer Silver assurance compliant, since I used an expired password for my credential renewal. Thus I need to go through a more burdensome re-issuance process (and the login server needs to track that that's how I did my password change to remove my Silver assertion).

 

It's a little fuzzy because the language in the intro refers to "in response to compromise", but the section seems to refer to any password change. 

 

I don't expect that this is the intention for the common scenario, but that seems to be what's stated in the section.

 

--- Eric

 

 

From: David Walker <>
Reply-To: "" <>
Date: Friday, January 11, 2013 10:20 AM
To: "" <>
Subject: Re: [Assurance] Renewing an Expired authentication secret: 4.2.4.3

 

Jeffrey,

The theory is that an expired password cannot be trusted sufficiently to authenticate the subject; it is no longer considered "current."  (Otherwise, why would you have expired it in the first place?)  So, yes, under the Silver profile, 4.2.4.3 requires use of one of the other methods to renew / re-issue a credential with an expired password.

David Walker

On Thu, 2013-01-10 at 15:09 +0000, Capehart,Jeffrey D wrote:

Based on your reading of 4.2.4.3 for credential renewal…

 

I am interpreting that changing your password after it expires (i.e. 90 days) would be considered a “renewal”.

 

According to 4.2.4.3 prior to renewal, subject must prove possession of an unexpired current authentication secret (i.e. password).

 

With that requirement, it would appear that you shouldn’t be able to reset/change your password after it is expired.  However, if your account is not administratively disabled, and it is just your expired password that is denying you access to services (email, network, ERP), would it not be OK to be able to do a self-service change password even after it expired, as long as you know the old password?

 

Where I get hung-up in reading this is the case where the subject CAN prove possession of the current (although expired) Authentication Secret, but the methods #1 and #2 do not apply since the secret CAN be supplied.

 

Is the wording vague or am I reading this incorrectly?

 

4.2.4.3 CREDENTIAL RENEWAL OR RE-ISSUANCE

Appropriate policy and process must be in place to ensure that any new Credential

and/or new Authentication Secret is provided only to the actual Credential Subject

should it be necessary to reissue an Authentication Secret, e.g., due to suspected

compromise or the Subject having forgotten the Secret, or to reissue a Credential due to

expiration. This process must be at least as trustworthy as the process used for initial

issuance of the Credential.

Prior to the IdPO allowing renewal or re-issuance of a Credential, the Subject must

prove possession of an unexpired current Authentication Secretor, if the Subject cannot

supply the current Authentication Secret, one of the following methods may be used:

1. The Subject must supply answers to pre-registered personalized questions designed

to be difficult for any other person to know;

2. A short-lived single use Secret sent to the Address of Record that the Subject must

submit in order to establish a new Authentication Secret.

Replacing a forgotten Authentication Secret can be accomplished at any time using the

above methodology. Authentication Secrets shall not be recovered; new Secrets shall

be issued.

After expiration of the current Credential or Authentication Secret, or if none of the

alternative mechanisms specified above are successful, renewal and re-issuance shall

not be allowed. The Subject must re-establish her or his identity with the IdPO as

defined in Section 4.2 above.

All interactions conducted via a shared network shall occur over a Protected Channel

such as SSL/TLS.

 

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882


http://oia.ufl.edu

 

 

 




Archive powered by MHonArc 2.6.16.

Top of Page