Re: parties ID handling under ISAKMP-OAKLEY

[svakil@xxxxxxx]

     Alexei,
     Please see my comments below.
     
     Sumit A. Vakil
     3Com, Corp.


______________________________ Reply Separator _________________________________
Subject: parties ID handling under ISAKMP-OAKLEY
Author:  "Alexei V. Vopilov" <alx@elnet.msk.ru> at Internet
Date:    12/16/97 11:43 PM


One of observations on the latest IPsec drafts 
is the handling of the parties ID information 
during a SA phase two negotiation.
I trust that a serious discussion had preceded the 
discussion to put the scope of negotiating SA in 
the ID payload, I mean TCP/UDP protocol, and ports.
However, it is not clear in documents how to negotiated 
a SA, say from an initiator TCP port X to responder TCP 
port Y.
Probably, I missed some point, but ...
     
1. A DOI reserves 'proto' an 'port' for the ID payload, 
but does not say exactly whether these values belong
to initiator (data sender) or responder side.
I guess it should describe the destination point of SA even 
been included in the initiator ID payload.

Sumit>> From section 5.5 of the ISAKMP/Oakley resolution 
draft,
"If ISAKMP is acting as a client negotiator on behalf of 
another party the identities of the parties MUST be passed as 
IDci and then IDcr.... If IDs are not exchanged, the 
negotiation MAY assumed to be done on behalf of each ISAKMP 
peer."

This means that if ISAKMP is doing the phase 2 on behalf of 
another party, the client ids on both sides must be present 
in the message, and the ordering (IDci, IDcr) must be 
maintained.
     
2. The only way to include _both_ IDs in the proposal
as per ISAKMP-OAKLEY is to use Quick Mode with full context. 
If an initiator did not include _both_ IDs in the
proposal, the responder cannot predict the missing part and thus 
respond with own ID, which include other than 0 port information. 
Do you feel the serious security problem due to that?
I do, especially for multi-user IPsec environment running number of 
client applications.

Sumit>> See above.  Both Ids must be supplied.
     
3. Since there can be only one pair of IDs in the proposal, multiple 
SAs cannot be negotiated at the same time or they will be just 
identical by scope, i.e. will protect the same connection streams.

Sumit>> You are correct.  Multiple SAs can be negotiated, but they 
will have the same scope.  The idea behind this is to allow fast 
re-keying.  From section 9 of the resolution draft,

"An implementation may wish to negotiate a range of SAs when 
performing Quick Mode.  By doing this they can speed up the 
"re-keying". Quick Mode defines how KEYMAT is defined for a range of 
SAs.  When one peer feels it is time to change SAs they simply use 
the next one within the stated range. A range of SAs can be 
established by negotiating multiple SAs (identical attributes, 
different SPIs) with one Quick Mode.
     
4. Q: Can I negotiate two ICMP SAs of
different ICMP types which will have different SPIs?
If it can be done using the Id payload 'port' field for the ICMP 
'type' one, that should be stated in the DOI draft.
Sumit>> Not sure.

     
5. Q: There cannot be a 'ports range' negotiated according to
   the current DOI-06, right?
Sumit>> That's how I understand it, too.  However, 0 is supposed to be
a wildcard.
     
6. Q: If an initiator needs to negotiate a SA been stuck to
      specific IP address+key_ID values, how it can be done with 
      current ISAKMP-OAKLEY, DOI drafts.
      Another word, is it possible for a party to provide 
      more than one ID payload for itself?
Sumit>> No, there can be only one Id payload pair in a 
phase 2 exchange.  The Id payloads are used to determine 
the local security policy.  They are also used to identify 
data flows to be protected using a negotiated association.  
The data flow Ids don't necessarily have to be restricted 
to pairs of IP addresses and pairs of TCP ports.  If you 
want to use the same phase 2 association for packets 
between multiple sources, you simply need to re-define the 
Ids in your policy to allow subnets, range of IP addresses, 
etc..  The IP DOI allows the Id to be subnets or ranges of 
IP addresses, with wildcard upper layer protocols and 
ports.  I'm not sure if this answers your question.
     
If I'm completely wrong, just give me the right hint. 
thanx.
---
Alexei V. Vopilov (alx@elnet.msk.ru),  +7(095)5367694 
Software Architecture&Development Consultant.
---
-----Original Message-----
From: Theodore Y. Ts'o <tytso@MIT.EDU> 
To: ipsec@tis.com <ipsec@tis.com>
Date: 5 ÄÅEAAOÑ 1997 Ç. 8:54
Subject: IPSEC document reading party!
     
     
:
:Hi,
:
: Bob and I are very concerned that few people are actually 
:reading all of the IPSEC drafts, and so there may be internal
:inconsistency and other problems across the various drafts, that perhaps 
:won't be discovered until after they are published as RFC's.  That, as 
:they say, would be Bad.
:
: In order to try to avoid this, we are planning an IPSEC document 
:reading party, to be held Monday evening at the IETF meeting.  The 
:logistical details are still be being finalized, but it will probably 
:start at either 6:00 or 7:30.  (If it starts at 6:00, food will be 
:provided.)
:
: We are looking for a people who are willing to put in a couple
:of hours of real work, by reading over the documents, with a particular 
:attention towards finding consistency problems and other problems with 
:the drafts.  Please come only if you are prepared to work!  Also, please 
:bring your own copies of the documents to read.
:
: In the interests of getting work done, we're not looking for 
:quality, not quantity, in terms of the number of people we have 
:participating.  Document editors are especially asked to come so that
:they will be available for questions should they arise from the readers. 
:
: If you are interested in particpating, please RSVP to Bob and I. 
:Information about the location, etc. will be announced later (probably 
:at the IETF meeting itself; check the announcements board.)
:
: If you have any questions, please let either Bob or I know. 
:
: - Ted
:
:
:
:
Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP
  (IMA Internet Exchange 2.02 Enterprise) id 49716C00; Tue, 16 Dec 97 18:03:12
-0600
Received: from portal.ex.tis.com by usr.com (8.8.5/3.1.090690-US Robotics)
	id QAA04219; Tue, 16 Dec 1997 16:37:18 -0600 (CST)
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id
PAA03913 for ipsec-outgoing; Tue, 16 Dec 1997 15:32:35 -0500 (EST)
From: "Alexei V. Vopilov" <alx@elnet.msk.ru>
To: <ipsec@tis.com>
Subject: parties ID handling under ISAKMP-OAKLEY
Date: Tue, 16 Dec 1997 23:43:41 +0300
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id
PAA03910
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by usr.com id QAA04219