Subject: [Sip] wrt SIP Saml Review by Jiri Kuthan - "missing scenarios"

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

Jiri Kuthan <[email-masked]> wrote:
 > I'm personally missing scenarios which
 >
 > - use redirection as opposed to proxy mode. IMO, it is beneficial to have
 >   the AS operated in 3xx mode for better scalability.

Perhaps you could explain a bit more what you mean here because it isn't all 
that clear what the differences would be. In poking around thru, say, RFC3665 
section "3.6.  Session via Redirect and Proxy Servers with SDP in ACK", it 
isn't clear to me that there is necessarily a salient difference between it's 
scenario and the one depicted in draft-ietf-sip-saml-02 fig 1.

Here's RFC3665 Session via Redirect and Proxy Servers..

    Alice        Redirect Server     Proxy 3             Bob
      |                |                |                |
      |   INVITE F1    |                |                |
      |--------------->|                |                |
      |     302 F2     |                |                |
      |<---------------|                |                |
      |     ACK F3     |                |                |
      |--------------->|                |                |
      |     INVITE F4                   |                |
      |-------------------------------->|    INVITE F5   |
      |             100  F6             |--------------->|
      |<--------------------------------|      180 F7    |
      |             180 F8              |<---------------|
      |<--------------------------------|                |
      |                                 |     200 F9     |
      |             200 F10             |<---------------|
      |<--------------------------------|                |
      |             ACK F11             |                |
      |-------------------------------->|     ACK F12    |
      |                                 |--------------->|
      |                Both Way RTP Media                |
      |<================================================>|
      |                                 |     BYE F13    |
      |             BYE F14             |<---------------|
      |<--------------------------------|                |
      |             200 F15             |                |
      |-------------------------------->|     200 F16    |
      |                                 |--------------->|
      |                                 |                |

..and here's -sip-saml-02 fig 1..

      +--------+           +--------------+          +--------+
      |Alice@  |           |Authentication|          | Bob@   |
      |example |           |Service       |          |example2|
      |.com    |           [email-masked]  |          |.com    |
      +---+----+           +------+-------+          +---+----+
          |                       |                      |
          |      INVITE           |                      |
          |---------------------->|                      |
          | From:[email-masked]    |                      |
          |                       |                      |
          |  407 Proxy auth. req. |                      |
          |<----------------------|                      |
          |     Challenge         |                      |
          |                       |                      |
          |       ACK             |                      |
          |---------------------->|                      |
          |                       |                      |
          | INVITE w/authn creds  |                      |
          |---------------------->|                      |
          |                       | INVITE               |
          |                       | w/Identity header    |
          |                       |--------------------->|
          |                       | and Identity-Info    |
          |                       |                      |
          |                       | HTTP GET SAML assn   |
          |                       |<==================== |
          |                       | and domain cert      |
          |                       |                      |
          |                       | HTTP 200 OK + assn   |
          |                       |=====================>|
          |                       | and domain cert      |
          |            200 OK     |                      |
          |<----------------------+----------------------|
          |                       |                      |

..so it seems that given the way in which RFC4474 works, either of the Redirect 
server or Proxy 3 in the former figure could instigate authn of the user/UAC, 
whereupon things would proceed more-or-less as depicted in the latter.

yes/no?

 > - use SAML-by-value, in addition to SAML-by-reference. I personally find
 >   the SAML-by-reference quite non-real-time and harder-to-scale too.

Yes, this is not-yet-well-resolved piece of the architecture. Given present 
restrictions wrt SIP intermediaries only being able to add SIP headers to a SIP 
request message -- it offhand would have to be the UAC that embeds a SAML 
assertion into a SIP request it is originating.

