I had not considered that. I just tested sending a signed email to my Google address. I had no trouble reading the mail but was surprised that the UI gave no indication (that I noticed) that it had been signed? Looks like we all need to start lobbying the various providers you mention to support this. From: [mailto:] On Behalf Of David Langenberg
Sent: Monday, December 03, 2012 9:16 AM
To:
Subject: Re: [Assurance] Request for Comment: IAP 4.2.4 Credential Issuance and Management I was thinking about doing the signature thing with email, but the trouble with that is providing a way for a user to verify the signature and message from a commercial web-based email system like yahoo, gmail, hotmail, comcast, etc. On Fri, Nov 30, 2012 at 6:26 PM, Jones, Mark B <> wrote: 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
--
David Langenberg Identity & Access Management The University of Chicago |
