[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parties ID handling under ISAKMP-OAKLEY
Thank you, Sumit, for the feedback.
At least I got awareness that I do understand
IPsec documents the same way as somebody else ;-)
I should rephrase some of my topics.
1. Although it's clear that IDci and IDcr are to identify
parties, the DOI does not clarify whether the proto
and port fields of _IDci_ (initiator) do
correspond to the initiator or responder values.
If one will send in IDci proto=TCP, port=21 does
it means that the _initiator_ will sent data on
the _responder_ TCP 21 port.
If yes, the DOI should clarify
that case, because _initiator_ ID includes the port
actually associated with the _responder_ service.
If DOI assumes other, I don't see the way how client
can request particular remote service under current DOI.
2. When doing host-to-host negotiations
(on behalf of each ISAKMP peer!), and
if IDs are not present, there is no way to select
the scope for a SA other but all traffic between two
hosts. Right? If yes, the fine-grained IPsec implementation
must always use Quick mode at the full context.
It should be noted in the current version of ISAKMP-OAKLEY.
6. The ID payload type allows select either
party IP_address or key_ID, but not both.
That means with using preloaded shared keys
(where key_id is required for a negotiation)
there is no way for a gateway employ different
local keys for different protected systems
resided behind it. The same can be applied for
multiple local certificates of a gateway, since
documents say that 'Cert' payload (if included in
a SA negotiation) must be the one identified by
the 'ID' payload. It seems impossible to say
for a responder:'I request a SA originated from
that IP address using that long-term keying material'.
---
Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694
Software Architecture&Development Consultant.
---
-----Original Message-----
From: svakil@usr.com <svakil@usr.com>
To: ipsec@tis.com <ipsec@tis.com>; Alexei V. Vopilov <alx@elnet.msk.ru>
Date: 17 äåêàáðÿ 1997 ã. 18:47
Subject: Re: parties ID handling under ISAKMP-OAKLEY
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
:
:
:
: