Subject: Re: [Sip] Comments draft-ietf-sip-saml-02 - marc willekens - "clarification" items

From: Jeff Hodges <[email-masked]>
Date: Mon, 09 Jul 2007 16:25:37 -0700

> -------- Original Message --------
 > Subject: 	[Sip] Comments draft-ietf-sip-saml-02
 > Date: 	Thu, 21 Jun 2007 16:47:46 +0200
 > From: 	Willekens, Marc <[email-masked]>
 > To: 	<[email-masked]>
 >
 >
 > [Page 3], Introduction
 >
 > Is this document only about assertion for the authorization or also for
 > the authentication?

authorization.

 > [Page 12]
 >
 > Domain name for Alice: example.com or foo.com?? (same comment for other
 > figures)

oops, good catch. foo.com.

 > Authentication service or Assertion service or both?

authentication service -- the term is from rfc4474.

 > [Page 13], 6.1. Assertion Fetch profile
 >
 > Is this the only planned profile or will other profiles be defined and
 > added later?

My personal present thinking is that there are other possible SIP SAML 
profiles, e.g. see the appendix in -sip-saml-02 of other use cases, but that 
they should likely be specified separately in their own drafts.

 > Will there also be a push based model? Will it then be
 > "pushed" as part of the SIP message?

This is something for the WG to think about. One _can_, in theory, have the UAC 
assert some information and attach a SAML assertion to a SIP request (e.g. 
Invite) body making such a statement. Thus this approach could only be used by 
UACs because (1) only UACs may place data in the SIP request body, and (2) 
there are vociferous objections in the SIP WG to schemes whereby SIP 
intermediaries may place BLOBs (binary large objects) in SIP header fields. See 
also..

[Sip] wrt SIP Saml Review by Jiri Kuthan - "missing scenarios"
http://www1.ietf.org/mail-archive/web/sip/current/msg19793.html

We could specify this for UACs-only, and the other http-uri-based fetch 
approach for, as it is currently, intermediates or UACs.

However, before we go to the effort, what's the in-actuality demand for doing 
so? Has anyone implemented the rfc4474 authentication service role in the UAC 
and is it being used?

 > [Page 13], 6.1.1. URN
 >
 > What's the current consensus for the urn?

No one has objected to what is in the spec, although no one has commented 
specifically on it as yet, either.

 > [Page 17], 6.1.3.
 >
 > ...sender and Authentication service (AS) may be separate or... ???
 >
 > How will the AS and sender be combined?

See the last paragraph on page 5 of rfc4474..

   "This specification allows either a user agent or a proxy server to
    provide identity services and to verify identities."

 > [Page 22], 6.1.4.1.4.
 >
 > AttributeStatement is indicated. But what about Authentication and
 > Authorization Decision statement?

This particular SIP SAML Profile doesn't specify use of those statements, but 
they are not explicitly excluded either. Conceivably someone could cook up a 
use case for them and make use of it in a site-specific manner, or we might 
find use case and then can specify their use more easily.

If we do want to explicitly do this we should perhaps add that such statements 
MAY be present, but their meaning is defined outside of this profile.

 > [Page31]
 >
 > This RFC draft talks about assertions. But how can an identity be
 > asserted only by considering a device, e.g. in case a device is stolen
 > or temporary used by someone else? At VON 2000, H. Schulzrinne has
 > already indicated that something as fingerprint has to be added for a
 > device with a changing set of owners.

Although a valid thought, that being the question of the nature of the actual 
authn mechanism between the UAC and the registration service, it is out of 
scope of this specification. In fact, this draft nowhere states that the 
subject's identity is asserted only by the device (UAC).

thanks for your review,

=JeffH

_______________________________________________
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: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Jul 2007 23:13:59 +0200

Hi Jeff,
Hi Marc,

a comment below:

Jeff Hodges wrote:
> profiles, e.g. see the appendix in -sip-saml-02 of other use cases, 
> but that they should likely be specified separately in their own drafts.
>
We have investigated other profiles. The SIP SAML profile has the very 
nice characteristic that it is nicely aligned with SIP Identity -- an 
already understood and agreed model.

> This is something for the WG to think about. One _can_, in theory, 
> have the UAC assert some information and attach a SAML assertion to a 
> SIP request (e.g. Invite) body making such a statement. Thus this 
> approach could only be used by UACs because (1) only UACs may place 
> data in the SIP request body, and (2) there are vociferous objections 
> in the SIP WG to schemes whereby SIP intermediaries may place BLOBs 
> (binary large objects) in SIP header fields. See also..
>
> We could specify this for UACs-only, and the other http-uri-based 
> fetch approach for, as it is currently, intermediates or UACs.
>
> However, before we go to the effort, what's the in-actuality demand 
> for doing so? Has anyone implemented the rfc4474 authentication 
> service role in the UAC and is it being used?
>
>

With regard to the ability of the SIP UA to attach an assertion there is 
another document that describes an extension to this SAML profile.
See http://tools.ietf.org/html/draft-jennings-sipping-pay-05

> No one has objected to what is in the spec, although no one has 
> commented specifically on it as yet, either.
>
>
>
> > [Page 17], 6.1.3.
> >
But for the use case where the end host attaches the assertion it might 
be more realistic to assume that the assertion is added to the body of 
the SIP message. This is currently not provided. This again is described 
in the SIP Pay draft.

> This particular SIP SAML Profile doesn't specify use of those 
> statements, but they are not explicitly excluded either. Conceivably 
> someone could cook up a use case for them and make use of it in a 
> site-specific manner, or we might find use case and then can specify 
> their use more easily.
>
> If we do want to explicitly do this we should perhaps add that such 
> statements MAY be present, but their meaning is defined outside of 
> this profile.
>
>
We have received this question several times already. I believe we 
should explicitly enable the support since the AuthStatement provides 
more information than SIP Identity.

> Although a valid thought, that being the question of the nature of the 
> actual authn mechanism between the UAC and the registration service, 
> it is out of scope of this specification. In fact, this draft nowhere 
> states that the subject's identity is asserted only by the device (UAC).
>
That's clearly outside the scope of this document.

> =JeffH
Ciao
Hannes