Hi all,
Here is a review by Erkki:
-----Ursprüngliche Nachricht-----
Von: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) [mailto:[EMAIL PROTECTED]
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 PROTECTED] or [EMAIL PROTECTED] ?
- Is Bob either [EMAIL PROTECTED] or [EMAIL PROTECTED] ?
- 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
