Subject: [Sip] draft-ietf-sip-saml-02

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 12 Jun 2007 11:13:47 +0200

(As WG chair)

Well it seems there is interest in this work, but it is not getting the
attention it deserves.
 
Some people also seem to think it is almost there, but we have no way of
judging that without seeing the what comments are being made against the
document (or of course reviewing it ourselves).

This week is a quiet week (we supposedly finished our current WGLC
yesterday, and we are not yet ready to initiate another one, and the
draft closured deadlines for the forthcoming IETF are still a little bit
away).
 
We therefore task the working group to take the next 7 calendar days
(ending Monday 18th June) to open up:

http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt

And for everyone to post at least one comment on the document to the SIP
list. Posts can cover any of:

-	completeness - is there something missing?
-	applicability - does it identify and solve a problem?
-	readability - I didn't understand what it was trying to tell me?
-	correctness of technical solution - the solution is flawed?
-	nits

We would also welcome suggestions as to whether review is needed by
other groups than the SIP WG.

And of course if you read it and find it absolutely perfect, send the
chairs a mail at least to tell us.

Regards

Keith

_______________________________________________
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: <[email-masked]>
Date: Tue, 12 Jun 2007 15:34:54 +0300

Hi,

>-	applicability - does it identify and solve a problem?

I believe it solves a relevant problem which was identified 
already within RFC 4484.

>-	readability - I didn't understand what it was trying to tell me?

I found the draft easy to understand even if I had very little
knowledge on SAML itself when starting to read the draft some
time ago.

>-	correctness of technical solution - the solution is flawed?

The approach itself seems to be sound, but some details still
need polishing, like this one:

   10.  Verify that the SAML assertion contains an <Audience> element,
        and that its value matches the value of the addr-spec of the SIP
        To header field.

How is this matching to be done ? Shall the <Audience> element
exactly the SIP URI in the To header or can it contain just a
part of it (like host part of the URI) ? The example in section 8
is like this:

  19          <Audience>
   20             example2.com
   21          </Audience>

which is not a SIP URI, so I believe either the example or the
normative text needs clarification.

>-	completeness - is there something missing?

The draft refers to a number of open issues:

13.  Open Issues

   A list of open issues can be found at:
   http://www.tschofenig.priv.at:8080/saml-sip/

It seems to me that those issues are still open within this
version of the draft and should be addressed. I became concerned
especially of issue 12 where there is an interoperability problem
if the UAS only supports Identity-Info to refer to a certificate
(per RFC 4474) instead of SAML assertion. This should be fixed in
some way or another.

    @@ TODO: do we need to define a new SIP error response code for
    when a SAML assn signature is bad? e.g., '4xx Invalid SAML
    asssertion'.

This TODO shall be resolved. To me an extra error code
would make sense.

>-	nits

I found these:

In section 6.1.2:

   Although this profile is overview is cast in terms of a SIP INVITE
   transaction

The first 'is' of the sentence sounds unnecessary.

   and also containing a the domain's (example.com) public key
certificate

The 'a' should be removed.

The SIP URIs in Figure 2 should be checked:
- Is Alice either [email-masked] or [email-masked] ?
- Is Bob either [email-masked] or [email-masked] ?
- Should the SIP URIs of both Bob and Alice or neither
  of them have sip: prefix in the figure ? Currently
  Alice does not have it (in From) while Bob has (in To).

In section 9.1. 

      *  etc.

This 'etc' should be removed. 

Regards,

Erkki

>-----Original Message-----
>From: ext DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 12.June.2007 12:14
>To: IETF SIP List
>Subject: [Sip] draft-ietf-sip-saml-02
>
>(As WG chair)
>

---

From: Shida Schubert <[email-masked]>
Date: Wed, 13 Jun 2007 14:44:39 -0700

Hi,

 I just glanced at the diff from the previous version that I read (ver-01).
> -	completeness - is there something missing?
 Some of the major issues addressed on the list and on the SIP-SAML list 
(separate
list that was active a while back to discuss SAML usage in SIP) has not 
been resolved.
 Some of which may require an extension or change to the dependent draft 
(e.g. SIP-Identity).

 So I would have to say that it's still far from complete.
> -	applicability - does it identify and solve a problem?
 Yes.
> -	readability - I didn't understand what it was trying to tell me?
 The text in the draft is fairly comprehensive and easy to understand.
> -	correctness of technical solution - the solution is flawed?
 I believe the solution and approach seems to be sound, but will need to 
