$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 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
