Subject: Re: [Sip] SIP Saml Review by Marcos Dytz and Sebastian Felis

From: Jeff Hodges <[email-masked]>
Date: Wed, 04 Jul 2007 17:08:14 -0700

[this is a response to ostensibly "substantive" comments wrt the sip-saml draft]

Marcos Dytz <[email-masked]> said  (via Hannes):
 >
 > 1) I believe that it would be good to leave a bit the emphasis on
 > authentication and providing different uses of the protocol

Sebastian Felis said (via Hannes):
 >
 > In my point of view, the draft focuses only on trait-based
 > authorization and tries to deploy trait-based authorization using SAML.
 > It does not try to specify SAML over SIP, which I was expected.

I'm assuming that both of the above are essentially saying:

   Perhaps the SIP SAML Profile should be generalized so it may be applied
   to other use cases in a SIP context.

yes?

This spec is presently designed for a fairly narrow use case, derived from 
RFC4474 "SIP Identity", and RFC4484 "Trait-Based Authorization Requirements for 
SIP". This use case is summarized in section 4 of draft-ietf-sip-saml-02 like so..

   4.  Specification Scope

      The scope of this specification is:

      o  Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
         that a subject's profile attributes, and their domain's
         certificate, can be conveyed to a relying party using SAML.  In
         doing so, satisfy the requirements outlined in [RFC4484], and
         compose with [RFC4474].

Which arguably leaves essential things unsaid, such as..

  - "using SAML" here means "using a SAML assertion", not using one of the
    existing SAML profiles. This is a _new_, SIP-specific, SAML profile.

  - we're _not_ trying to concoct a fully-general "authorization mechanism"
    as imagined in RFC4484. Rather, we're simply trying to provide a means
    to convey (some undefined (sub)set of) a subject's profile attributes
    in the specific context of "authenticated identity management" as defined
    in RFC4474. As such, -sip-saml-02, presently meets (only) a subset of
    the requirements in RFC4484. For example, Requirement 3 of Section 5 of
    RFC4484 stipulates that an authorization assertion must be deliverable
    to a SIP UAC either by reference or by value, and -sip-saml-02
    presently defines by-reference only.

  - enhancing -sip-saml-02, meaning the "SIP SAML Profile", to address
    additional use cases, and/or fully meet RFC4484's requirements,
    would add significant complexity to the specification.

So, if the WG were to decide that -sip-saml-02 ought to, at this time, address 
additional use cases, and/or fully meet RFC4484's requirements, then we need to 
do yet more significant work on it. Otherwise, it seems fairly close to being 
complete.

Thoughts?

=JeffH

ps:

Just to clarify on this comment..

 > It does not try to specify SAML over SIP, which I was expected.

This seems to me to be indicative of a misunderstanding of SAML, because the 
phrase "SAML over SIP" doesn't make much actual sense. SAML per se is not "just 
a concrete protocol" that can be simply layered above another protocol, as HTTP 
is layered over TCP. Rather, it's a _framework_, that must be profiled for 
particular contexts of use, e.g. SIP Authenticated Identity Management. 
Sometimes folks, when thinking of SAML, are thinking of just one of the 
existing SAML profiles (e.g. Web SSO) and imagining that to be "SAML" or "the 
SAML protocol", and further imagine said "protocol" somehow being layered over 
some other protocol. This line of thinking wrt SAML isn't workable. Rather one 
needs to think in terms of making use of applicable pieces of SAML's "abstract 
classes" (in the "SAML core" specification) and freshly concretely applying 
them to the target use case and protocols, thus crafting a new SAML profile(s) 
(and binding(s)) -- which is exactly what -sip-saml-02 does.

See also..

How to Study and Learn SAML
http://identitymeme.org/how-to-study-and-learn-saml/

---
end

_______________________________________________
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: "Marcos Dytz" <[email-masked]>
Date: Thu, 5 Jul 2007 01:24:34 -0300

Hello,

I agree on the limitations described below by Jeff. My concern was with the
emphasis on authentication throughout the draft, but I had in mind that it
was actually targeting that particular point (in the same way that
sip-paying targets payment).

Nevertheless, are there ideas to develop new drafts on further cases for
SIP/SAML? In my personal opinion, the protocol offers many technical
advantages (and flexibilities) that could be required for more general use
cases. By adopting and developing new cases, the overall protocol would only
be gaining a larger market share and could very well adopt some synergy
among the different areas.

