Subject: wrt RFC4474 'absoluteURI' in Identity-Info header field and SIP-SAML implications (was: Re: [Sip] comments on draft-ietf-sip-saml-00)

From: Jeff Hodges <[email-masked]>
Date: Tue, 24 Oct 2006 01:41:40 -0700

Tschofenig, Hannes wrote:
 >
 >> * I'm not clear on how this mechanism works with older sip-identity
 >> implementations. The main issue is whether the URI in the identity-info
 >> header field will return just a certificate, as specified in sip-identity,
 >> or whether it returns a saml assertion. An older sip-identity verifier
 >> will expect a certificate but it will get an assertion if the AS
 >> implements sip-saml. Perhaps you are assuming that the Accept headers or
 >> something are used for this? Somehow this needs to be handled.
 >
 > My understanding was that this got fixed with the SIP Identity draft. I
 > might, however, be worth to double-check it.

I double-checked it, and I think we perhaps have an issue here.

I see that the language of interest has now changed from (bottom of page 14
in -sip-identity-06)..

    The 'absoluteURI' portion of the Identity-Info header MUST contain
    either an HTTP or HTTPS URI which dereferences to a resource that
    contains a single MIME body containing the certificate of the
    authentication service.  These URIs MUST follow the conventions of
    RFC2585 [10] and the indicated resource MUST be of the form
    'application/pkix-cert' described in that specification. ...

..to this at the beginning of the second para of page 15 (in RFC4474)..

    The 'absoluteURI' portion of the Identity-Info header MUST contain a
    URI which dereferences to a resource containing the certificate of
    the authentication service.  All implementations of this
    specification MUST support the use of HTTP and HTTPS URIs in the
    Identity-Info header.  Such HTTP and HTTPS URIs MUST follow the
    conventions of RFC 2585 [10], and for those URIs the indicated
    resource MUST be of the form 'application/pkix-cert' described in
    that specification. ...

Given the revised text above, I'm a tad concerned that implementors will
interpret the 3d sentence to mean that their implementations need _only_
support HTTP/HTTPS URIs pointing to certificates as described in RFC2585, even
though one _can_ interpret the above as also meaning that HTTP/HTTPS URIs
pointing at resources other than certificates and/or CRL files are alloFrom [email-masked] Tue Oct 24 04:46:27 2006
Date: Tue, 24 Oct 2006 01:41:40 -0700
From: Jeff Hodges <[email-masked]>
To: IETF SIP List <[email-masked]>
Subject: wrt RFC4474 'absoluteURI' in Identity-Info header field and SIP-SAML
	implications (was: Re: [Sip] comments on draft-ietf-sip-saml-00)

Tschofenig, Hannes wrote:
 >
 >> * I'm not clear on how this mechanism works with older sip-identity
 >> implementations. The main issue is whether the URI in the identity-info
 >> header field will return just a certificate, as specified in sip-identity,
 >> or whether it returns a saml assertion. An older sip-identity verifier
 >> will expect a certificate but it will get an assertion if the AS
 >> implements sip-saml. Perhaps you are assuming that the Accept headers or
 >> something are used for this? Somehow this needs to be handled.
 >
 > My understanding was that this got fixed with the SIP Identity draft. I
 > might, however, be worth to double-check it.

I double-checked it, and I think we perhaps have an issue here.

I see that the language of interest has now changed from (bottom of page 14
in -sip-identity-06)..

    The 'absoluteURI' portion of the Identity-Info header MUST contain
    either an HTTP or HTTPS URI which dereferences to a resource that
    contains a single MIME body containing the certificate of the
    authentication service.  These URIs MUST follow the conventions of
    RFC2585 [10] and the indicated resource MUST be of the form
    'application/pkix-cert' described in that specification. ...

..to this at the beginning of the second para of page 15 (in RFC4474)..

    The 'absoluteURI' portion of the Identity-Info header MUST contain a
    URI which dereferences to a resource containing the certificate of
    the authentication service.  All implementations of this
    specification MUST support the use of HTTP and HTTPS URIs in the
    Identity-Info header.  Such HTTP and HTTPS URIs MUST follow the
    conventions of RFC 2585 [10], and for those URIs the indicated
    resource MUST be of the form 'application/pkix-cert' described in
    that specification. ...

Given the revised text above, I'm a tad concerned that implementors will
interpret the 3d sentence to mean that their implementations need _only_
support HTTP/HTTPS URIs pointing to certificates as described in RFC2585, even
though one _can_ interpret the above as also meaning that HTTP/HTTPS URIs
pointing at resources other than certificates and/or CRL files are allowable,
as long as the resource resolves one way or another into a "..certificate of
the authentication service" (1st sentence above) -- as in a URI pointing to a
SAML assertion containing such a cert.

thoughts?

thanks,

=JeffH

_______________________________________________
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

---

From: Shida Schubert <[email-masked]>
Date: Mon, 30 Oct 2006 21:34:44 -0800

Hi Jeff;

I saw the change in text below but the text following the
changed text concerns me a bit which may need to be changed
as well.

## Text from RFC4474 page 14 ##########
"HTTP and HTTPS URIs MUST follow the conventions of
RFC 2585 <http://rfc.sunsite.dk/rfc/rfc2585.html> [10], and for
those URIs the indicated resource MUST be of the form
'application/pkix-cert'"

It reads like resource indicated by either HTTP or HTTPS has to be
a certificate, not something containing the certificate. Or I am reading
the text above incorrectly.

Regards
Shida

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 31 Oct 2006 08:54:02 +0100

Hi Jeff,
Hi Shida,

> the text above incorrectly.

That's also my reading of the text.

To me this means that we have to define a new header as a consequence.

Ciao
Hannes