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: FW: Proposal for extensions to Authentication Context




-----Original Message-----
From: Hal Lockhart 
Sent: Monday, August 27, 2007 9:30 AM
To: 'Giles Hogben'; Brian Campbell
Cc: Eve.Maler@Sun.COM
Subject: RE: Proposal for extensions to Authentication Context

> Hi Hal,
> Also looking forward to progressing this in SSTC. Should I get ENISA
to
> join OASIS to this end?

Yes that would be helpful. Can you join the call tomorrow to discuss
this with the TC? I will put you on the agenda.


> Some thoughts on your reponse. I will change the wiki to reflect
these:
> 
> **Ref Reputation:-
> 
> I agree fully that reputation would need to be captured in attribute
> statements. That was partly my intention when I wrote "Integrating
> reputation may require some modifications to other elements in SAML".
> Wouldn't a reputation-backed public key (e.g. PGP key) be an
> Authentication Statement though?

I would suggest an attribute statement to express the reputation info
and using the PGP key as a holder-of-key subject confirmation method. To
my way of thinking the reputation info is associated with the subject
independently from how Authentication is done.

> 
> Putting reputation in attribute/authentication statements provides the
> ability to transmit E.g. :
> -"X is a trusted seller" according to 99% of voters
> -"K is X's public key" verified by 50 PGP users
> 
> We are currently doing a study on reputation systems and there is a
very
> strong need for an interoperable format, so this could be very timely.
> 
> BUT I also think there is a case for Auth-Context to include
information
> about the context of the reputation system used to collect/measure the
> reputation.
> E.g.
> -Votes are linked to a micropayment system as protection against Sybil
> attacks.
> -PGP users verify via PGP web-of-trust.
> -Reputation scheme includes a weighting scheme S for votes (2nd order
> repuation system)
> 
> Excuse my ignorance, but is there any equivalent to AuthnContext for
> Attribute statements? I.e. a way of describing how the attribute
> statement was verified?

The only thing that has been done in this area is the attribute
profiles. But Attribute statements have an open schema so you should be
able to express anything you want in the most convenient form of XML.

In previous discussions of this issue, I have concluded that a
reputation statement should refer to a single subject. Therefore a
single transaction might result in two reputation assertions, one for
the buyer and one for the seller.

Hal
> 
> **Ref Accreditation:-
> 
> Since the Authentication Context (including the assurance level) is
> signed by the issuer, I guess the assumption is that the issuer
vouches
> for its trustworthiness. I agree that adding a separate chain of trust
> for the Authentication Context is probably overkill. This requirement
> comes from previous work where the Authentication Context (equivalent)
> was not included in the signature, so there was no accreditation chain
> at all for the Auth Context. So perhaps we should just drop this
> requirement. Nevertheless maybe it is worth checking with the TC if
any
> implementers would see the need for a separate accreditation of the
> Authentication Context. Perhaps some trust models would be better
suited
> to separate accreditation here?
> 
> Regards,
> 
> Giles
> 
> 
> **-----Original Message-----
> **From: Hal Lockhart [mailto:hlockhar@bea.com]
> **Sent: 24 August 2007 18:35
> **To: Giles Hogben; Brian Campbell
> **Cc: Eve.Maler@Sun.COM
> **Subject: RE: Proposal for extensions to Authentication Context
> **
> **Giles,
> **
> **All of this looks to be completely in scope for SAML and of
> **sufficiently
> **general applicability to warrant doing the work in the SS TC.
> **
> **The only point where I would differ with you in analysis is
> **with regard
> **to Reputation. I have been doing some thinking on this subject for a
> **while and I believe reputation can best be captured as
> **attributes in an
> **Attribute Statement, rather than as part of Authentication Context.
I
> **note that in your Web Services usecase, you even refer to the
> **reputation
> **properties as Attributes.
> **
> **The basic reason I feel this way is that in all the cases I have
seen,
> **where reputation properties need to be conveyed to the relying
party,
> **they are properties of the Subject, not properties of the
> **Authentication. Where reputation is a precondition to obtaining a
> **specific type of token from a specific organization, it seems
> **to me that
> **it is unnecessary and cumbersome to pass through all the criteria
used
> **at issuance time.
> **
> **In the cases where reputation is used at Authorization Decision
time,
> **policies about the Authentication method and policies about the
> **reputation of the subject are orthogonal. Further, the issuing
parties
> **for the Authentication Token and for the Reputation properties will
> **often be distinct. Of course for efficiency and convenience
> **it is always
> **possible to issue a SAML Assertion containing both Authentication
and
> **Attribute Statements.
> **
> **Proposal 4 is interesting. I have no objection to the requirement,
nor
> **do I see any particular difficulty in adding what you suggest, but I
> **have lots of questions. What sort of format would this accreditation
> **certificate be in? X.509? SAML? Some other defined format?
> **Some not yet
> **defined format?
> **
> **In the normal SAML SSO case you have 1) Subject 2) Relying
> **Party (SP) 3)
> **Authentication Authority (IdP) and 4) Issuer (of
> **Authentication Token).
> **In the password case, typically 3 & 4 will be the same entity, in
the
> **case of PKI they will typically not be. Proposal 4 suggests a
> **5th Party
> **- Accreditation Authority. Is this correct?
> **
> **Looking back at Proposal 3, would the Assurance Level come
> **from the IdP
> **or the Issuer? If from the IdP, doesn't the SP already trust
> **the IdP to
> **verify this kind of thing? If from the Issuer, isn't the
accreditation
> **built into the certification chain that the Issuer used to
> **validate the
> **authentication?
> **
> **I guess my concerns revolve around the idea that the purpose of SSO
is
> **to relieve the SP of as much of the processing as possible.
> **Information
> **only used for the Issuance decision or the Authentication decision
and
> **not needed for the Authorization decision should not be carried in
the
> **SAML Assertion.
> **
> **I look forward to progressing this work in the SS TC.
> **
> **Hal
> **
> **> -----Original Message-----
> **> From: Giles Hogben [mailto:Giles.Hogben@enisa.europa.eu]
> **> Sent: Friday, August 24, 2007 7:48 AM
> **> To: Brian Campbell; Hal Lockhart
> **> Cc: Eve.Maler@Sun.COM
> **> Subject: Proposal for extensions to Authentication Context
> **>
> **> Hi Brian, Hal,
> **> As discussed on the SSTC call on Aug 16, here is an
> **explanation of the
> **> relation of our proposals to SAML Authentication contexts.
> **Please take
> **a
> **> look at the link below and let me know if you think it fits
> **the bill.
> **> I'm happy to tweak it as you think fit. If you think it's clear
> **enough,
> **> I guess the next step is to circulate it within to SSTC for
comment
> **and
> **> then discuss on another call? If not, please let me know what
needs
> **> clarifying (we can also talk on the phone if that's easier)
> **>
> **>
> **http://wiki.enisa.europa.eu/index.php?title=Authentication_Int
> **eroperabil
> **> ity
> **>
> **> Thanks,
> **>
> **> Giles
> **>
> **> Giles Hogben
> **> Expert, Network Security Policy
> **> ENISA  (European Network and Information Security Agency)
> **> Technical Department
> **> P.O. Box 1309,
> **> 71001 Heraklion
> **> Crete
> **> Greece
> **> Tel: (+30) 28 10 39 1892,
> **> Fax : (+30) 2810 391895
> **>
> **> giles.hogben@enisa.europa.eu
> **> http://www.enisa.europa.eu/
> **
> **


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