We (SIP WG) should perhaps think about this and whether we think it is a 
practical use case that would indeed see some use. Below is one example of such 
an approach (there's various ways to approach its details). Is this an approach 
we should pursue in addition to the one presently spec'd in -sip-saml-2 ?

 > Perhaps there are arguments why proxy+by/reference is the best thing, but
 > if that's the case I think they should be mentioned in the document.

Yes, ok. Part of the rationale was that this sort of approach will work with 
present-day unmodified UACs, and all of the workable 
"include-SAML-assertion-by-value" approaches that we could think of involved 
UAC enhancements to support the new funtionality (this of course skirts the 
controversial sip-proxy-placing-BLOB-values-in-SIP-header approach, e.g. using 
a data: URL).

So we felt that specifying the draft narrowly, and focusing on enhancements to 
proxy-tier functionality was the way to go for now.

thoughts?  HTH,

=JeffH

-------
Fig 4: "caller-driven, authn+attr, SAML Assertion embedded in INVITE"

        Caller explicitly executes <samlp:AuthnRequest> protocol, i.e.
          "caller-driven" in that caller stipulates at least some of info
          that is to be embodied in resulting assertion.
        Caller places SAML Assertion in INVITE msg body; Assertion has an
          <saml:AuthnStatement> and optionally a <saml:AttributeStatement>. 

        Callee obtains SAML Assertion directly from INVITE message.

        protocol message count (only include msgs w/CSeq=N+1):

          Caller-to-AS:  3
          AS-to-callee:  1

        Protocols employed: SIP and SAML (via HTTP/SOAP)

        NOTE:    The interaction between caller and the AS is
                 in the style of the "SAML Token Service", which is
                 specified in draft form in section 

                 "3.3 SAML Token Service Profile" of [9].

                 Caller and AS must speak at least one flavor of SAML protocol.

                 Relying party needs only to be capable of understanding
                 SAML assertion. Does not need to employ any SAML protocols.

[9] SAML 2.0 Single Sign-On with Constrained Delegation
     (and SAML Token Service Proposal (Shib design note))
http://shibboleth.internet2.edu/docs/draft-cantor-saml-sso-delegation-01.pdf

                                                     Callee's UA or
                             Caller's Domain's      Callee's Domain's
         Caller               AS & SIP Proxy           SIP Proxy
        +--------+           +--------------+          +--------+
        |Alice@  |           |Authentication|          | Bob@   |
        |example |           |Service       |          |example2|
        |.com    |           [email-masked]  |          |com     |
        |        |           |    (AS)      |          |        |
        +---+----+           +------+-------+          +---+----+
-   -      |                       |                      |
^   ^      |      INVITE           |                      |
|   |      |---------------------->|                      |
|          | From:[email-masked]    |                      |
|   C      | To:sip:[email-masked]|                      |
|   S      |                       |                      |
|   e      |  407 Proxy auth. req. |                      |
|   q      |<----------------------|                      |
|          |     Challenge         |                      |
|   =      |                       |                      |
|          |                       |                      |
|   N      |                       |                      |
|          |                       |                      |
|   |      |      ACK              |                      |
|   V      |---------------------->|                      |
|   -      |                       |                      |
|          |                       |                      |
|          | [Alice marshalls      |                      |
|          |  authn credentials    |                      |
|          |  in resp to challenge]|                      |
|          |                       |                      |
|          |                       |                      |
|    -     |Request Authn+Attr Assn|                      |
|    ^     |via Authn Request Prot |                      |
|    .     |======================>|                      |
|    .     | <samlp:AuthnRequest>  |                      |
|    .     |  <samlpext:RespondTo> |                      |
|    .     |     [email-masked]  | [AS is configured    |
|    .     |                       |  OOB to "know" which |
|    .     | Assn returned         |  "profile attributes"|
|    .     |<======================|  to return in Assns. |
|    .     | <samlp:Response>      |  Relying party meta- |
|    .     |  <saml:Assertion>     |  data could be also  |
|    .     |   <saml:Subject>      |  employed. Or SAML   |
|    .     |    <saml:NameID>      |  request protocol    |
|    .     |      [email-masked]|  extension could be  |
|    .     |   <saml:AuthnStatement>  used.]              |
|    .     |   <saml:AttrStatement>|                      |
|    .     |      foo=bar          |                      |
|    .     |                       |                      |
      .     |                       |                      |
D    .     |                       |                      |
      .     | INVITE + authorization|                      |
I    |     | header w/marshalled creds                    |
      |     |---------------------->|                      |
A    |     | From:[email-masked]    |                      |
      |     | To:sip:[email-masked]|                      |
L    |     |  <saml:Assertion>     |                      |
      |     |   <saml:Subject>      |                      |
O    |     |    <saml:NameID>      |                      |
      |     |      [email-masked]|                      |
G    |     |   <saml:AuthnStatement>                      |
      |     |   <saml:AttrStatement>|                      |
|    |     |      foo=bar          |                      |
|    |     |                       |                      |
|    |     |                       |                      |
|    |     |                       |                      |
|          |                       |INVITE + authorization|
|    C     |                       |header w/marshalled creds
|    S     |                       |--------------------->|
|    e     |                       | From:[email-masked]   | [this would
|    q     |                       | To:sip:[email-masked]  thus convey an
|          |                       |  <saml:Assertion>    |  "unsolicited
|    =     |                       |   <saml:Subject>     |     response" as
            |                       |    <saml:NameID>     |   discussed in
            |                       |      [email-masked]   [5] & [3]. ]
            |                       |   <saml:AuthnStatement>
|          |                       |   <saml:AttrStatement>
|    N     |                       |     foo=bar          |
|          |                       |                      |
|    +     |                       |                      |
|          |                       |                      |
|    1     |                       |                      |
|          |                       |                      |
|    |     |                       |                      |
|    |     |            200 OK     |                      |
.    V     |<----------------------+----------------------|
.    -     |                       |                      |
.
.
V

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