Early Review of draft-ietf-sip-saml-
review-ietf-sip-saml-secdir-early-harrington-2008-12-13-00

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I am not knowledgeable in SIP or in SAML, so another reviewer has also
reviewed this document.

Executive Summary:

I believe this was an early review request, not a review for last call
or IESG telechat. The document appears to be in an early stage of
maturity. I found some of the English difficult to parse. It could
stand significant WG review. The hard-to-parse English will make it
difficult for implementers to interpret the text the same way, and
could cause implementations to not interoperate properly. The English
MUST be cleaned up to enable getting the security right.

Way way too many options and loose language; this really needs to be
tightened up.

Security Review:

In section 4, the document states "In oder for any trait-based system
to be practical, participating entities must agree on the attributes.
And then it goes on to say we don't define attributes or explain how
to discover what attributes are supported. Then why bring this up? I
mention it in the security review portion for 2 reasons:
1) There are so many things this document raises and then does not
discuss it took a while before I could determine what this document
actually DID discuss.
2) Each of the things raised and not fully discussed seemed to be
options, and this document describes a profile of options on options
on options. There is a lot of text here that says this could happen,
and this could happen and this could happen - how about some nice
RFC2119 langauge describing what MUST/SHOULD/MAY happen so that
implementers can interoperate? I get very concerned when I see so many
options. I doubt anybody could ever tell whether security was achieved
or not because there are so many optional pieces to consider.

section 7.1.3 step 2 mentions cached credentials. The security
Considerations do not discuss cached credentials.

Security Considerations have a nunber of SHOULDs (or shoulds) but
little discussion of when it is appropriate to not do so. In a number
of cases I wondered why these were not MUSTs. For example, in
countermeasures, "should be signed" - why not "MUST be signed"?

The <SubjectConfirmation> element attribute methd SHOULD be set to
XXXX, but MAY be set to something else. Are we standardizing here?
What is the reason it SHOULD be set to XXXXX, and under what
circumastnaces woudl it be appropriate to not do so?

"Note that any SIP message may be used to convey the SAML assertion
even though SIP INVITE may be th emost approrpiate candidate." - are
we standardizing, or writing something that allows any variation of
implementation to claim compliance?

10.3 "The SAML assertion may contain several elements to prevent
replay attacks. There is, however, a clear tradeoff between the
replaying an assertion and re-using it over multiple SIP
exchanges/sessions." - So are we standardizing some guidelines at
least, to help guide implementers to develop something that will
interoperate reasonably?

Other comments:

In the Introduction, it says various means of authorization exist, and
it lists 3 types, then says the authors selected SAML (which was not
one of the three).

I found the terminology section confusing.

It would be easier on readers if citations were of the form "Title"
[RFCXXXX] rather than just [RFCXXXX]. To know what document RFCXXXX
refers to requires looking up the document or looking in the
references, which interrupts reading.

Hope this helps,

David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com

_______________________________________________
secdir mailing list
secdir at mit.edu


https://mailman.mit.edu/mailman/listinfo/secdir


_______________________________________________
secdir mailing list
secdir at ietf.org


https://www.ietf.org/mailman/listinfo/secdir