Subject: [Ipsec] Re: [Pki4ipsec] HASH and URL

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Sep 2004 15:36:10 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "suren" == suren  <[email-masked]> writes:
    suren> Hi, As I understand, the IKE node can send Hash of public key
    suren> of its certificate and URL (including port number) from which
    suren> the peer can retrieve its certificate. I guess, it is to
    suren> ensure that there is no fragmentation on IKE packets as some
    suren> routers might not honor fragmentation.

    suren>    I see that there would be firewall related issues in
    suren> this. Since, the IKE needs to make a new connection (HTTP
    suren> connection) to the URI given in Cert payload, any firewalls
    suren> in between should have a policy (ACL) to allow this HTTP
    suren> connection.

  Worse, given NAT/firewall, you can't tell the peer to "get it from 
http://me:1234/mycert.pem"
 
  It would be best if we had an option in the CERT REQ which told the
peer to please do an HTTP POST to some URL. 
  A responder would then be in a position to know if it can provide for
this service or not.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 2 Sep 2004 15:10:32 +0300

> http://me:1234/mycert.pem"

But you can normally say "get it from my home-www server
http://www.my-home.net/username/mycert.cer". For VPN style usage,
that is quite right, and you quite often assume that http over port 80
will work through the firewalls/nat, especially when there is nothing
special going on (meaning proxies etc can work properly with the url). 

>   A responder would then be in a position to know if it can provide for

That would work for the one way, but would not work for the other way
around. I.e. if the initiator is behind NAT, and claims that the
servers certificate should be posted to url http://10.0.0.22:1234/, it
would not really work...

So we would need keep the normal get also, and I think we can most
likely organize things so that there will be some place you can
connect to get the certificate, and if not, then send it inband...
-- 
[email-masked]

---

From: [email-masked]
Date: Thu, 2 Sep 2004 07:33:56 +0530 (IST)

Note: please reply to [email-masked]

It is not good to assume that all firewalls/NATs are of Cone type.
   They could be symmetric type too. Alternate method I can think of :

            Node A                                        Node B
                                             <-------------Cert Request
            Certificate---------->

           As part of certificate, it can indicate that, the Node B needs
           to make a connection on fixed port (assigned number from IANA)
           running HTTP Server.

   Node B makes the connection to Node A to get the certificate. If Node A
has the certificate, it returns the certificate. Otherwise, it itself
can make a connection to certificate store, get the certificate and
send it on the connection Node B made with it.

         Since Node A can listen on well known fixed port, Firewall
administrators at Node B can allow only that service.

Regards,
-Ravi
ROCSYS Technologies Ltd
http://www.rocsys.com

> Hi,
>    As I understand, the IKE node can send Hash of public key of
>    its certificate and URL (including port number) from which the peer
> can retrieve its certificate. I guess, it is to ensure that there is
> no fragmentation on IKE packets as some routers might not honor
> fragmentation.
>
>    I see that there would be firewall related issues in this.
>    Since, the IKE needs to make a new connection (HTTP connection) to
> the URI given in Cert payload, any firewalls in between should have
> a policy (ACL) to allow this HTTP connection.
>
>    This could be a deployment problem. The administrator of firewall
> need to create a ACL to allow all connections outbound.
>    This is one of the problem being faced by administrators on CRLDP
>   (CRL Distribution point) too. At least in this case, the distribution
>    points are smaller and in most cases deterministic and the
>    administrator of firewalls can create appropriate policies
>    statically.
>
>    What do you think of this following proposal.
>    - IKE Peer which receives Certificate payload always sends its
>      IP address and port as part of URL.  (Assumption here is that,  all
> services typically are allowed between IPSec Peers).
>    - When the IKE node receives HTTP request, it could send HTTP
>      Redirect to new URL, which could be outside its node.
>    - IKE Peer is expected to use same source IP address and Port
>      (May be using REUSE address option in sockets) to connect to  new
> HTTP Server and Port.
>    - Since, most of firewalls support 'address binding' feature,
>      it should work.
>
> Does this make sense? Comments?
>
> Thanks
> Suren
> www.intoto.com
>
> pki4ipsec mailing list
> [email-masked]
> http://honor.icsalabs.com/mailman/listinfo/pki4ipsec