[Sip] comments on sipping-certs

[Jonathan Rosenberg <[e-mail]>]

Cullen, Jon

Some comments on the sipping-certs draft.

The document is in need of a picture that shows the overall architecture 
- something along the lines of a protocol model as described in:

http://www.ietf.org/internet-drafts/draft-iab-model-02.txt

I'd suggest that the picture show the credential server, identity 
service, and clients on both sides, along with a single section 
overviewing operation.

One technical aspect of this bothered me. My understanding is that the 
NOTIFY from the credential server containing the cert has to be signed 
by an identity service in order to provide an indentity binding to the 
cert. However, in this case, the notification is *not* sent by the user 
in the From/identity field! It is sent by an entity which is authorized 
to send requests for that identity, and is going to have a tight trust 
relationship with the authentication service.

The spec is quite loose with terminology; I point out some of these 
below, but it needs a careful scrub in this area.

You need to formally define the various event packages you are using. I 
would suggest aligning the package names with the terminology you are 
using (i.e., a credential and certificate package).

Generally, a lot of details are needed in various places. It reads much 
like a proposal and needs to move on to become a protocol specification.

I think section 7 and 10.2 are out of scope. This is a fairly orthogonal 
piece of work that treats how offer/answers are done using s/mime. It 
does not appear to depend at all on the fact that the certificates were 
obtain through the mechanism in this draft.

section 11.1 is out of place. It belongs in a section that defines 
client behavior for obtained a cert.

also, thinking about this, it seems to me that the mechanism is 
susceptible to SBCs, which would be able to tap into the media stream. 
They would do this by handing out a different cert to subcsribers than 
the one you hand it. Then, any encrypted media for you comes to the SBC, 
which decrypts and re-encrypts with your key. Badness.

Might want to mention this in the security considerations section, and 
recommend that a UA subscribe to its own cert using a different identity 
in order to verify that the proper cert is being handed out.



detailed comments:

> SIP provides a mechanism for end to end encryption and integrity
>    using S/MIME,

s/end to end/end-to-end

> S/MIME has not been widely implemented or deployed due to the
>    complexity of providing a reasonable certificate distribution
>    infrastructure.

This is a bold statement; there are many reasons, of which this is one.

> Combined with the Identity [2] work, this work allows users to have
>    certificates that are not signed by any well known certificate

s/work/specification

> This mechanism allows UAs such as IP phones to enroll
>    and get their credentials without any more configuration information
>    than they commonly have today, without any extra effort or key clicks
>    by the end user, and without any extra expense for the end user.

this is one long run on sentence

> This mechanism also lets the UA discover and retrieve the public
>    certificate for any other user and find out about certificate
>    revocations.

worth noting that it actually provides more than this; its not just 
users, but any resource associated with an AOR.

> The general approach is to provide a new SIP service referred to as a
>    Credential Server that allows UAs to subscribe to some other user's
>    certificate. 

a server provides a service, it isn't a service

> The identity of the certificate can be vouched for
>    using Identity [2] work, which uses the domain's certificate to sign
>    that the NOTIFY really is from the Credential server for the request
>    user in that domain.

This is not true. The signature does not verify this; the signature 
verifies that the request came from a server that has access to the 
domain keys.

> The Credential Service can manage public
>    certificates as well as credentials that include the user's private

you sometimes use credential service, sometimes credential server

also, this text is confusing since credentials apparently contain 
certificates according to your definition. So, saying that they manage 
certifications *as well as* private keys is redundant

> The Credential Server authenticates UAs that
>    are changing credentials or requesting private keys using a shared
>    secret that both the UA and the Server know.

in this sentence, it is not obvious that "using a shared secret" applies 
to both changing credentials and requesting private keys.

Also, my understanding is that you would request credentials as well, 
not just the private key (i.e., there is no way to get just one)

> Typically this will be
>    the same shared secret that is used in Register with the Registrar
>    for the domain.

s/Register/REGISTER

> The mechanism described in this document works for both self signed
>    certificates and certificates signed by a well known certificate
>    authority;

you just said that in the preceding paragraph

> Previous versions of this work proposed using HTTP instead of SIP for
>    communicating with the Credential Server. 

this needs to be changed now

generally, on its way to an rfc, it needs to become less conversational, 
  statements like "this work" and "previous versions" need to go

> The key difference with
>    using SIP is that a certificate can be revoked by sending a new
>    NOTIFY; in the HTTP based scheme, the certificates were cached for a
>    predefined period of time, typically one day, so that a revocation
>    could take effect only after the cache had expired.

there are other differences too, i mentioned some of the benefits of 
presence integration. Its a good idea to compare the pros and cons now 
that http becomes optional.

also the text is confusing because the certificate can also be revoked 
in sip by having it expire

> 2.  Conventions

change to definitions

>  The certificates discussed in this draft are generally self signed
>    and use the mechanisms in the Identity work [2] to vouch for their
>    validity.

the "work" thing again

> 3.  Goals
> 
>    This work allows S/MIME to be used to meet the following goals and
>    requirements:

