[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ISAKMP Oakley resolution and ipsec doi document questions


There are two specific scenarios using proxies for 

1. A host wants to initiate a connection to another host,
and a proxy host in the middle handles IPSEC for it
This is the case addressed in your response. Typically,
(but not necessarily), this would be for accessing intranet
over a firewall by an host on the internet.

2. A host (daemon) wants to accept connections from
other hosts and there is a proxy which needs to establish
an authenticated IPSEC connection to the host before it allows
traffic to/from it. 

Here is an example. I have a web server www on the intranet. 
For many pragmatic reasons, I do not want to put this web server
in the DMZ. This web server wants to request the firewall that it 
be allowed to communicate with any external host.
The way firewall can ensure this (and stop other intranet hosts
from using IP address of www to send unauthorized traffic out), is
to establish IPSEC AH or ESP SA between www and 
firewall and use it. The firewall will varify that all the 
packets leaving the site are from www and no one else. Similarly,
all the packets entering the Intranet to www are (for example encrypted)
so that know one can spoof them. (In some ways, this type of 
fuctionality is supported by socks). 

In this example, host www will establish an IPSEC AH or ESP SA.
However, the firewall will not know the identity IDur until 
some external host attempts to connect to www.

Therefore, I would suggest that we do not mandate that IDui and
IDur must be specified at the same time. 
One alternative is to use as ID when you do not
know the ID (since it provides such a limited value why bother
sending it). Therefore, it is my openion that IDur and IDii should
not be tied together (which leads to a question on how 
to differentiate between the two!).


-----Original Message-----
From:	Edward A. Russell [SMTP:erussell@ftp.com]
Sent:	Friday, June 13, 1997 12:34 PM
To:	'baiju@ideal.jf.intel.com'; 'ipsec@tis.com'
Subject:	RE: ISAKMP Oakley resolution and IPSEC DOI document questions

Baiju Patel (baiju@ideal.jf.intel.com) said on 6/13/97 at 8:11 AM
>1. The ISAKMP/OAKLEY document specifies
>  Quick Mode is defined as follows:
>        Initiator                        Responder
>       -----------                      -----------
>        HDR*, HASH(1), SA, Ni
>          [, KE ] [, IDui, IDur ] -->
>                                  <--    HDR*, HASH(2), SA, Nr
>                                               [, KE ] [, IDui, IDur ]
>        HDR*, HASH(3)             -->
>Does this mean that either both IDui and IDur must be specified 
>or none. Or was it authors intention to specify
>        Initiator                        Responder
>       -----------                      -----------
>        HDR*, HASH(1), SA, Ni
>          [, KE ] [, IDui][,IDur ] -->
>                                  <--    HDR*, HASH(2), SA, Nr
>                                               [, KE ] [, IDui][, IDur ]
>        HDR*, HASH(3)             -->
>So that one or both IDui and IDur can be specified. 
>Basically, I am curious on how will the initiator know
>the identity IDur if receiver is a proxy.

I belieive the assumption is you must specify both or neither.
The initiator should know the IDur identity even if the receiver
(isakmp peer) is a proxy because the initiator presumbably knows
who he want to ultimately connect to.  It is up to the initiator to tell the
responder who the ultimate destination (IDur) is going to be and therefor
who this SA is going to be used for.

>2. in the doi document, who's port number is specified in
>the identification payload? (initiator or reviver?)
>The protocol ID and port are also in the field marked
>reserved in the ISAKMP document. Is this intentional?
>In my view, this should be consistent.

The port is 500 for sending
The port is 500 for receiving
The port is 500 ONLY.
I believe this came out of Memphis.

>3. draft-ietf-ipsec-isakmp-oakley-03.txt:
>   The introduction states:
>This draft combines ISAKMP and Oakley. The purpose is to negotiate,
>   and provide authenticated keying material for, security associations
>   in a protected manner.
>Since this document is only applicable (to best of my understanding)
>to peer to peer communication (and not multicast), it may be a good idea to
> specify that clearly.

Edward Russell