As for Sebastian, I have the impression that he would like to see more
integration and deployment details. I had problems to fulfill the gaps on
integration while working on my thesis (e.g., enveloping SAML assertions in
SIP message - usually workflows target the transaction state and avoid
mentioning how to converge that with SIP - I did my implementation in the
way I thought best, but every developer is free to choose different formats
if specification does not define these little details).

As for your final points, agree to limitations due to complexity and partial
fulfilment of RFC4484. If further work is to be applied on the draft, I
believe the best action would be to leave the draft as it is and start
another work from scratch.

Regards,

Marcos

PS: I am rusty on software architecture. Can we describe SAML as a
framework? Isn't there a better terminology?

---

From: Jeff Hodges <[email-masked]>
Date: Fri, 06 Jul 2007 12:25:18 -0700

Marcos Dytz wrote:
 >
 > I agree on the limitations described below by Jeff. My concern was with
 > the emphasis on authentication throughout the draft, but I had in mind
 > that it was actually targeting that particular point (in the same way
 > that sip-paying targets payment).

Ok.

 > SIP/SAML?

Yes. Hannes has a few "in the queue".

 > In my personal opinion, the protocol offers many technical

which protocol?

 > advantages (and flexibilities) that could be required for more general
 > use cases.

 > By adopting and developing new cases, the overall protocol
 > would only be gaining a larger market share and could very well adopt
 > some synergy among the different areas.

here, by "..the overall protocol..", you mean "SIP+SAML"?

 > integration and deployment details. I had problems to fulfill the gaps
 > on integration while working on my thesis (e.g., enveloping SAML
 > assertions in SIP message - usually workflows target the transaction
 > state and avoid mentioning how to converge that with SIP - I did my
 > implementation in the way I thought best, but every developer is free to
 > choose different formats if specification does not define these little
 > details).

But you weren't implementing what is specified in draft-ietf-sip-saml-02 were you?

Do you have pointers to any documentation or papers about your work?  Or the 
code? :)

 > As for your final points, agree to limitations due to complexity and
 > partial fulfilment of RFC4484. If further work is to be applied on the
 > draft, I believe the best action would be to leave the draft as it is
 > and start another work from scratch.

Ok, fine by me.

thanks again for your feedback,

=JeffH

---

From: Jeff Hodges <[email-masked]>
Date: Fri, 06 Jul 2007 17:40:32 -0700

> -------- Original Message --------
 > Subject: [Sip] SIP Saml Review by Marcos Dytz
 > Date: Mon, 18 Jun 2007 10:39:20 +0200
 > From: Tschofenig, Hannes <[email-masked]>
 > To: SIP IETF <[email-masked]>
 > CC: ext Marcos Dytz <[email-masked]>
 >
 > 6) I believe that it is valid that together with signing part of the
 > message, some fields are hashed in order to improve security.

Hm, I'm not sure I understand. Can you please explain more fully?

thanks,

=JeffH

---

From: Jeff Hodges <[email-masked]>
Date: Mon, 09 Jul 2007 14:47:49 -0700

> 1) ...  (or, at
 > least, specifying that it can be used to convey attributes, query for
 > information, etc).

yes, we can attempt to clarify this in the draft.

 > 2) The SAML assertion profile sounds weird, although I never completely
 > had a complete grasp of its meaning.

You're referring to section "6.1.4.  Assertion Profile Description" of 
-sip-saml-02, yes?

 > 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.

I called it an "assertion profile" because it "profiles" SAML assertions for 
use in this particular context. SAML assertions are explicitly tailorable, so 
each SAML profile needs to do this as well as specify how they are to be 
conveyed. Since they are security tokens, explicitly defining their content and 
the semantics thereof is important.

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

by "locks" you mean "invalidates"?  Sure we can try to clarify this, but in 
section "6.1.5.  Assertion Verification", step 11, we do note that the validity 
period must be validated -- tho yes we should perhaps explicitly state that an 
  assertion that fails any of the 11 steps MUST be deemed invalid (good catch).

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

This is tied to our perhaps thorniest open issue, which is discussed here..

[Sip] wrt RFC4474 Identity-Info header field referent issue (was: SIP SAML 
Review by Richard Barnes)
http://www1.ietf.org/mail-archive/web/sip/current/msg19686.html

http://www.tschofenig.priv.at:8080/saml-sip/issue12

So, yes, we need to clarify appropriately once we deal with the issue.

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

AFAIK it is complete in a technical sense. I believe some other reviewers had 
more detailed comments on it, so will likely be looking into it in any case.

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

which section/paragraph are you referring to?

thanks for your review,

=JeffH