[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Review of draft-ietf-sip-saml-05
$Id: draft-ietf-sip-saml-05-rev.txt,v 1.1 2008/11/15 02:58:38 ekr Exp $
The purpose of this document seems to be to allow the use of SAML
authentication for SIP messages. However, after reading it, I find
myself fairly confused about how it works and what security properties
are provided.
MAJOR TECHNICAL
1. Unless I'm misreading S 7, unlike RFC 4474, no signature covers the
message. Rather, the signature covers the SAML assertion which has
some not very well specified relationship to the message (See S
7.1.5). This seems like the foundation for a cut-and-paste attack. S
10.1 dismisses this risk, but I don't see why. Where does, for
instance, the SDP get checked? What stops me from stealing an
assertion and setting up a call impersonating the caller?
2. I don't understand how the verifier obtains the domain cert
of the signer. Reading 7.1.5, it sounds like I'm supposed
to extract it from ds:X509Certificate, but if the assertion is
fetched by reference over TLS, then I would wnat to verify the certificate
before I see the the asssertion So I don't see how this works.
How does this work with unsigned assertions fetched over TLS?
3. Aren't the storage requirements different for thsi mechanism than
for RFC 4474? With 4474, you basically just have one cert that you
hand out all the time. But in this draft, you might generate a new
assertion for each call. How do you garbage collect them?
MAJOR EDITORIAL
Editorially, the mechanisms are scattered throughout the document
without a single, unified statement of how things are intended to
work. This is made worse by the fact that a lot of the document is
just profiling SAML or 4474 without explaining what's being profiled.
For instance:
The SAML assertion MAY contain an <AttributeStatement> element. If
so, the <AttributeStatement> elemeFrom sip-bounces at ietf.org Fri Nov 14 19:42:10 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 197B93A6832;
Fri, 14 Nov 2008 19:42:10 -0800 (PST)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 71D893A6832
for <sip at core3.amsl.com>; Fri, 14 Nov 2008 19:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.414
X-Spam-Level:
X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=0.080,
BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id O1DUctrA5kM1 for <sip at core3.amsl.com>;
Fri, 14 Nov 2008 19:42:07 -0800 (PST)
Received: from kilo.rtfm.com (unknown [74.95.2.169])
by core3.amsl.com (Postfix) with ESMTP id 73A313A67B2
for <sip at ietf.org>; Fri, 14 Nov 2008 19:42:07 -0800 (PST)
Received: from kilo-2.local (localhost [127.0.0.1])
by kilo.rtfm.com (Postfix) with ESMTP id 8F6B6755282
for <sip at ietf.org>; Fri, 14 Nov 2008 19:42:06 -0800 (PST)
Date: Fri, 14 Nov 2008 19:42:06 -0800
From: Eric Rescorla <ekr at networkresonance.com>
To: sip at ietf.org
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081115034206.8F6B6755282 at kilo.rtfm.com>
Subject: [Sip] Review of draft-ietf-sip-saml-05
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
$Id: draft-ietf-sip-saml-05-rev.txt,v 1.1 2008/11/15 02:58:38 ekr Exp $
The purpose of this document seems to be to allow the use of SAML
authentication for SIP messages. However, after reading it, I find
myself fairly confused about how it works and what security properties
are provided.
MAJOR TECHNICAL
1. Unless I'm misreading S 7, unlike RFC 4474, no signature covers the
message. Rather, the signature covers the SAML assertion which has
some not very well specified relationship to the message (See S
7.1.5). This seems like the foundation for a cut-and-paste attack. S
10.1 dismisses this risk, but I don't see why. Where does, for
instance, the SDP get checked? What stops me from stealing an
assertion and setting up a call impersonating the caller?
2. I don't understand how the verifier obtains the domain cert
of the signer. Reading 7.1.5, it sounds like I'm supposed
to extract it from ds:X509Certificate, but if the assertion is
fetched by reference over TLS, then I would wnat to verify the certificate
before I see the the asssertion So I don't see how this works.
How does this work with unsigned assertions fetched over TLS?
3. Aren't the storage requirements different for thsi mechanism than
for RFC 4474? With 4474, you basically just have one cert that you
hand out all the time. But in this draft, you might generate a new
assertion for each call. How do you garbage collect them?
MAJOR EDITORIAL
Editorially, the mechanisms are scattered throughout the document
without a single, unified statement of how things are intended to
work. This is made worse by the fact that a lot of the document is
just profiling SAML or 4474 without explaining what's being profiled.
For instance:
The SAML assertion MAY contain an <AttributeStatement> element. If
so, the <AttributeStatement> element will nt will contain attribute-value
pairs, e.g., of a user profile nature, encoded according to either
one of the "SAML Attribute Profiles" as specified in
[OASIS.saml-profiles-2.0-os], or encoded in some implementation-
and/or deployment-specific attribute profile.
What's an AttributeStatement? I mean, I can guess, but what is
this for. This isn't helped by the fact that 7.1.5 is fairly
vague about what you do with the assertion (steps 7-11 are
phrased as "this may include the following checks"), which
makes it quite hard to reverse engineer what's intended.
In addition, the document would benefit from a clear statement
of what the security properties it's intended to provide and
which pieces of the system are responsible for providing
each piece.
DETAILED COMMENTS
7.1.3.3.
Step 1 of [RFC4474] Section 6 maps to and is updated by, the
following two steps in this procedure.
Which next two steps? This is really unclear. Can you please provide
a unified description of how verification is done without having
to reference individual substeps of 4474.
7.1.4.1.3.
What is the audience restriction bringing to the party here? what
security properties does it provide?
What is the impact of clock skew in this spec?
7.1.5.
6. Verify that the content of the SAML assertion matches with the
information carried in the SIP message. This may include the
following checks:
This seems unacceptably vague for implementors. How do I know what
to do?
9. Verify that the SAML assertion's <SubjectConfirmation> element
value is set to whichever value was configured at
implementation- or deployment-time. The default value is:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
What does this do?
8.1.
Section 3.7.5.3 Security Considerations:
Support for TLS 1.0 or SSL 3.0 is mandatory to implement.
This implies a normative ref to TLS 1.0 and HTTPS [neither
of which appears in the references] and SSL 3.0, which isn't
an IETF protocol. Also, shouldn't this be TLS 1.1 at this point?
9.
51 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
52 Alice at example.com
53 </NameID>
Wait, aren't you comparing an email address value to a SIP URI?
That seems problematic.
-Ekr
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
contain attribute-value
pairs, e.g., of a user profile nature, encoded according to either
one of the "SAML Attribute Profiles" as specified in
[OASIS.saml-profiles-2.0-os], or encoded in some implementation-
and/or deployment-specific attribute profile.
What's an AttributeStatement? I mean, I can guess, but what is
this for. This isn't helped by the fact that 7.1.5 is fairly
vague about what you do with the assertion (steps 7-11 are
phrased as "this may include the following checks"), which
makes it quite hard to reverse engineer what's intended.
In addition, the document would benefit from a clear statement
of what the security properties it's intended to provide and
which pieces of the system are responsible for providing
each piece.
DETAILED COMMENTS
7.1.3.3.
Step 1 of [RFC4474] Section 6 maps to and is updated by, the
following two steps in this procedure.
Which next two steps? This is really unclear. Can you please provide
a unified description of how verification is done without having
to reference individual substeps of 4474.
7.1.4.1.3.
What is the audience restriction bringing to the party here? what
security properties does it provide?
What is the impact of clock skew in this spec?
7.1.5.
6. Verify that the content of the SAML assertion matches with the
information carried in the SIP message. This may include the
following checks:
This seems unacceptably vague for implementors. How do I know what
to do?
9. Verify that the SAML assertion's <SubjectConfirmation> element
value is set to whichever value was configured at
implementation- or deployment-time. The default value is:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
What does this do?
8.1.
Section 3.7.5.3 Security Considerations:
Support for TLS 1.0 or SSL 3.0 is mandatory to implement.
This implies a normative ref to TLS 1.0 and HTTPS [neither
of which appears in the references] and SSL 3.0, which isn't
an IETF protocol. Also, shouldn't this be TLS 1.1 at this point?
9.
51 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
52 Alice at example.com
53 </NameID>
Wait, aren't you comparing an email address value to a SIP URI?
That seems problematic.
-Ekr
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip