[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Joel,

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

On 10/10/06, Joël Repiquet <joel.repiquet at tech-invite.com> wrote: 
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?

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:bob at example.com".  Alice's UA
  receives the certificate and can use it to encrypt a message to Bob.

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:bob at example.com".  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?


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":
----------------

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.


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


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.


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:
   Event: credential

added

   PUBLISH sips:alice at atlanta.example.com SIP/2.0
   ...
   Event: credential
   Content-Type: multipart/mixed;boundary=boundary
   Content-Disposition: signal


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

done


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.

done


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

done


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.

done

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip