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] | [Elist Home]


Subject: Re: Minutes of 8 May 2001 Focus subcommittee telecon



Folks,

> RECOMMENDATION: We recommend that the TC authorize a subgroup/task force to
> evaluate a suitable pass-through authN solution for eventual inclusion in
> V.next of SAML.  If the TC likes the design once it is presented, it may
> choose to open up its scope to once again include pass-through authN in
> V1.0.  Stephen is willing to champion this.

In the process of getting this done in the next couple of days (what was
the joke about the optimist:-), there's a specific issue which we might 
want to tackle in general. 

The issue is at the conjunction of security, privacy and message
routing. The problem is basically that some structures within SAML
messages will contain names, which are used for message routing
purposes, but which also present a privacy problem. I guess there
might be other elements (as well as names) with similar problems
(I dunno).

To use an example where none of us here (AFAIK;-) were at fault,
this is one (of too many) problem(s) that the IEEE 802.11 folks have 
given themselves with WEP - you can track a user as they contact 
each 802.11 hub to "authenticate"/exchange keys, which will be an 
issue when there's a hub on all the lamp posts in a city (or all the 
coffeeshops, which I've heard is likely to actually happen).

There are a few ways to tackle this, but I wanted to present one
in particular (also used in some other protocols), which is to
not just send <Name> but to send *both* <Realm> and <Name> (for
efficiency the Name might also include the Realm string, or not,
that's a detail). 

What's this get us? Well, if we assume (which I think is fair) that 
we'll have to have a general concept of element signing/encryption for 
SAML, then the Name element can be encrypted (for privacy), but the 
Realm element can still be used (in clear) for routing.

Bit long winded, but the summary is three questions (with my assumptions
of the answers):-

1. Do we need to care about privacy in SAML (in particular for names)?
[Yes.]

2. Do we assume that SAML will specify a general method for applying 
integrity and encryption (XMLDSIG & XMLENC, when its done) to SAML 
assertions and messages?
[Yes, but maybe not "complete" for v1.0 though, esp. encryption likely to 
be v1.next due to W3C/OASIS timing, meanwhile use ssl for SAML pipes.]

3. Should we split out Name/Realm as above?
[Yes.]

I'd be interested if folks who disagree would explain why. I guess if
there's no disagreement we might make a "motion" on these sometime
(don't ask about those quotes:-), or if there is disagreement maybe
we've distilled another issue.

Stephen.

btw: who's doing the general integrity/encryption thing for assertions, 
since I assume we will need at least (partial) assertion signing for 
v1.0?


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


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


Powered by eList eXpress LLC