Subject: Re: [VIPR] An alternative to the VIPR ticket

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Oct 2011 15:53:31 -0700

During the last conference call, this proposal was criticized as been a
significant change from the way SIP is processing TLS requests.  My research
shows that it is not the case.

First of all, let's define exactly what SIP, without even talking about VIPR, is
doing regarding TLS.  The best place for this is RFC 5922.  We can skip the
client behavior discussion (section 7.3) because neither VIPR or my proposal
suggest any modification to this procedure.  Here's what RFC 5922 says about the
server behavior (aka client certificate):

"  When a server accepts a TLS connection, the server presents its own
   X.509 certificate to the client.  Servers that wish to authenticate
   the client will ask the client for a certificate.  If the client
   possesses a certificate, that certificate is presented to the server.
   If the client does not present a certificate, the client MUST NOT be
   considered authenticated.

   [...]

   When authenticating the client, the server MUST obtain the set of SIP
   domain identities from the client certificate as described in
   Section 7.1.  Because the server accepted the TLS connection
   passively, unlike a client, the server does not possess an AUS for
   comparison.  Nonetheless, server policies can use the set of SIP
   domain identities gathered from the certificate in Section 7.1 to
   make authorization decisions.

   For example, a very open policy could be to accept an X.509
   certificate and validate the certificate using the procedures in RFC
   5280 [6].  If the certificate is valid, the identity set is logged.

   Alternatively, the server could have a list of all SIP domains the
   server is allowed to accept connections from; when a client presents
   its certificate, for each identity in the client certificate, the
   server searches for the identity in the list of acceptable domains to
   decide whether or not to accept the connection.  Other policies that
   make finer distinctions are possible."

In other words, the SIP server (or proxy) does whatever it thinks is necessary
with the client certificate, and it does not seems that even following RFC 5280
is required (note in particular that nowhere it is said that the validation must
use a public trust anchor).

VIPR itself adds very little to the requirements of RFC 5922.  Here is what
- -sip-antispam says about TLS and the ticket:

"  The Border Element will receive the TLS ClientHello which begins the
   TLS handshake.  The Border Element will present its own configured
   cert.  Once TLS handshaking is complete, the Border Element notes the
   domain from the SubjectAltName on the other side of the TLS
   connection, and associates it with that connection.

   Next, the Border Element will receive an INVITE.  This INVITE will
   contain a ticket in the ViPR-Ticket header field value.  The Border
   Element extracts this header field.  This call flow assumes it is
   present.  The Border Element parses it, and obtains the epoch value
   encoded in the ticket.  This is matched against the current epoch
   value for the configured password.  If they match, processing
   continues.  The Border Element verifies the signature is correct.
   Next, it examines the start and stop time of the validity.  If the
   current time is between the start and stop times, the check is
   passed.  Next, the Border Element checks the granted-to domain in the
   ticket.  It compares that domain against the domain name in the
   SubjectAltName of the peer on the other side of the TLS connection,
   as noted above.  Next, it takes the Request-URI of the SIP INVITE.
   That will be of the form sip:+number@domain.  If it is not in that
   form, and if the number does not begin with a plus, the request is
   dropped.  The value, including the plus, is then compared to the
   number in the ticket.  If it is equal, the check has passed.  The
   Border Element leaves the header field in the request, but forwards
   to the Call Agent."

The only policy that is added to what RFC 5922 says is that the granted-to
domain in the ticket must be equal to the domain in the SubjectAltName of the
client certificate.  Here too, not a word about a public trust anchor.

Now back to my proposal.  The first thing is that the client certificate must be
validated using the CA of the VIPR server as trust anchor, which is already what
a SIP server could do.  It validates according to the rules in RFC 5280, which
is equivalent to verifying the signature of the ticket and the start/stop
validity.  The SubjectAltName in the client certificate (which is not even
required to be used in standard SIP) can be checked against the domain part of
the From header of the INVITE.  The phone number and the granting-domain (which
not even verified in VIPR) can be stored as an URI in the Issuer Alternative
Name extension in the client certificate and be validated against the
Request-URI of the INVITE.  The granting node can be also be stored as a reload
URI in an Issuer Alternative Name extension.

So in conclusion, my proposal does not change what a normal SIP stack is doing,
because the specification does not say what a SIP stack should do with a client
certificate.

(Note that to -sip-antispam should also be added some text saying that RFC 5923
must be used, because there is no way to create an additional TLS connection in
the other direction for a subsequent SIP transaction).

On 09/03/2011 12:06 PM, Marc Petit-Huguenin wrote:
> In the current specification, the PVP server builds and signs a VIPR ticket, and
> send it back to the PVP client, that passes it to the Call Agent/ Border Element
> (CA/BE).  The CA/BE will insert this ticket in the next SIP INVITE to the remote
> CA/BE, which will check the validity of the ticket and the domain of the TLS client.
> 
> There is multiple things that bother me with this process:
> 
> - The verification of the ticket use HMAC-SHA1, and so the same password has to
> be provisioned in both the CA/BE(s) (to verify the ticket) and the VIPR
> server(s) (to generate the ticket).
> - The ticket can be used without TLS (we all know that implementers think of
> MUST as SHOULD and SHOULD as MAY).
> 
> I would like to propose an alternative that is simpler to implement and, I
> think, more secure than the ticket.
> 
> Instead of using a symmetrical key, the local VIPR server generates an RSA key
> pair, with the public key distributed to the CA/BE(s).  After a successful PVP
> connection, the remote PVP client sends a PKCS#10 certificate request,
> containing the domain name and signed with a private key[1].  The local PVP
> server generates a new certificate[2], sign it with its private key and send it
> back to the remote PVP client, which pass it back to the remote CA/BE.
> 
> The remote CA/BE will use the certificate received to establish the TLS
> connection for the SIP transactions to the local CA/BE, which will use a
> standard CA based certificate for its domain.  The local CA/BE will be able to
> verify with the VIPR public key that it issued the certificate, then will
> validate the standard parts of the certificate (expiration date and so on).
> 
> There is multiple advantages to this proposal:
> 
> - The private key is stored only in the VIPR server, or better in a physical
> token.
> - VIPR does not work without TLS for the SIP connection.
> - There is plenty of commercial or free TLS and X.509 implementations that have
> years of experience and testing, which is not the case for the ticket proposal.
> - Security agility is provided by TLS.
> - No additional SIP Header.
> - Because the ticket verification process is folded into the client certificate
> verification, there is less resources needed.
> 
> 
> [1] This is the private key of the CA/BE, so the CA/BE needs to upload the
> PKCS#10 file in the VIPR server.  Depending on the architecture used, each CA/BE
> can use a different PKCS#10 or the same, which means that the PVP server must be
> able to process more than one PKCS#10 and send back more than one certificate on
> one PVP connection.
> 
> [2] The certificate sent back can directly contain the SIP routes, increasing
> the overall security.  One possible mapping from the ValExchange response to the
> certificate could be:
> 
> - Unique ID: serialNumber
> - Epoch: issuer
> - salt: N/A
> - integrity: signature
> - Validity: validity
> - Phone Number: subjectAltName uniformResourceIdentifier tel:+14085551234
> - Node-ID: subjectAltName uniformResourceIdentifier
> reload://0110123456789ABCDEF0123456789ABCDEF/
> - Granted domain: subjectAltName dNSName example.com
> - Granting domain: implicit in routes
> - Route(s): subjectAltName uniformResourceIdentifier
> sip:[email-masked]:371;maddr=10.1.1.1
> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Michael Procter <[email-masked]>
Date: Thu, 13 Oct 2011 08:29:46 +0100

[...]
> because the specification does not say what a SIP stack should do with a client

What you describe is that the server side of the connection will need
to validate a client certificate whatever happens, and changing the
ticket to a certificate does not substantively change the validation
process.  It does force the ticket validation to the edge of your
network though, which having the ticket in a header field doesn't.
Since ticket validation is a new process introduced with ViPR, this
may be a reasonable change.

However, what is overlooked in this analysis is that the client side
must present a different certificate on a per-call basis.  Most
implementations that I have seen tend to have a fairly statically
configured certificate (or several, but not lots) that is valid for
the duration of the process/between scheduled maintenance.  Having the
certificate change on a per-call basis is a change for these
implementations.  How significant a change depends on their
architecture, but it is a change nonetheless.

Why does this matter?  With the ViPR ticket in a header field, I can
route ViPR traffic out in much the same way as I route other SIP
traffic.  Granted it has an additional header, but that doesn't
substantively change the job my egress points perform.  With a ViPR
certificate instead of a ticket, my egress points need to be
sufficiently ViPR-aware to know to use a dynamically selected
certificate, and how to get hold of that certificate.  Not
insurmountable problems, but ones that are introduced by changing to a
certificate over a simple header field.

There may be other problems (Jon seemed to jump on the change quite
fast so he may have more reasons), but this is the one that struck me.
 I think this change warrants wider discussion before deciding whether
to adopt or not.

Regards,

Michael

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 13 Oct 2011 07:54:05 -0700

> architecture, but it is a change nonetheless.

True.

> certificate over a simple header field.

Another argument to add to your point is that using a different certificate for
each different phone number reduces the possibility of session caching or
session resumption.

>  I think this change warrants wider discussion before deciding whether

OK, so I think that there is a way to keep the properties of the ticket (can be
processed separately from the TLS server processing, does not require to
dynamically choose the certificate on the client side), and still let "advanced"
implementations not use this.

The first step is to simply say that an X.509 certificate is a better
replacement for the ticket as defined currently, independently to its usage in TLS:

- - Existing and proven libraries.
- - Support for asymmetrical keys.
- - Security agility.

With this first step, we use the X.509 certificate just like the current ticket,
as a container to carry the parameters in the ticket.  This means that the
border element on the originating side establishes a TLS connection using a
static client certificate, and then send an INVITE with a vipr-ticket header
containing the X.509 certificate received from the PVP transaction and encoded
in base64.  The border element on the receiving side verifies the client
certificate as per RFC 5280, then verifies the certificate inside the
vipr-ticket (or pass it to another element to verify this second certificate).
At this point we have exactly the same process than before, expected for the
container used to carry the ticket values.

Now let's add two very small modifications on the server processing side:

- - The VIPR server CA is added to the list of public trust anchor that the TLS
server uses to validate the client certificate.
- - If there is no vipr-ticket in the INVITE, the client certificate received from
the other side is used as if it was received in a vipr-ticket header field.

With this, we now can have the TLS client choose to either work as a standard
SIP client, i.e. it uses its static client certificate for the TLS connection,
and put the certificate received from PVP in the vipr-ticket field, or work more
dynamically, by using directly the certificate received from PVP as the client
certificate for the TLS connection.  On the server side all the processing can
be done at one point, or it can have the ticket processing delegated to another
server.

This way we have the best of the two worlds.

- -- 
Marc Petit-Huguenin

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Oct 2011 13:25:45 -0400

On the last design call, I expressed a number of reservations about this change, but the main one was that it was insufficiently motivated. For my part, anyway, I was curious to understand what the problem was with the existing mechanism that you believed this solved - once we understood the problem, we could understand the potential design space to solve it. I had thought we'd left the call understanding that you were going to explain the problem; instead, you're pretty much defending a solution here without reference to what the problem is. 

I've taken a look at the sketch of your proposal below, but it's a bit too high level for me to really understand its properties. I will say that if your argument is:

> my proposal does not change what a normal SIP stack is doing,

I have to disagree. 5922 cites the relevant text in 3261:
      Each side of the connection SHOULD verify and inspect the
      certificate of the other, noting the domain name that appears in
      the certificate for comparison with the header fields of SIP
      messages.
Now by today's standards, that text is somewhat vague, but back when we wrote that the idea was basically that you compare the domain in the cert (typically the CN or SubjectAltName) used in TLS with the supposed identity of the sender of a request over that transport connection (typically given in the From header field value). That works when the cert has been issued by an authority capable of ascertaining who owns domain names. 5922 introduces qualifications to this in order to support cases where a virtual hosting service has a certificate with multiple names, for example, but it isn't really chipping away at the basic operation. ViPR today, as you cite, requires that same reference integrity between the granted-to field of the ticket and the domain in the cert used in TLS. Again, the idea here is that the granted-to has to correspond with a cert issued by an authority who actually verifies ownership of domain names. Thus, purely on the basis of capturing a ticket with a granted-to of example.com, you cannot impersonate example.com unless you also control a cert issued for that domain by a CA, and incidentally a CA trusted by the target ViPR domain. If you are arguing for a case where a ViPR domain that is not in a position to certify who owns what domain names is issuing certificates that are used for TLS, then you are changing how certificate usage in SIP is commonly understood.

>From what I can gather about your proposal, I suspect you underestimate the complexity of acting as a CA, enrolling peers in the CA and enabling them to use those credentials properly - what it means for two entities that have no pre-existing relationship to suddenly treat each other as trust anchors. I furthermore suspect that TLS operations would not be optimal in this sort of model. Is the antispam property something that is best bound to the transport or to a single SIP request? The use cases, ultimately, answer that for us: consider two large ViPR domains that want to exchange traffic - should they have to establish a new TLS connection for each called number, or should they be able to send signaling for many calls over a single TLS connection? Are there cases where the hop-by-hop property of TLS weakens the utility of the mechanism? Are there environments we want ViPR to be useful where TLS is not available? 

Jon Peterson (as an individual)
NeuStar, Inc.

On Oct 12, 2011, at 3:53 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> During the last conference call, this proposal was criticized as been a significant change from the way SIP is processing TLS requests.  My research
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk6WGmoACgkQ9RoMZyVa61dW3gCeMcKcsvqK27kk2ZW1mRMPYdep
> 3ZcAn3EIFv8hlBZop57YIDN7HCOUtixU
> =v31B
> -----END PGP SIGNATURE-----
> _______________________________________________
> VIPR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vipr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 13 Oct 2011 11:40:54 -0700

On 10/13/2011 10:25 AM, Peterson, Jon wrote:
> 
> On the last design call, I expressed a number of reservations about this
> change, but the main one was that it was insufficiently motivated. For my
> part, anyway, I was curious to understand what the problem was with the
> existing mechanism that you believed this solved - once we understood the
> problem, we could understand the potential design space to solve it. I had
> thought we'd left the call understanding that you were going to explain the
> problem; instead, you're pretty much defending a solution here without
> reference to what the problem is.

I thought I did this, but here is my list of problems associated with the ticket
as currently defined:

- - Use of a symmetrical key, which has to be shared between different boxes if
the generation of the ticket is done in a different box than the verification of
the ticket.
- - No security agility.
- - Code has to be written from scratch for both the generation and the
verification of the ticket.

> 
> I've taken a look at the sketch of your proposal below, but it's a bit too
> high level for me to really understand its properties. I will say that if
> your argument is:
> 
>> my proposal does not change what a normal SIP stack is doing, because the
>> specification does not say what a SIP stack should do with a client 
>> certificate.
> 
> I have to disagree. 5922 cites the relevant text in 3261: Each side of the
> connection SHOULD verify and inspect the certificate of the other, noting the
> domain name that appears in the certificate for comparison with the header
> fields of SIP messages.  Now by today's standards, that text is somewhat
> vague, but back when we wrote that the idea was basically that you compare
> the domain in the cert (typically the CN or SubjectAltName) used in TLS with
> the supposed identity of the sender of a request over that transport
> connection (typically given in the From header field value). That works when
> the cert has been issued by an authority capable of ascertaining who owns
> domain names. 5922 introduces qualifications to this in order to support
> cases where a virtual hosting service has a certificate with multiple names,
> for example, but it isn't really chipping away at the basic operation. 

Let me offer a more complete quote of RFC 5922:

" RFC 3261 [2], Section 26.3.2.2, only tells Proxy-B to "compare the
  domain asserted by the certificate with the 'domainname' portion
  of the From header field in the INVITE request".  The difficulty
  with that instruction is that the domainname in the From header
  field is not always that of the domain from which the request is
  received."

So here RFC 5922 acknowledges that doing this verification is not possible in
all cases.  The minimum should have been to do an RFC 5280 validation, but even
that is not required.

> ViPR
> today, as you cite, requires that same reference integrity between the
> granted-to field of the ticket and the domain in the cert used in TLS. Again,
> the idea here is that the granted-to has to correspond with a cert issued by
> an authority who actually verifies ownership of domain names. Thus, purely on
> the basis of capturing a ticket with a granted-to of example.com, you cannot
> impersonate example.com unless you also control a cert issued for that domain
> by a CA, and incidentally a CA trusted by the target ViPR domain. If you are
> arguing for a case where a ViPR domain that is not in a position to certify
> who owns what domain names is issuing certificates that are used for TLS,
> then you are changing how certificate usage in SIP is commonly understood.

Yes, you have a point here.  Verifying the granted-to domain at call time will
prevent someone to use a stolen ticket, and will prevent the granted-to domain
to sell their tickets (although a domain can sell its private key also with the
tickets).

So if this verification is really that important (still thinking about this), I
guess that using the ticket as the client certificate is a problem.  But in any
case I still think that using an X.509 certificate in the Vipr-Ticket field is a
better solution than using an adhoc ticket as described currently in VIPR.

> 
>> From what I can gather about your proposal, I suspect you underestimate the
>> complexity of acting as a CA, enrolling peers in the CA and enabling them
>> to use those credentials properly 

I do not underestimate anything.  On the other hand the CAs certainly
overestimate the value of their services, especially on the light of the recent
problems some of them experienced.  Running a CA is not difficult, and the best
proof is that RELOAD (draft-ietf-p2psip-base section 10.3) requires running it's
own CA in a way that is similar to what I propose.

>> - what it means for two entities that
>> have no pre-existing relationship to suddenly treat each other as trust
>> anchors. I furthermore suspect that TLS operations would not be optimal in
>> this sort of model. Is the antispam property something that is best bound
>> to the transport or to a single SIP request? The use cases, ultimately,
>> answer that for us: consider two large ViPR domains that want to exchange
>> traffic - should they have to establish a new TLS connection for each
>> called number, or should they be able to send signaling for many calls over
>> a single TLS connection? Are there cases where the hop-by-hop property of
>> TLS weakens the utility of the mechanism? Are there environments we want
>> ViPR to be useful where TLS is not available?

Here you are not talking about my proposal, but about VIPR itself, as it already
requires TLS.  That's a different problem.

> 
> Jon Peterson (as an individual) NeuStar, Inc.
> 
> First of all, let's define exactly what SIP, without even talking about VIPR,
> is doing regarding TLS.  The best place for this is RFC 5922.  We can skip
> the client behavior discussion (section 7.3) because neither VIPR or my
> proposal suggest any modification to this procedure.  Here's what RFC 5922
> says about the server behavior (aka client certificate):
> 
> "  When a server accepts a TLS connection, the server presents its own X.509
> certificate to the client.  Servers that wish to authenticate the client will
> ask the client for a certificate.  If the client possesses a certificate,
> that certificate is presented to the server. If the client does not present a
> certificate, the client MUST NOT be considered authenticated.
> 
> [...]
> 
> When authenticating the client, the server MUST obtain the set of SIP domain
> identities from the client certificate as described in Section 7.1.  Because
> the server accepted the TLS connection passively, unlike a client, the server
> does not possess an AUS for comparison.  Nonetheless, server policies can use
> the set of SIP domain identities gathered from the certificate in Section 7.1
> to make authorization decisions.
> 
> For example, a very open policy could be to accept an X.509 certificate and
> validate the certificate using the procedures in RFC 5280 [6].  If the
> certificate is valid, the identity set is logged.
> 
> Alternatively, the server could have a list of all SIP domains the server is
> allowed to accept connections from; when a client presents its certificate,
> for each identity in the client certificate, the server searches for the
> identity in the list of acceptable domains to decide whether or not to accept
> the connection.  Other policies that make finer distinctions are possible."
> 
> In other words, the SIP server (or proxy) does whatever it thinks is
> necessary with the client certificate, and it does not seems that even
> following RFC 5280 is required (note in particular that nowhere it is said
> that the validation must use a public trust anchor).
> 
> -sip-antispam says about TLS and the ticket:
> 
> "  The Border Element will receive the TLS ClientHello which begins the TLS
> handshake.  The Border Element will present its own configured cert.  Once
> TLS handshaking is complete, the Border Element notes the domain from the
> SubjectAltName on the other side of the TLS connection, and associates it
> with that connection.
> 
> Next, the Border Element will receive an INVITE.  This INVITE will contain a
> ticket in the ViPR-Ticket header field value.  The Border Element extracts
> this header field.  This call flow assumes it is present.  The Border Element
> parses it, and obtains the epoch value encoded in the ticket.  This is
> matched against the current epoch value for the configured password.  If they
> match, processing continues.  The Border Element verifies the signature is
> correct. Next, it examines the start and stop time of the validity.  If the 
> current time is between the start and stop times, the check is passed.  Next,
> the Border Element checks the granted-to domain in the ticket.  It compares
> that domain against the domain name in the SubjectAltName of the peer on the
> other side of the TLS connection, as noted above.  Next, it takes the
> Request-URI of the SIP INVITE. That will be of the form sip:+number@domain.
> If it is not in that form, and if the number does not begin with a plus, the
> request is dropped.  The value, including the plus, is then compared to the 
> number in the ticket.  If it is equal, the check has passed.  The Border
> Element leaves the header field in the request, but forwards to the Call
> Agent."
> 
> domain in the ticket must be equal to the domain in the SubjectAltName of
> the client certificate.  Here too, not a word about a public trust anchor.
> 
> Now back to my proposal.  The first thing is that the client certificate must
> be validated using the CA of the VIPR server as trust anchor, which is
> already what a SIP server could do.  It validates according to the rules in
> RFC 5280, which is equivalent to verifying the signature of the ticket and
> the start/stop validity.  The SubjectAltName in the client certificate (which
> is not even required to be used in standard SIP) can be checked against the
> domain part of the From header of the INVITE.  The phone number and the
> granting-domain (which not even verified in VIPR) can be stored as an URI in
> the Issuer Alternative Name extension in the client certificate and be
> validated against the Request-URI of the INVITE.  The granting node can be
> also be stored as a reload URI in an Issuer Alternative Name extension.
> 
> So in conclusion, my proposal does not change what a normal SIP stack is
> doing, because the specification does not say what a SIP stack should do with
> a client certificate.
> 
> (Note that to -sip-antispam should also be added some text saying that RFC
> 5923 must be used, because there is no way to create an additional TLS
> connection in the other direction for a subsequent SIP transaction).
> 
>>>> In the current specification, the PVP server builds and signs a VIPR
>>>> ticket, and send it back to the PVP client, that passes it to the Call
>>>> Agent/ Border Element (CA/BE).  The CA/BE will insert this ticket in
>>>> the next SIP INVITE to the remote CA/BE, which will check the validity
>>>> of the ticket and the domain of the TLS client.
>>>> 
>>>> - The verification of the ticket use HMAC-SHA1, and so the same
>>>> password has to be provisioned in both the CA/BE(s) (to verify the
>>>> ticket) and the VIPR server(s) (to generate the ticket). - The ticket
>>>> can be used without TLS (we all know that implementers think of MUST as
>>>> SHOULD and SHOULD as MAY).
>>>> 
>>>> I would like to propose an alternative that is simpler to implement
>>>> and, I think, more secure than the ticket.
>>>> 
>>>> Instead of using a symmetrical key, the local VIPR server generates an
>>>> RSA key pair, with the public key distributed to the CA/BE(s).  After a
>>>> successful PVP connection, the remote PVP client sends a PKCS#10
>>>> certificate request, containing the domain name and signed with a
>>>> private key[1].  The local PVP server generates a new certificate[2],
>>>> sign it with its private key and send it back to the remote PVP client,
>>>> which pass it back to the remote CA/BE.
>>>> 
>>>> The remote CA/BE will use the certificate received to establish the
>>>> TLS connection for the SIP transactions to the local CA/BE, which will
>>>> use a standard CA based certificate for its domain.  The local CA/BE
>>>> will be able to verify with the VIPR public key that it issued the
>>>> certificate, then will validate the standard parts of the certificate
>>>> (expiration date and so on).
>>>> 
>>>> - The private key is stored only in the VIPR server, or better in a
>>>> physical token. - VIPR does not work without TLS for the SIP
>>>> connection. - There is plenty of commercial or free TLS and X.509
>>>> implementations that have years of experience and testing, which is not
>>>> the case for the ticket proposal. - Security agility is provided by
>>>> TLS. - No additional SIP Header. - Because the ticket verification
>>>> process is folded into the client certificate verification, there is
>>>> less resources needed.
>>>> 
>>>> 
>>>> [1] This is the private key of the CA/BE, so the CA/BE needs to upload
>>>> the PKCS#10 file in the VIPR server.  Depending on the architecture
>>>> used, each CA/BE can use a different PKCS#10 or the same, which means
>>>> that the PVP server must be able to process more than one PKCS#10 and
>>>> send back more than one certificate on one PVP connection.
>>>> 
>>>> [2] The certificate sent back can directly contain the SIP routes,
>>>> increasing the overall security.  One possible mapping from the
>>>> ValExchange response to the certificate could be:
>>>> 
>>>> - Unique ID: serialNumber - Epoch: issuer - salt: N/A - integrity:
>>>> signature - Validity: validity - Phone Number: subjectAltName
>>>> uniformResourceIdentifier tel:+14085551234 - Node-ID: subjectAltName
>>>> uniformResourceIdentifier 
>>>> reload://0110123456789ABCDEF0123456789ABCDEF/ - Granted domain:
>>>> subjectAltName dNSName example.com - Granting domain: implicit in
>>>> routes - Route(s): subjectAltName uniformResourceIdentifier 

- -- 
Marc Petit-Huguenin

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Oct 2011 15:55:35 -0400

This was the only problem you brought up during the call. I would say however that if you're running a CA, then you need to share a great deal more than a symmetrical key to validate signed messages. Unless the thing that issued the cert is colocated with the box that acts as a TLS server, you're not going to be able to avoid some communication between those boxes.

As I said on the call, there are a number of ways to address that need for communication among distributed components that do not involve replicating secrets, and those are part of the design space for addressing implementations that want to distribute these components.

- - No security agility.

I assume you mean algorithm agility. TLS does have a great deal of latitude here, it's true, including the ability to set a null cipher suite. You're going to end up having to narrowly profile TLS for the application if you want to achieve any measure of interoperability or security. SIP, for example, is pretty specific about what algorithms you use with TLS. If you want to change the recommended algorithm, you will still be iterating your specifications and rolling out new versions.

I'm dubious that any off-the-shelf CA library will enable you to put attributes like granted-by and so on into certificates without putting any significant burden on implementers, let alone parsing and verifying those attributes as a step in validating a TLS connection.

RFC3261 still naively assumed a SIP trapezoid. ViPR does as well, but much less naively. The notice given in here in RFC5922 is about cases where an intermediary domain prevents the establishment of a direct TLS connection. If we have an intrusive intermediary in ViPR, then yes, you'll have a failure establishing reference integrity. However, I'd say that the whole, entire point of doing ViPR, of using RELOAD as a foundation, was to establish direct connections between ViPR domains without relying on any intermediary infrastructure. ViPR is by design a dis-intermediation mechanism. (This is in danger of being the intermediary discussion again - hopefully this isn't one of the "hooks" that we're fishing for.)

Anyway, 5922 is speaking to a subset of SIP TLS behavior - behavior, incidentally, that has been controversial in all of the protocols that rely on TLS, like virtual hosting cases and proxying cases. We should be using that as a departure point to argue that reference integrity isn't a desirable or necessary property, especially not in ViPR. That is not the intention behind RFC5922.

ViPR
the basis of capturing a ticket with a granted-to of example.com<http://example.com>, you cannot
impersonate example.com<http://example.com> unless you also control a cert issued for that domain

Again, I think this would need to be far more thoroughly specified for us to be able to evaluate the idea. I gather you mean that you could just put the signature generated by the cert into the ticket's header field value. That is a much less radical proposal than doing this at the transport layer. We'd then need to evaluate, again, how those certs get created, installed and validated, and whether or not this truly solves your problem with distributed components - or if indeed there are other ways entirely to approach the distributed components problem that changing the way the ticket is secured, and which ways would require the least work.

I rather think the recent CA problems are an illustration of how easy it is to do things wrong. I look forward to reading your CPS.

Honestly, this would be a lot easier to swallow if you proposed just to generate a public/private key pair without all the X.509 baggage. I really don't see how a certificate adds any value, except in so far TLS requires them, but if you're willing to move this to a header field, X.509 would be the first thing I'd drop.

If ViPR Domain A nails up a TLS connection to ViPR Domain B, in the original ViPR plan as I understand it, the (public) cert presented by A in TLS is compared to the granted-to of tickets by B when A sends requests over that connection. A could send thousands of different requests, from thousands of different callers, to thousands of different destinations, over the same TLS channel, because the channel is bound to the domain and not to any specific ticket. Unless I totally misunderstand your proposal, you are changing that, right? You want to instantiate the antispam function at the establishment of a TLS connection. The issue is that in SIP, call signaling isn't necessary bound to the establishment of an underlying transport.

Agreed, however, that ViPR does basically require TLS today, so if TLS isn't available, those parts of the spec as written today would't work, so that isn't a problem with your proposal as such - though perhaps your (original) proposal would make adjusting the spec to fix that impossible.

[...]

subjectAltName dNSName example.com<http://example.com> - Granting domain: implicit in

_______________________________________________
VIPR mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vipr

- --
Marc Petit-Huguenin

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Oct 2011 17:23:17 -0500

On 10/13/11 12:25 PM, Peterson, Jon wrote:

> I furthermore suspect
> that TLS operations would not be optimal in this sort of model. Is
> the antispam property something that is best bound to the transport
> or to a single SIP request? The use cases, ultimately, answer that
> for us: consider two large ViPR domains that want to exchange traffic
> - should they have to establish a new TLS connection for each called
> number, or should they be able to send signaling for many calls over
> a single TLS connection? Are there cases where the hop-by-hop
> property of TLS weakens the utility of the mechanism? Are there
> environments we want ViPR to be useful where TLS is not available?

Perhaps the ViPR domain intermediaries shouldn't be cryptographically 
involved in TLS at all.

See: http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01

--
Dean