Re: [VIPR] An alternative to the VIPR ticket

["Peterson, Jon" <[e-mail]>]

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.

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.

- - Code has to be written from scratch for both the generation and the
verification of the ticket.

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.


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.

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
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<http://example.com>, you cannot
impersonate example.com<http://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.

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.



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


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.

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


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.

Jon Peterson (as an individual)
NeuStar, Inc.


Jon Peterson (as an individual) NeuStar, Inc.

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

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:[phone] - Node-ID: subjectAltName
uniformResourceIdentifier
reload://0110123456789ABCDEF0123456789ABCDEF/ - Granted domain:
subjectAltName dNSName example.com<http://example.com> - Granting domain: implicit in
routes - Route(s): subjectAltName uniformResourceIdentifier
sip:[e-mail]:371;maddr=10.1.1.1



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

- --
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6XMLUACgkQ9RoMZyVa61dhCgCghMV7hIJ8Gcc1GZjGEiDflw44
kwkAn3zHPotOdEQRb4VQort1a8aYb/f4
=Slq9
-----END PGP SIGNATURE-----