Hi Andreas, All,

To be honest, the idea came just yesterday to me. That's why I haven't
given it that much thought myself, so it's not necessarily a good (or
even appropriate) solution. I'm still thinking if it wouldn't break
something important...

If I understand you correctly about the IP addresses, this would be
such a prevention against breaking. So, if we have a request coming
from

server-1.opentox.net

which requests a policy to be created for

http://service-A.opentox.org/resource-B

based on comparing the DNS names only, we would refuse it. However, if
we check the IP addresses "behind" "server-1.opentox.net" and
"service-A.opentox.org" and if they match, we would actually accept
the policy. That's a very good point.

Still, I'd suggest we bypass the DNS -- probably I shouldn't have even
proposed this at all, but I had already written part of the mail when
I realized that the SSL certificates could do the same -- and much
better -- job. Not only they are inherently secure, but they also
easily solve the problem with different DNS names on one machine --
even if there are multiple addresses behind each, actually, which is
also possible.

In the above example, when we get the request from

server-1.opentox.net (which resolves to, say, 123.4.5.6)

which requests a policy to be created for

http://service-A.opentox.org/resource-B
(where the domain name part resolves to, say, 12.3.4.56)

we would reject the request based on both DNS and IP verification.
However, if the requester has been issued a certificate for the
following domains

server-1.opentox.net
server-2.opentox.net
server-3.opentox.net
service-A.opentox.org
service-B.opentox.org
service-C.opentox.org

and has authenticated itself with this as a client certificate during
the SSL handshake, we would have all the good reasons to accept the
request (because one of the domain names in the certificate matches
the URL in the policy: service-A.opentox.org; where exactly the
request came from is irrelevant in this case -- it could have been
even gates.microsoft.com).

Technically, the said certificate would look something like this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 371 (0x173)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=org, DC=opentox, CN=OpenTox CA
        Validity
            Not Before: Jun 28 12:50:26 2010 GMT
            Not After : Jul 28 12:50:26 2011 GMT
        Subject: DC=org, DC=opentox, O=services, O=OpenTox, OU=IDEA,
CN=service-A.opentox.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:d9:f1:a0:e2:8a:56:ba:64:72:72:3c:73:91:a6:
                    62:ed:7a:00:c7:7d:3e:6b:c5:3c:9a:52:2d:75:f5:
                    2b:fc:c7:d8:03:23:7a:c6:5f:f8:2b:4d:1e:29:df:
                    55:0f:85:43:48:aa:f4:ca:a9:42:2f:f2:77:74:dc:
                    98:c5:49:35:50:3e:fa:b1:a9:72:9b:8f:8a:ff:d5:
                    ba:cf:20:db:35:2a:48:f1:e3:ba:1a:51:2f:df:ea:
                    fc:86:0f:78:78:5c:86:f6:dc:25:53:3c:ae:08:68:
                    46:5a:05:e2:9e:b9:43:f6:4c:ed:04:ee:23:53:05:
                    98:5f:22:5b:6b:35:ac:39:92:60:3b:63:65:b0:a4:
                    1b:a4:f5:df:9a:8d:bf:8f:56:2a:4b:9a:11:ae:38:
                    b3:b3:9e:65:85:fa:f7:55:50:27:c1:2f:d8:d2:30:
                    8b:fd:54:93:59:45:2d:11:0b:a0:0a:95:32:a9:1e:
                    19:6c:e7:40:71:6a:d2:51:bd:c7:fe:10:77:6b:c0:
                    13:69:9c:9e:d5:31:19:00:22:3c:e2:3b:53:ef:45:
                    a8:53:d1:d8:5d:1f:00:95:a4:59:df:08:b8:76:c9:
                    19:d5:c7:c9:25:28:29:dc:8c:32:63:aa:37:8e:f7:
                    1e:34:39:1d:94:b2:d0:9d:83:9f:fd:10:c0:51:81:
                    5b:1f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 CRL Distribution Points:
                URI:http://ca.opentox.org/crl/opentox_ca-crl.der

            X509v3 Authority Key Identifier:

keyid:D1:7D:63:38:C7:69:EC:56:2C:CE:EE:D5:6D:4E:77:C7:A3:FD:34:6C

            X509v3 Subject Key Identifier:
                40:DE:5A:69:25:62:0B:10:22:DC:5B:56:09:F0:12:96:83:1D:63:24
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.26646.1.3.1.1.0

            X509v3 Subject Alternative Name:
                DNS:server-1.opentox.net, DNS:server-2.opentox.net,
DNS:server-3.opentox.net, DNS:service-A.opentox.org,
DNS:service-B.opentox.org, DNS:service-C.opentox.org
    Signature Algorithm: sha1WithRSAEncryption
        80:6b:5a:c7:51:3a:f4:27:2a:17:2a:fc:82:99:48:3e:f8:ef:
        0d:80:99:02:9b:62:24:7b:93:47:ad:68:9b:3f:3a:af:24:1c:
        bc:11:16:1e:36:31:11:69:09:b2:02:82:ac:79:a4:c2:25:96:
        3d:64:77:02:1f:5c:1b:5f:21:ee:d5:88:7b:08:f7:6a:be:7e:
        ba:1c:e2:a3:01:7f:09:2d:34:6e:b1:39:cc:2b:21:8f:0f:53:
        af:54:44:cd:68:57:24:4b:21:da:95:e9:dc:47:90:2a:1b:f5:
        6c:5f:84:e4:e8:05:8e:01:46:88:c9:4a:b0:4e:b9:29:23:67:
        3e:af:b7:22:40:88:6a:d1:9b:47:40:ff:d4:2c:5c:c7:61:d7:
        5d:ef:db:90:f5:c3:33:16:be:a0:1b:8a:3f:42:df:6e:ae:49:
        31:71:16:1c:2a:93:62:64:7c:15:37:ff:37:3f:d5:53:17:26:
        01:d7:eb:70:3d:f0:0d:f2:86:82:1f:48:89:50:84:90:99:7f:
        89:08:89:e2:f4:8c:e1:f8:fd:a7:59:2d:80:59:64:1b:08:2a:
        0a:dd:ef:77:3b:c8:d3:e7:0d:c7:a6:0d:bd:5c:f4:1a:05:8f:
        dc:f5:1d:e5:49:b7:6c:a0:de:f5:ab:59:4b:87:dc:31:98:f8:

The certificate signature would be checked already at handshake time,
so all that is necessary, is to compare the DNS name of the URL in the
requested policy to the list of Subject Alternative Names -- and if
one of the entries matches, the request is accepted.

Actually, wildcards in domain names are also accepted, so that entry
could have been even simpler:

            X509v3 Subject Alternative Name:
                DNS:*.opentox.net, DNS:*.opentox.org

Mind you, when a Subject Alternative Name (SAN) is present in the
certificate, the CN field in the DN is not checked at all -- so,
really all checks should be against the SAN list.

So, to summarize, the question is: how easy for the policy service
would it be to check the SAN entries in the client certificate used in
the SSL/TLS connection against the URL for which a policy is submitted
through that secure channel?

If that works, then probably we could set up a temporary certification
authority for testing (I could do that) and see how it really works in
practice.

Cheers,
Luchesar


On Tue, Jun 29, 2010 at 11:02, Andreas Maunz <andreas at maunz.de> wrote:
> Ok, we can restrict creation to policies relevant to the current machine
> only. In that case:
> - we have policy creation only by services or users logged in to the current
> machine.
> - no other machine can create a policy relevant for the current machine
> The two points impair flexibility a lot, thus I did not think this far. Of
> course, Nina is right with the efficiency argument. I had in mind the
> situation where public access was prohibited prior to policy creation, thus
> no data would be transported. But I recognize this was short-sighted, and
> overall, I agree with your proposal to use DNS-verification.
>
> One more (less important) question: We could also only forward DNS
> resolution, couldn't we? Are host names not available with the request? If
> yes, we could resolve both host names of requesting webservice and target
> webservice and check whether the two IP addresses match.
>
> Greetings
> Andreas
>
>
> Luchesar V. ILIEV wrote on 06/28/2010 09:54 PM:
>>
>> On Mon, Jun 28, 2010 at 22:27, Luchesar V. ILIEV
>> <luchesar.iliev at gmail.com>  wrote:
>>>
>>> [...snip...]
>>>
>>> In other words, if the service gets a request for the resource above
>>> from an address, which reverse-resolves to, say, badguy.aol.com, then
>>> the policy service will reject the request straight away.
>>
>> That was ambiguous, sorry. Should have read instead:
>>
>> In other words, if the _policy_ service gets a _policy_creation_
>> request for the resource above from an address that reverse-resolves
>> to, say, badguy.aol.com, then the policy service will reject the
>> request straight away (because badguy.aol.com !=
>> serviceA.opentox.org).
>>
>> L.
>>
>> P.S. And, in the case of SSL/TLS, it would read:
>>
>> In other words, if the _policy_ service gets a _policy_creation_
>> request for the resource above via a secure connection where the
>> client certificate has been issued to badguy.aol.com, then the policy
>> service will reject the request straight away (because badguy.aol.com
>> != serviceA.opentox.org).
>>
>> Of course, if the bad guy doesn't present valid certificate in the
>> first place (that is, issued by a trusted certification authority),
>> then no connection would happen at all.
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>