Subject: [Sip] SIP Saml Review by Marcos Dytz

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 18 Jun 2007 10:39:20 +0200

Marcos Dytz implemented SIP Pay and I asked him to review the document.
Here are his review comments:

-----------------------------

Von: ext Marcos Dytz [mailto:[email-masked]] 
Gesendet: Montag, 18. Juni 2007 10:20
An: Tschofenig, Hannes
Betreff: Re: SIP SAML Draft Review

Hey Hannes,

I finished my review. Here are my comments:

Overall the draft is much more detailed (thus, better) than anything
I've read before on SIP/SAML. 

My points on possible improvements to be added.

1) I believe that it would be good to leave a bit the emphasis on
authentication and providing different uses of the protocol (or, at
least, specifying that it can be used to convey attributes, query for
information, etc). 

2) The SAML assertion profile sounds weird, although I never completely
had a complete grasp of its meaning. I understand that it is connected
with the implementation, but it never actually had any particular use to
me (or I never gave it much attention). I rather see it as details that
developers had to apply in order to have the implementation working and
must be added to the specification in order to avoid interoperability
issues. 

3) I believe it is worth mentioning that one invalid condition locks the
whole assertion.

4) I also believe that is worth mentioning that the Identity-Info is
connected with CERTS and might go through deployment issues. 

5) Is there something missing on 7.1? Sounded incomplete to me.

6) I believe that it is valid that together with signing part of the
message, some fields are hashed in order to improve security.

7) The part of the AS as an authenticator and proxy could be further
clarified. 

Just some tips on how I believe it could be further improved. Again
overall the draft is very good and understandable.

Cheers

Marcos

PS: Grammar corrections (and suggestions). I've put changes under
parentheses.

* areas where the applicability to SIP (are) is widely desired.

* Employing SAML in SIP necessitates devising a new SAML profile(s) and
binding(s) because (the) those already specified in the SAMLv2 

* specification set are specific to other use contexts (contexts of use
sound more connected with general use of the term, no?), e.g.,
HTTP-based web browsing. 

* 6.1.  AS-driven SIP SAML URI-based Attribute ( )Assertion Fetch
Profile (Double spacing) 

* Since the AS (is) already being trusted to create and add the Identity
header containing the SIP Identity Assertion, and to supply a pointer to
its domain certificate, having it point instead to a SAML assertion
conveying the domain certificate and possibly some user profile
attributes, does not significantly alter the first-order security
considerations examined in [RFC4474]. 

The last one was confusing to me. I re-wrote by having two sentences.

Since the (is) AS already being trusted to create and add the Identity
header containing the SIP Identity Assertion, and to supply a pointer to
its domain certificate. By having it point instead to a SAML assertion
conveying the domain certificate and possibly some user profile
attributes does not significantly alter the first-order security
considerations examined in [RFC4474]. 

* Although this profile (is) overview is cast in terms of a SIP INVITE
transaction, the reader should note that the mechanism specified herein,
and in [RFC4474], may be applied to any SIP request message.

* the randomness requir(e)ments specified in Section 1.3.4 of
[OASIS.saml-core-2.0-os].

* The value of the NotOnOrAfter XML attribute MUST be set to a time
instant later than the value for(or of?) NotBefore.

* 6.1.3.4.  Verifier Dereferences HTTP-based SAML ( )URI Reference

* the SIP SAML assertion profile specified herein (states) that the
subject's SAML assertion must adhere to causes it to be not useful to
arbitrary parties. 

* Additionally, the assertion content dictated by the SAML assertion
profile herein ensures (or provides?) ample evidence for a relying party
to verify the assertion and its relationship with the received SIP
request. 

_______________________________________________
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