[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on IKEv2
On 7 Dec 01, at 0:44, Dan Harkins wrote:
> Valery, zdrastii!
Dan, privet!
> On Fri, 07 Dec 2001 11:05:05 +0300 you wrote
> >
> > on what criteria could responder base his decision to narrow TS?
> > Assume the following situation: initiator offers wildcard TSS, while
> > responder's SPD consists of several adjacent ranges. The very natural
> > decision for him is to select and sent back to initiator one of these
> > ranges. But which? He doesn't have enough information because
> > initiator has no ability to tell him what exact packet she is trying
> > to make SA for. If this information were provided by initiator (via
> > special payload or by requiring the first TSS in TS to always
> > represent the actual IP packet triggered this negotiation), this
> > would increase robustness of the protocol.
>
> The Responder could send back all of them. If the packet that
But what if responder's policy dictates to protect each of these
ranges with a separate SA (say, for the purpose of following
authorization)? In this case responder needs to send back only one
range, but which?
> triggered the Initiator's negotiation was not included in what the
> Responder sent back then those packets would not be sent after
> negotiation for the subset succeeded (I'd imagine that if the
> Initiator is a gateway it would send back some "administratively
> prohibited by filter" message back to the source). But that is what
> happens when the Responder does not allow the Initiator to access
> what she (the Initiator) wants to access. No way around that.
I agree. But with current protocol design the situation when
negotiation is not succeeded will be happen erroneously sometimes
(e.g. when in fact it might succeed).
> Requiring the first TSS in the TS to always represent the actual
> IP packet triggering the negotiation is an interesting idea but it
> wouldn't solve the problem you described-- the packet matched a
> wildcard selector. Or are you suggesting that no negotiation should
Why not? It will. Responder will take the very first TSS and match it
upon her SPD. If no suitable selector is found (or if selector found
dictates to discard packet), responder will return "invalid id
information" (or "no proposal chosen", anything you like) - and in
this case negotiation won't succeed. But, if he found suitable
selector, he then will need to check whether this selector is a
subset of the other TSSs from initiator's proposal. If it is, it will
return it, if not, it will return back initial initiator's set of
TSSs.
In any case, either they will have an SA that is equal to or
"narrower" than initiator's initial proposal, or no SA will be made.
Note, that the latter will take place only if responder's policy does
prohibit such a traffic, but not due to the protocol deficiencies.
Note also, that I presume that responder may not only remove some TSS
from initiator's set (as explicitly said in the draft), but also to
modify them, provided resulting set of TSS is equal or "narrower"
than original. For example, he can replace wildcard TSS with range
TSS, or one range TSS with another (if the latter is completely
included in the former). Am I right?
> succeed? That is, the Responder says "no proposal chosen" instead
> of sending back a TS subset?
>
> > And one more comment. The peers seem to have no ability to inform
> > each other about what kind of signature (RSA or DSA) they will use.
> > Why so? This will require all implementation to support both (or even
> > more if ECDSA come later) to be interoperable. Wouldn't it be better
> > to negotiate this, as well as cipher, hash and group?
>
> Can't you infer what signature the peer supports? If you are
> using a pre-shared public key you know directly. If you are enrolled
> in a CA you should know what types of certs it will issue, no? If
> it issues certs for both RSA and DSA public keys then you have to
> support them both.If it issue certs for just one then you just have
> to support that one. I would imagine that people want to make their
Nothing can stop any particular CA to start issuing certificates with
new type of key sometime. So, in general you don't know what types of
key CA supports, even if you know what he is supporting now. And that
makes me nervous - that is one more place that can lead to
incompatibility (artificial, I think). I'd prefer types of signature
to be negotiated, moreover the protocol has everything ready for
this.
> product as versatile as possible, though, and support them both
That effectively forces an implementation to support every type of
signature, including ECDSA, ElGamal, GOST and so on, that may be
inappropriate for resource-limited devices...
> regardless of whether a magic number is used to indicate up-front
> which signature will be used.
>
> Dan.
Vsego horoshego (best regards),
Smyslov Valery.
References: