Re: [VIPR] An alternative to the VIPR ticket

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
> 
> 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 - Granting domain: implicit in
>>>> routes - Route(s): subjectAltName uniformResourceIdentifier 
>>>> sip:[e-mail]:371;maddr=10.1.1.1
>>>> 
> 
> 
_______________________________________________
VIPR mailing list
[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-----