I think this section needs to become the introduction. Furthermore, much 
of the introduction is sort of a weak overview of operation. You should 
move that text into a stronger overview of operation section.

>  Not require any efforts (zero clicks) on behalf of an end user to
>       acquire and start using end to end security.

s/efforts/effort
s/end to end/end-to-end



>  Not require any extra cost on a per user basis in deploying
>       systems that support this.  It does require that the domain have a
>       web server style certificate that is either self signed or signed
>       by a well known CA.

this is clearly false; I'll require incremental CPU for each user to 
process subscriptions for their cert, and incremental storage.

> Allow negotiation of E2E encrypted SRTP sessions.

please use end-to-end consistently

> Allow end to end encryption and integrity of SIP bodies that may
>       be delivered in SIP signaling, such as page mode MESSAGEs or
>       NOTIFY bodies in presence.

integrity? i usually think of signature as the way we provide integrity, 
and the certs mechanism isn't used for that

hmm. if you want to encrypt presence documents in NOTIFY, what uri do 
you use to get the certificate? is it the identity used in the 
subscription, or the gruu in the contact? should a credential server 
support subscriptiosn to gruu to get certificates?

> Allow end to end encryption and integrity of SIP bodies that may
>       be delivered in SIP signaling, such as page mode MESSAGEs or
>       NOTIFY bodies in presence.

i had to read this a few times to realize you were talking about the 
case where a user wants to discover someone elses certificate; since a 
certificate is included in the credential i initially found this confusing

> If the identity asserted by the Authentication Service
>    does not match the identity requests, t

what are "identitiy requests"?

in this section, you need to say more. discuss when a ua might initiate 
the subscription, how long it will hold it. Need ot mention the 
keepalive issue. Also mention that these subscriptions won't generally 
be challenged.

> which will result in a message containing both an
>    application/pkix-cert body and an application/pkcs8 body that has the
>    associated private key information for the certificate. 

I think you mean that the notifications will contain bodies of this type.

> credential that contains both an
>    application/pkix-cert and an application/pkcs8 body.

MUST contain

>  may be configured with a specific name for the Credential Server;
>    otherwise it defaults to the name of the domain in the User's AOR.

is this a new dns usage? I think you mean that we do rfc3263 
resolutionon a sip uri

> The TLS connection MUST present a certificate that matches the
>    expected name for the credential server, so that the UA knows it is
>    talking to the correct server.

this is not detailed enough. anyway i think it is covered in rfc3261, 
you should reference that

section 6 blends together a discussion of handling of credentials and 
certs. For example, it is unclear from the last paragraph on page 5 
whether or not the server digest challenges requests for certs (it 
should not)

> Otherwise it sets up a subscription and forms a NOTIFY with the
>    certificate in the body and the From header field value set to the
>    request URI of the SUBSCRIBE. 

how does this work if the request is proxied or retargeted in any way?

> It MUST send this NOTIFY through an
>    Authentication Service (as described in Identity [2]) or implement an
>    Authentication Service itself.

it can't just do that; the notifies are sent within the dialog. The 
subscribe request has to be routed through the authentication service.

> When a Credential Server receives a SUBSCRIBE for a credential, the
>    Server has to authenticate and authorize the UA and validate that
>    adequate transport security is being used. 

how is authorization done?

> Once the UA has authenticated with the Server, the Server can set up
>    a subscription and send a Notify message that MUST contain the
>    credentials.  This NOTIFY message is sent thought an Authorization
>    Service in the same way as the certificate subscriptions.

s/thought/through

authorization service? perhaps authentication

>  Next Alice sends a SIP MESSAGE message to Bob and can encrypt the
>    body using Bob's public key as shown below.  Thought outside the
>    scope of this document, it is worth noting that IM messages often

s/thought/though

>  Likewise, the authentication
>    of the user submitting the private key should be equivalent to or
>    higher than the key being transmitted.

its going to be digest; i'm not sure what this means

> If a UA receives a
>    certificate in a TLS connection that it cannot chain back to a well
>    known CA but is otherwise valid (i.e.  a self signed certificate), it
>    MAY ask the user if it wishes to allow this certificate to be used,

why should we allow this? seems like a recipe for trouble

> If a particular credential needs to be revoked, the new credential is
>    simply published to the Credential Server.  Every device keeping this
>    current in its cache will have a subscription to the credential and

this current? i think you mean the credential that was just revoked

 >  certificate for the identity in the Original URI.  This means that
 >       the certificate should only be indexed in the certificate cache by
 >       the value of the original URI, not by the value of all the
 >       identities found in the SubjectAltName list.

that said, i think the cert should be a valid standalone cert. i think 
we should require, at should or possibly must, that the subjectaltname 
match the identity that the authentication service will assert for that 
user. You need a section on generating self-signed certs, i think.

 > The Authentication Service validates
 >    that this message did come from the identity claimed in the From and

it won't though; it will come from the credential service which cannot 
claim it is the identity in the from

 > Only the UA that can authenticate as this user can tamper with this
 >    body, so the owner of the identity can provide a false public key but
 >    other users cannot.

or the authentication service itself, or anything with the private 
domain keys





-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip