OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] suggested HoK URIs and namespace prefixes


On Wed, Aug 20, 2008 at 8:59 PM, Scott Cantor <cantor.2@osu.edu> wrote:
>
> I still didn't read Conor's response as being about what you were
> suggesting. He was talking about the time of confirmation and you were
> talking about the time of initial key binding.

Yes, I reread that exchange and I think you're right.  For the record,
I was talking about the time of proof of possession *to the issuer*.
In the same way that AuthnInstant reflects the time of authentication,
ProofInstant reflects the time of proof of possession.  If there were
no SSO, AuthnInstant would be unnecessary.  Likewise if proof of
possession is ALWAYS freshly established for each request to the
issuer, there is no need for ProofInstant.

> I accept your suggestion that it's a relevant data item (though not so much
> to me), but I just don't know where it would go.

Well, if we assume that the presenter always proves possession at the
issuer, there's nothing to worry about.  By the way, the use cases I
have in mind satisfy that requirement.  If there are other use cases
that don't, then we have yet to determine if they can be rolled into
this profile.

>> Well, then I think the onus is on you to clarify these other use cases
>> so that we can take them into consideration.  The dialogue thus far
>> suggests this might be a useful exercise.
>
> The basic use case is already profiled and specified in ID-WSF. Heck, I have
> sample messages posted in the Internet2 wiki.

Can you provide a pointer, please?

> By far the most useful HoK use
> case is web services. Some of those cases could involve a client, but most
> of them will be browser -> site -> service.
>
> SSO with SAML from IdP to SP/WSC
>
> SP/WSC to IdP with AuthnRequest for token for WSP
>
> WSC to WSP with token (today we assume SOAP, but I think this can change)
>
> The token contains the user in the subject, but the SP's key in the
> SubjectConfirmation.

How and when does proof of possession take place?

> Various optimizations are possible and all of this is already defined to my
> satisfaction (thus I don't think new profiles are needed for the SAML
> protocol bits). What you want is a last step; to profile the actual
> verification of HoK. That's fine, but it's orthogonal to the flows, and
> should not need to know anything about who's requesting what or about whom.

Sorry, I don't see it that way.  In my mind, there are two
requirements that can not be relaxed:

1. The presenter MUST present an X.509 public key certificate
2. The presenter MUST prove possession of the corresponding private key

The first requirement  justifies the choice of ds:X509Data as a child
element of ds:KeyInfo.  The second requirement justifies the binding
of the X.509 data to the assertion in the first place.  Without the
latter, it seems a timestamp is required, as argued above.

Frankly, I don't know how to write a profile without these two
requirements.  If someone else wants to give it a go, please do.

> What I further argue is that HoK in this context is about replacing PKI with
> SAML. To that end, the goal should be to get to keys and compare them, and
> avoid the brittle processing of certificates. Otherwise SAML doesn't need to
> be there to begin with.

You'll have to find someone else to engage in this religious battle
:-)  My immediate goal is to profile HoK subject confirmation in as
broad fashion as possible.  Since keys are almost always bound to
certificates in flows, the above requirements seem to make sense.

Tom


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]