Assurance

[David Walker <>]

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