Assurance

["Jones, Mark B" <>]

We are looking into signing such email correspondence and training users to 
look for valid signatures.

Sent from my iPhone

On Nov 27, 2012, at 9:58 AM, "David Langenberg" 
<<mailto:>>
 wrote:

Yes, thanks Tom.

Dave


On Tue, Nov 27, 2012 at 8:28 AM, Tom Barton 
<<mailto:>>
 wrote:
Dave,

The language in 4.2.4.5 is intentionally not specific as to nature of 
measures, nor is there an adjective in front of "verify" to qualify how 
perfectly. Personally, I picture a range of technical and non-technical 
measures being used at IdPOs in good faith efforts to protect their users, 
knowing that perfect protection is generally impossible or infeasible.

In the case of a self-serve workflow in which the user requests a single-use 
secret be delivered using a per-registered out of band delivery mechanism, 
like SMS to a cellphone, it could be sufficient to protect the web site on 
which the user makes that request with an SSL cert that can be validated and 
has a subject name in a namespace administered by the IdPO.

Make sense?

Tom


On 11/27/2012 9:10 AM, David Langenberg wrote:
Well, today (pre anything silver) we have the individual call into the 
helpdesk, do a very basic Q/A session over the phone with them, and if we 
think they're legit, give them the single-use secret.  Obviously that doesn't 
work for silver, so instead the support person will have a button which will 
transmit the secret to the individual's addresses of record.  Now, in this 
flow, yes, the user will be on the phone so the support person could say, 
"here comes a text message to your cell / email." The user could also read 
the message to the support person & verify that way.  In the self-service 
workflow though, the app will tell the user about the message with the 
secret, but there would be no way short of calling the helpdesk or seeing if 
the secret worked for the purposes or regaining control of the account to 
verify that the IDPO is the source of the message.

My concern about this is what happens when the phishers start sending fake 
messages along the lines of:

"Your account has been locked, here's your authentication code: 123AF123.  Go 
to http://uchicago.pwn3d.com and enter your username, password, and code to 
get back access to your account"

So, since that will be the next iteration of phish once Silver takes off, 
what measures were envisioned for 4.2.4.5?

Dave


On Tue, Nov 27, 2012 at 7:16 AM, Ann West 
<<mailto:>>
 wrote:
How do you do this now, Dave?

Ann


----- Original Message -----
> As for how 4.2.4.5 pertains to 4.2.4.3.2, what were you imagining the
> implementation would require?  Would allowing the user to call the
> helpdesk & ask "Is this legit?" be sufficient or are we imagining a
> more technical implementation where if transmitted electronically the
> message must be signed somehow?
>
> Dave
>
> On Fri, Nov 16, 2012 at 10:25 AM, Ann West 
> <<mailto:>>
> wrote:
> > Hello All,
> >
> > As I mentioned last week in my note regarding the meaning of the
> > term "industry standard," we're discussing several possible
> > updates to the Profile and Framework documents and would like to
> > get your thoughts regarding your ability to support these
> > requirements and the ease to which you can do so.
> >
> > As you know, we currently don't include Bronze in the Credential
> > Issuance section of the IAP. FICAM's request is that we align
> > Bronze more tightly with their program in this area, and we have
> > responded by drafting an updated 4.2.4 Credential Issuance and
> > Management section.
> >
> > I've copied the entire section below, so you can see the scope of
> > the possible changes: 4.2.4.1 and 4.2.4.2 remain unchanged except
> > they now apply to Bronze in addition to Silver; 4.2.4.3 now also
> > applies to Bronze and, while we were editing the spec, the
> > language has been clarified; the retention period in 4.2.4.4. has
> > increased, an issue I vetted with the CIC and several other
> > schools late summer; and 4.2.4.5 is new.
> >
> > We invite you to send your thoughts to this list over the next
> > week.
> >
> > Best,
> > Ann
> >
> > -----
> > DRAFT
> >
> > 4.2.4        CREDENTIAL ISSUANCE AND MANAGEMENT
> > The authentication Credential must be bound to the physical Subject
> > and to the IdMS record pertaining to that Subject.
> >
> > 4.2.4.1         (S) (B)  CREDENTIAL ISSUANCE
> > To ensure that the same Subject acts throughout the registration
> > and Credential issuance process, the Subject shall identify
> > himself or herself in any new transaction (beyond the first
> > transaction or encounter) with information known only to the
> > Subject, for example a temporary Secret which was established
> > during a prior transaction or encounter, or sent to the Subject’s
> > Address of Record.  When identifying himself or herself in person,
> > the Subject shall do so either by using a Secret as described
> > above, or through the use of an equivalent process that was
> > established during a prior encounter.
> >
> > 4.2.4.2        (S) (B)  CREDENTIAL REVOCATION OR EXPIRATION
> > 1. The IdPO shall revoke Credentials within 72 hours after being
> > notified that a Credential is no longer valid or is compromised.
> > 2. If the IdPO issues Credentials that expire automatically within
> > 72 hours or less then the IdPO is not required to provide an
> > explicit mechanism to revoke the Credentials.
> >
> > 4.2.4.3        (S) (B)  CREDENTIAL RENEWAL OR RE-ISSUANCE
> > A Subject must be authenticated for purpose of Credential renewal
> > or re-issuance by any of the following methods:
> > 1.        By use of a non-expired and valid Credential.
> > 2.        By use of a single-use secret delivered to the Subject
> > from the IdPO by means of a pre-registered out of band delivery
> > mechanism.
> > 3.        The Subject may supply correct answers to pre-registered
> > personalized questions designed to be difficult for any other
> > person to know.
> > After expiration of the current Credential, if none of these
> > methods are successful then the Subject must re-establish her or
> > his identity with the IdPO per Section 4.2.2 before the Credential
> > may be renewed or re-issued.
> > Authentication Secrets shall not be recovered; new Authentication
> > Secrets shall be issued.
> >
> > 4.2.4.4         (S)  CREDENTIAL ISSUANCE RECORDS RETENTION
> > The IdPO shall maintain a record of the unique identifier and time
> > of issuance or revocation of each Credential issued or revoked for
> > a minimum of 7.5 years beyond the expiration of the Credential.
> >
> > 4.2.4.5        (S) (B) RESIST TOKEN ISSUANCE TAMPERING THREAT
> > The process or processes used by the IdPO in 4.2.4.1, 4.2.4.2, and
> > 4.2.4.3 must enable the Subject to verify that the IdPO is the
> > source of any token or Credential data they receive.
>
>
>
> --
> David Langenberg
> Identity & Access Management
> The University of Chicago
>



--
David Langenberg
Identity & Access Management
The University of Chicago





--
David Langenberg
Identity & Access Management
The University of Chicago