Subject: [Sip] AW: Comment on draft-schwartz-sipping-spit-saml-00

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 18 Nov 2005 13:02:41 +0100

hi otmar, 

thanks for your feedback. let me also respond to your comments. 

> Hello,
> 
> as I'm not sure whether this draft is supposed to be discussed in
> sip or sipping, I'm writing directly to you:
> 
> After a quick reading of draft-schwartz-sipping-spit-saml-00 I'm
> wondering:
> 
> * e.g. 5.1.1: 
> 	The numerical values maybe fine to denote the strength levels
> 	you have in mind now, but they do not offer any space for
> 	adding new notions which lie between current values.
> 
> 	I'd recommend you change the values from 0,1,2,3,4 to
> 	0,10,20,30,40 to accomodate future enhancements.
> 
that's a very good question. 

let me point to a few aspects here: 

- first, i think that there is a difference in the way how difficult it
is to obtain an identity in a certain domain. i guess there are no
doubts about this. 

- the second aspect is how you actually rank the different ways. i am
not sure whether it is a good idea to make a ranking at all. maybe it is
just better to assume that there are different categories and to let the
person that writes the policies decide whether they think that certain
mechanisms are more difficult in, for example, one country than in
another one. 

- the third aspect is extensibility. how do you actually add new
mechanisms to the list? currently we do not define an extensibility
mechanism and that needs to be fixed. 

for example, what happens if i want to add something like a
'return-routability' check. this is often done with today's email
providers. you need to have a valid email address (or something
similar). you might also use an sms (which provides higher security ,
probably). 

- the forth aspect is: 'are the currently defined values reasonable?'
for example, is the 'paying service' actually indicating something about
your identity. at some point in time we need to go through these
attributes and discuss what attributes & values are most useful.

> * The XML (SAML) framents look overly complex:
> 	I haven't read the SAML spec itself, but the example
> 
> 	<Attribute
> 		AttributeName="IdentityStrength"
> 		AttributeNamespace="http://mio.com">
> 		<AttributeValue>2
> 		</AttributeValue>
> 	</Attribute>
> 
> 	looks overly contorted. Why not the following?
> 
> 	<IdentityStrength xmlns="http://mio.com">2</IdentityStrength>

i will look at this aspect in the next few days. let me send you a
response about it later. the usage of the attribute statement seems to
be the right way forward but i am not sure about the details at the
moment. we, however, might not be able to put arbitrary xml statements
in a saml assertion. 

ciao
hannes
> 
> cheers,
> 
> /ol
> -- 
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Peter Davis <[email-masked]>
Date: Wed, 30 Nov 2005 14:37:25 -0500

> moment. we, however, might not be able to put arbitrary xml statements

Might I suggest making use of the security mechanisms (authentication
context) vocabulary the SSTC @ OASIS produced [1].  Rather than requiring a
subjective gradation of various security mechanism strengths, one simply
conveys the mechanism in use for the given session. These are normatively
defined URNs in [1].

Adding new security mechanisms as above would allow sufficient
extensibility, I think.  It also allows for 'private' mechanisms, for closed
deployments.

SAML advice provides the extention point you seek for arbitrary XML:

<element name="Advice" type="saml:AdviceType"/>
    <complexType name="AdviceType">
        <choice minOccurs="0" maxOccurs="unbounded">
            <element ref="saml:AssertionIDRef"/>
            <element ref="saml:AssertionURIRef"/>
            <element ref="saml:Assertion"/>
            <element ref="saml:EncryptedAssertion"/>
            <any namespace="##other" processContents="lax"/>
        </choice>
    </complexType>

=peterd

[1] 
http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf