Subject: [Sip] SIP SAML Review by Erkki Koivusalo

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 18 Jun 2007 11:34:52 +0200

Hi all, 

Here is a review by Erkki:
 
-----Ursprüngliche Nachricht-----
Von: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) [mailto:[email-masked]] 
Gesendet: Dienstag, 12. Juni 2007 13:43
An: Tschofenig, Hannes
Betreff: RE: [Sip] draft-ietf-sip-saml-02

Hi,

Basically this is what I found before looking into the
open issues list:

---
As this draft reuses the mechanisms specified in RFC 4474
(more specifically the Identity-Info header) I am not sure 
how implementations complying to RFC 4474 or this draft
are able to interoperate.

Is it straightforward for the recipient (UAS) of the 
SIP request to find out whether the Identity-Info header
contains an URL pointing to the certificate of the AS
or the SAML assertion ? I assume the UAS finds it out
only from the MIME type of the HTTP response, correct ? 

Since the UAS verification steps of RFC 4474 and 
draft-ietf-sip-saml differ from each other, what happens 
if UAS supporting only RFC 4474 receives an Identity-Info 
header pointing to a SAML assertion or vice versa ? 
Can such an UAS gracefully handle the situation and if 
yes, how ?

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

   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.

Nits:

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

_______________________________________________
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