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.com: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 PROTECTED]>
To: IETF SIP List <[email protected]>, Hannes Tschofenig <[EMAIL PROTECTED]>
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 PROTECTED]>
To: SIP IETF <[email protected]>
CC: ext Marcos Dytz <[EMAIL PROTECTED]>
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 PROTECTED]>
To: SIP IETF <[email protected]>
- 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.com: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 PROTECTED]>
To: SIP IETF <[email protected]>
CC: ext Marcos Dytz <[EMAIL PROTECTED]>
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 PROTECTED]>
To: IETF SIP List <[email protected]>, Hannes Tschofenig <[EMAIL PROTECTED]>
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 PROTECTED]>
To: <[email protected]>
[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 PROTECTED]>
To: SIP IETF <[email protected]>
CC: ext Marcos Dytz <[EMAIL PROTECTED]>
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 01:41:08 +0200
From: Jiri Kuthan <[EMAIL PROTECTED]>
To: DRAGE, Keith (Keith) <[EMAIL PROTECTED]>, IETF SIP List <[email protected]>
CC: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
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.
-------- Original Message --------
Subject: RE: [Sip] draft-ietf-sip-saml-02
Date: Mon, 18 Jun 2007 09:44:38 +0200
From: Fries, Steffen <[EMAIL PROTECTED]>
To: DRAGE, Keith (Keith) <[EMAIL PROTECTED]>, IETF SIP List <[email protected]>
- 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 PROTECTED]>
To: IETF SIP List <[email protected]>
CC: [EMAIL PROTECTED]
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 PROTECTED]>
To: IETF SIP List <[email protected]>, Hannes Tschofenig <[EMAIL PROTECTED]>
Figure 2:
In the INVITE messages, the AoR in the From: header should be
"sip:[EMAIL PROTECTED]"
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 PROTECTED]
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 PROTECTED]>
To: <[email protected]>
[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 PROTECTED]>
To: SIP IETF <[email protected]>
- 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
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