see
how the remaining issues are going to be addressed.

 Regards
  Shida

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 18 Jun 2007 01:41:08 +0200

>-       applicability - does it identify and solve a problem?

I think it does. A specific case it simplifies is coordination of 
access control in federations.

>-       completeness - is there something missing?

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

Other things have been tracked but the debates are IMO not yet visible
in the spec:
- reference of the SAML document to some parts of the initial SIP request
  so that it is harder to replay SAML permisssions (issue #5)
- backwards compatibility with Identity-info (#12)
- the by-value scenarios is here actually too .. (#9)

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 18 Jun 2007 09:44:38 +0200

Hi,

I just had a quick review of the SIP-SAML activities. I found mostly
nits, which ware below, the draft generally seems mature to me.
- 1 Introduction (page 3)
   maybe it is worth mentioning in the introduction already that this ID
only 
   considers "call by reference" for the assertions and does not provide
means for 
   sending the assertion directly.
- 3.1 SAML assertions (page 7)
   "Explaining how the assertion was made, for example. " Sounds like an
example would follow, 
   which does not. I suggest removing "for example"
- 4 Specification scope  (page 9), in the discussion paragraph:
   "However, The ..." -> should be "However, the ..."
   "participating entites ..." -> "participating entities ..."
- 5. Emplying SAML in SIP (page 11)
  "seperatey" -> "separately"
- 6.1.2 Profile Overview (page 14)
  "Although this profile is overview is cast in terms of a SIP INVITE
..." There is something wrong with this sentence
- 6.1.3.2 (page 19)
  procedes -> proceeds

Ciao
	Steffen

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Tuesday, June 12, 2007 11:14 AM
> To: IETF SIP List
> Well it seems there is interest in this work, but it is not 
> getting the attention it deserves.
>  
> Some people also seem to think it is almost there, but we 
> have no way of judging that without seeing the what comments 
> are being made against the document (or of course reviewing 
> it ourselves).
> 
> This week is a quiet week (we supposedly finished our current 
> WGLC yesterday, and we are not yet ready to initiate another 
> one, and the draft closured deadlines for the forthcoming 
> IETF are still a little bit away).
>  
> We therefore task the working group to take the next 7 
> calendar days (ending Monday 18th June) to open up:
> 
> And for everyone to post at least one comment on the document 
> to the SIP list. Posts can cover any of:
> 
> We would also welcome suggestions as to whether review is 
> needed by other groups than the SIP WG.
> 
> And of course if you read it and find it absolutely perfect, 
> send the chairs a mail at least to tell us.
> 
> Regards
> 
> Keith
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Jeff Hodges <[email-masked]>
Date: Fri, 29 Jun 2007 14:10:06 -0700

Thanks to all who contributed feedback on draft-ietf-sip-saml-02.

I've extracted all the editorial comments and entered them into the tracker 
<http://www.tschofenig.priv.at:8080/saml-sip/>

I've coalesced all the other comments into three broad categories of: 
substantive, security considerations, and clarifications (see attached notes 
file).

Given the breadth of the various issues embodied therein, I'll endeavor to 
initiate discussion threads wrt the latter, and from the discussions enter 
issues into the tracker as appropriate. And I anticipate we'll update the draft 
as a result of the discussions.

thanks again for the feedback,

=JeffH

sip-saml-feedback-notes-01.txt
Fri Jun 29 13:25:10 PDT 2007
edited by: Jeff Hodges

========================================================================
                            SUBSTANTIVE
========================================================================

-------- Original Message --------
Subject: [Sip] SIP SAML Review by Richard Barnes
Date: Wed, 20 Jun 2007 23:44:26 -0400
From: Richard Barnes <[email-masked]>
To: IETF SIP List <[email-masked]>, 	Hannes Tschofenig <[email-masked]>

1. Conveying SAML assertions via a URI in the Identity-Info header 
contradicts Section 9 of RFC 4474, which says that the resource 
indicated MUST be of type "application/pkix-cert".  ISTM there are at 
least a couple of ways to fix this:
1.a. Normatively update RFC 4474 to allow the resource to be of either type
1.b. Normatively update RFC 4474 to allow for a "multipart/mixed" with 
one part of each type
1.c. Add a separate header to carry the SAML assertion
In the interest of backward-compatibility, I don't think you can get rid 
of application/pkix-cert altogether.

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

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

-------- Original Message --------
Subject: [Sip] SIP SAML Draft Review by Sebastian Felis
Date: Wed, 27 Jun 2007 12:02:48 +0200
From: Tschofenig, Hannes <[email-masked]>
To: SIP IETF <[email-masked]>

- 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.
Therefore, it is more on an SAML artifact resolution protocol using SIP.
The term "artifact resolution protocol" is never mentioned in your draft.
And how is the integration of SAML over SIP which carries the assertion
in the SIP message, eg. using MIME multiparts. But I guess, this is now
concerned by the new issue 10 in
http://www.tschofenig.priv.at:8080/saml-sip/issue10.

========================================================================
                        SECURITY CONSIDERATIONS
========================================================================

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

-------- Original Message --------
Subject: [Sip] SIP SAML Review by Richard Barnes
Date: Wed, 20 Jun 2007 23:44:26 -0400
From: Richard Barnes <[email-masked]>
To: IETF SIP List <[email-masked]>, 	Hannes Tschofenig <[email-masked]>

Security / Privacy Concerns:
------------------------------------------------------------------------
1. It's never made clear what entity is the Subject of the conveyed 
assertions.  This could be a critical distinction, e.g., if one party 
assumes that it's the UAC being discussed, and the other the user of the 
UAC.

2. Section 9 needs a discussion the nature of the assurances provided by 
SAML assertions.  In general, in order for it to be verifiable that the 
SAML assertion was issued by the Authentication Service, there must be 
proof that the holder of the private key used to create the 
Identity-Info header.  There are several ways to do this:
2.a. The SAML assertion is signed with the appropriate private key
2.b. An unsigned SAML assertion is provided over HTTPS by a server that 
authenticates with the same certificate
2.c. The Identity-Info is integrity-protected from the point where it is 
added by the Authentication Service until it reaches the UAS.

3. The list of threats and countermeasures in Section 9 is incomplete. 
For instance:
3.a. There's no discussion of threats of attacks by elements of the SIP 
signaling path (e.g., manipulating the URI in the Identity-Info header)
3.b. The anti-replay mechanism should reference the expiry elements 
built into the assertion (e.g., the NotOnOrAfter attribute)

4. The document isn't clear on whether or not the assertions MUST be 
signed by the issuer.  Section 6.1.5, step 3 seems to imply that the 
assertion will be signed, but Section 9.3 seems to assume that this 
isn't necessarily the case.  IMHO, it should be that the assertion MUST 
be signed by the same key used to generate the identity digest.  But 
even if this isn't the case, this point should be clarified.

5. No mention is made of the possible sensitivity of the contents of 
SAML assertions.  It's possible that these assertions could contain 
sensitive information about the Subject, such as statements about what 
identities the subject holds.  There should be some discussion about 
what measures should be taken in this case, e.g., the use of HTTPS and 
authentication of dereferencing clients.

Section 6.1.5, Step 3:
Section 5.4 of the indicated reference doesn't say anything about how 
signatures are verified.  Instead, this should reference Section 3.2 of 
the XMLdsig document referenced.  Also is this TODO resolved?

Section 6.1.5, Step 5:
Specify how this verification is done, e.g., by verifying that the 
signed-identity-digest and the signature on the SAML assertion are both 
verifiable with the key in the cert in the assertion.

Section 6.1.5, Step 7:
The relevant field in the X.509 certificate are Subject and Subject 
Alternative Name (not Issuer and Issuer Alternative Name).  The Issuer 
of the assertion is the Subject of the certificate.

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

[Page30] Security considerations

Is it possible to redirect messages to an own authentication service by 
manipulating the end-device? How can the called party trust the 
authentication service assigned by the caller?

========================================================================
                          CLARIFICATIONS
========================================================================

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

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.

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

-------- Original Message --------
Subject: RE: [Sip] draft-ietf-sip-saml-02
Date: Mon, 18 Jun 2007 09:44:38 +0200
From: Fries, Steffen <[email-masked]>
To: DRAGE, Keith (Keith) <[email-masked]>,	IETF SIP List <[email-masked]>

- 1 Introduction (page 3)
 maybe it is worth mentioning in the introduction already that this ID
only considers "call by reference" for the assertions and does not provide
means for sending the assertion directly.

-------- Original Message --------
Subject: [Sip] SIP SAML Review by Andreas Pashalidis
Date: Mon, 18 Jun 2007 22:24:19 +0200
From: Hannes Tschofenig <[email-masked]>
To: IETF SIP List <[email-masked]>
CC: [email-masked]

Here is a review by Andreas Pashalidis:

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

Here are a few small comments: 

"trait-based" authentication sounds a bit unconventional. 
Cannot you just talk about "attribute-based" authorization? That would be better aligned with SAML terminology. 

>From the description in section 5 and figure 1, it is not always clear
if you talk about an "authentication assertion" or an "attribute
assertion" -

Figure 2, step 5: is it possible to have multiple attribute statements
in the response? (for example, if possession of multiple attributes is
required?)

Section 6.1.4.1.4: what does it mean if there is no attribute
statement? is it an authentication assertion then? if yes, what would
be the authentication context?

Section 9.2: it would be nice to have some exaplanation there, without
having to refer to a different spec/document.

-------- Original Message --------
Subject: [Sip] SIP SAML Review by Richard Barnes
Date: Wed, 20 Jun 2007 23:44:26 -0400
From: Richard Barnes <[email-masked]>
To: IETF SIP List <[email-masked]>, 	Hannes Tschofenig <[email-masked]>

Figure 2:
In the INVITE messages, the AoR in the From: header should be 
"sip:[email-masked]"

Section 6.1.2, Step 3:
The AS is supposed to insert "attributes required by Bob's domain".  How 
is it supposed to know which attributes these are?  This is answered by 
the following paragraph, which should be moved up to here.

Section 6.1.2, Step 3:
The AS constructs a "HTTP-based SAML URI reference" -- shouldn't this be 
a reference according to the binding defined in this document, instead 
of the original (SAMLv2) reference standard?

Section 6.1.3.3, third paragraph:
This paragraph gives the option of HTTPS or HTTP, but doesn't specify 
that one of the two MUST be used.  Suggested text: "The AS MUST 
construct either an HTTP or HTTPS URI per Section "3.7.5.1 URI Syntax" 
of [OASIS.saml-bindings-2.0-os].  It is RECOMMENDED that the AS 
construct an HTTPS URI."

Section 6.1.3.3, fourth paragraph:
This is not technically correct; the URI should be the absoluteURI 
portion of the Identity-Info header value.

Section 6.1.4:
Through out this section, situations with exceptions are presented as 
"SHOULD ... MAY ...".  As I read it, this creates a situation without a 
mandatory default behavior; I would prefer if these were worded as 
MUSTs, with MAYs allowed under specified circumstances.

Section 6.1.4.1.3:
The SHOULDs in this section should be should be MUSTs.

Section 6.1.4.1.4, second paragraph:
This needs to say that the attribute-value pairs MUST pertain to the 
subject of the assertion (a concept which needs to be tied to a SIP 
entity elsewhere in the document).  This may be the entity identified in 
the From header, or another identified entity.

Section 7:
This binding doesn't really have anything to do with SIP.  Could we just 
exclude SIP from the name?  Maybe this could be the IETF standard URI 
binding of SAML.

-------- Original Message --------
Von: ext Mayutan A. [mailto:[email-masked]]
Gesendet: Mittwoch, 20. Juni 2007 09:45
An: Tschofenig, Hannes
Betreff: Re: SIP SAML Comments

section 7.1, 3rd para
this profile of the SAML URI Binding is congruent with the SAML URI binding ---- does not make sense

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

[Page 12]

Domain name for Alice: example.com or foo.com?? (same comment for other 
figures)

Authentication service or Assertion service or both?

[Page 13], 6.1. Assertion Fetch profile

Is this the only planned profile or will other profiles be defined and 
added later?  Will there also be a push based model? Will it then be 
"pushed" as part of the SIP message?

[Page 13], 6.1.1. URN

What's the current consensus for the urn?

[Page 17], 6.1.3.

...sender and Authentication service (AS) may be separate or... ???

How will the AS and sender be combined? Should it not be Authentication 
or Assertion service which can be combined?

[Page 22], 6.1.4.1.4.

AttributeStatement is indicated. But what about Authentication and 
Authorization Decision statement?

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

-------- Original Message --------
Subject: [Sip] SIP SAML Draft Review by Sebastian Felis
Date: Wed, 27 Jun 2007 12:02:48 +0200
From: Tschofenig, Hannes <[email-masked]>
To: SIP IETF <[email-masked]>

- Another topic is the usage of the term "Authentication Server" which
has the acronym AS. Since the term is originating from the trait-based
authorization draft, this term should be fine. But from the IMS
perspective, the acronym AS is "Application Server". By today, the SIP
(p)rotocol is more and more associated with IMS and touches the terms of
IMS. Further, the term Authentication Server is not a common term in
SAML. So I propose to use another term, which is more SIP/IMS and/or
SAML conform, e.g. Identity Provider in case of SAML.

===
END