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

[Hannes Tschofenig <[e-mail]>]

Hi Jeff,
Hi Marc,

a comment below:

Jeff Hodges wrote:
> > -------- Original Message --------
> > Subject:     [Sip] Comments draft-ietf-sip-saml-02
> > Date:     Thu, 21 Jun 2007 16:47:46 +0200
> > From:     Willekens, Marc <[e-mail]>
> > To:     <[e-mail]>
> >
> >
> > [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.
>
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.

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

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

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

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


> > [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).
>
That's clearly outside the scope of this document.

>
> thanks for your review,
>
> =JeffH
>
Ciao
Hannes

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



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