Subject: Re: [Sip] WGLC: draft-ietf-sip-certs-01

From: Joël Repiquet <[email-masked]>
Date: Tue, 10 Oct 2006 13:06:13 +0200

Hi,

Regarding the "cert" draft, I have some remarks regarding
the "Overview" and "Examples" sections, plus
some editorial notes.

Joël

In "3. Overview":
---------------

There are in Bob's domain 3 servers: Proxy, Auth and Cred.

Page 7, when:
"Alice decides that she wishes to discover Bob's
certificate, Alice's UA sends a SUBSCRIBE message to Bob's AOR.
The proxy in Bob's domain routes this to the credential server
via an authorization service".

What do you mean by "authorization service"? conversely to the
"authentication service" and the "credential service" there is no
clear standardization of it for SIP. Is it related
to some trait-based mechanism? what would be its
role in this very case and why not to have the proxy route
the SUBSCRIBE request directly to the credential server?

Likewise, in the same paragraph:
"The credential server returns a NOTIFY that contains Bob's public
certificate in the body.  This is routed through an authentication
service that signs that this message really can validly claim to be
from the AOR "sip:[email-masked]".  Alice's UA receives the
certificate and can use it to encrypt a message to Bob."

According to the figure page 6, the "authentication service" is provided by
the same server as the "authorization service". Typically, it would be provided -- as a
general service for the domain -- by the Proxy.
Is not the Auth server superfluous, or is there any reason we need one?

In "8. Examples":
----------------

In 8.1 we see that the authentication service is provided by the Credential
server. I would add a "date" header since it is mandatory.

In 8.2, first paragraph:

"When Alice's UA wishes to publish Alice's public and private keys to
the credential service, it sends a PUBLISH request like the one
below.  This must be sent over a TLS connection in which the other
end of the connection presents a certificate that matches the
credential service for Alice and digest challenges the request to
authenticate her."

What do you mean by "that matches the credential service"? the TLS server
certificate is not related to the credential service.

In the PUBLISH request, I would add the header:
Event: credential

Editorial remarks:
-----------------

In "1. Introduction" (2nd paragraph):
Replace:
In addition, this specification provides a which mechanism allows SIP
by:
In addition, this specification provides a mechanism that allows SIP

In "4. UA Behavior with Certificates" (last paragraph):
Replace:
be valid and legal for that UA to send a 302 redirecting the call to
Charlie.
by:
be valid and legal for that UA to send a 302 redirecting the call to
Bob.

In "6.5. NOTIFY Bodies":
Replace:
other type.  The Content-Disposition MUST be set to "signal", as
defined in as defined in [16].
by:
other type.  The Content-Disposition MUST be set to "signal", as
defined in [16].

In "12. References": replace [2] and [19] by:

[2]   Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.

[19]  Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation
Protocol (SIP) Event Notification Extension for Resource Lists",
RFC 4662, August 2006.

_______________________________________________
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: "Jason Fischl" <[email-masked]>
Date: Sun, 22 Oct 2006 23:13:08 -0700

Hi Joel,

Many thanks for your comments and sorry for the delay in responding.
See inline for my detailed responses.

> In "3. Overview":
We meant Authentication Service as defined in RFC 4474. Updated text here:

   Some time later Alice decides that she wishes to discover Bob's
   certificate so that she can send him an encrypted message or so that
   she can verify the signature on a message from Bob. Alice's UA sends
   a SUBSCRIBE message to Bob's AOR.  The proxy in Bob's domain routes
   this to the credential server via an "authentication service" as
   defined in [2].  The credential server returns a NOTIFY that contains
   Bob's public certificate in the body.  This is routed through an
   authentication service that signs that this message really can
   validly claim to be from the AOR "sip:[email-masked]".  Alice's UA
   receives the certificate and can use it to encrypt a message to Bob.

> the same server as the "authorization service". Typically, it would be
> provided -- as a general service for the domain -- by the Proxy.

The "authentication service" is the RFC 4474 identity service and
could be provided by the proxy. I think the text in this paragraph is
ok once we made the changes as provided above.

> In "8. Examples":

Since many other headers are not included in this example, I don't
think the Date is necessary here.

> certificate is not related to the credential service.

You raise a valid point. Here's some alternate text:

   When Alice's UA wishes to publish Alice's public and private keys to
   the credential service, it sends a PUBLISH request like the one
   below.  This must be sent over a TLS connection directly to the
   domain of the credential service.  The credential service presents a
   certificate where the subjectAltName contains an entry that matches
   the domain name in the request line of the PUBLISH request and digest
   challenges the request to authenticate her.

> In the PUBLISH request, I would add the header:
added

    PUBLISH sips:[email-masked] SIP/2.0
    ...
    Event: credential
    Content-Type: multipart/mixed;boundary=boundary
    Content-Disposition: signal

> Editorial remarks:
done

>    be valid and legal for that UA to send a 302 redirecting the call to
done

>    other type.  The Content-Disposition MUST be set to "signal", as
done

>          Protocol (SIP) Event Notification Extension for Resource Lists",
done