[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: matching GW addr to ID payload (fwd)
On Thu, 2 Dec 1999, Bronislav Kavsan wrote:
> Ooops - you are right - can't select the key based on ID Payload. But can verify that the
> policy entry selected based on source-ip-address is the same as pointed out by ID Payload.
>
Yes, but again, what's the point? If you pick the policy based on ID after
making sure the ID is the same as the source-ip-address, you've effectively
picked the policy based on the source-ip-address. The ID didn't really enter
into the picture.
If you have ID_FQDN, you couldn't do this check at all, and you would again
only pick the policy based on the source-ip-address, since that's the only
authenticated piece of information you have.
So in either case, the ID payload is irrelevant. While checking it when you
CAN is not illegal per the rfc, it's also quite useless, and makes your
implementation NOT work through NAT.
jan
> Bronislav Kavsan wrote:
>
> > Jan Vilhuber wrote:
> >
> > > Huh? If using MM with pre-shared keys, you can't use the ID payload to select
> > > the key.
> >
> > Why not if I am a responder? How it is different from using source-ip-adress to select the
> > key?
> >
> > > (I seem to recall you
> > > saying it's a one-liner).
> >
> > Yeah.....it takes one line of code, but requires whole new Release and upgrading thousands
> > of installations...
> >
> > > Whether or not we rewrite the rfc to exclude the ID from MM/pre-shared is
> > > irrelevant in that case.
> > >
> > > Bottom-line: ID payload in MM/pre-shared doesn't give you any usefull
> > > information and can not be checked for validity. So actually checking it is
> > > counter-productive.
> > >
> > > Unless someone can point out a fallacy in my thinking.
> > >
> > > Here's another approach: If we agree that it's valid to send ID_FQDN in
> > > MM/pre-shared, and you don't check this, then what do you gain by checking
> > > the ID payload when it's ID_IPV4?
> > >
> > > jan
> > >
> > > > Jan Vilhuber wrote:
> > > >
> > > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote:
> > > > > > Jan,
> > > > > >
> > > > > > You said "How would you know that I was NOT 'kivinen@iki.fi'?"
> > > > > > That's true - but the similar question could be asked: "How would you know
> > > > > > that my IP Address is NOT 204.12.57.121"?
> > > > > >
> > > > > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big
> > > > > difference. One selects the key, and one does not.
> > > > >
> > > > > > Both schemes have exactly the same level of insecurity (though changing IP
> > > > > > Address on my machine is much easier than changing the content of the ID
> > > > > > Payload :).
> > > > > >
> > > > > No, they don't, but I may be missing something: If you change your
> > > > > ip-address (barring NAT) I would pick a key based on the source-ip-address.
> > > > > So this does have implications.
> > > > >
> > > > > If you change the ID, nothing changes, except the string of bits that goes
> > > > > into the hash. There's a difference.
> > > > >
> > > > > > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload
> > > > > > and get through the NAT and do not make the special case for not checking
> > > > > > ID Payload when using pre-shared key in MM.
> > > > > >
> > > > > What does checking the ID payload give you? I can't CHECK that you are
> > > > > 'cisco-gateway.com'. And I personally don't care if your ID payload claims
> > > > > you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor
> > > > > are they particularly reliable, since you could be lying about them, and I
> > > > > have no way of knowing. So I ignore them, and pick the key based on
> > > > > source-ip-address (the only thing I CAN).
> > > > >
> > > > > > Another option in the new draft could be to remove ID Payload altogether
> > > > > > for MMs with pre-shared keys.
> > > > > >
> > > > > Either way, I don't get your points above. The problem is solved if you
> > > > > simply ignore the ID payload in this situation. Pay no attention to it. I
> > > > > carries no relevant information.
> > > > >
> > > > > jan
> > > > >
> > > > > > Jan Vilhuber wrote:
> > > > > >
> > > > > > > On Fri, 3 Dec 1999, Tero Kivinen wrote:
> > > > > > > > Jan Vilhuber writes:
> > > > > > > > > I would argue that it doesn't and that you can safely ignore the ID payload
> > > > > > > > > in the MM/pre-shared scenario, since it adds no value anyway.
> > > > > > > >
> > > > > > > > For pre shared keys it doesn't offer anything. You have to know the
> > > > > > > > identity before ID payload anyways, because you need to select the
> > > > > > > > correct pre shared key before you can decrypt the ID payload. You can
> > > > > > > > use ID payload as a key to select correct policy for the quick mode,
> > > > > > > > but I don't think there is any use to require it to match the IP
> > > > > > > > address of the policy. This only applies for the pre shared keys.
> > > > > > >
> > > > > > > But if you don't 'authenticate' the ID payload in any way, I would think it's
> > > > > > > insecure to select policy with it. Since PC-clients (or at least the one I'm
> > > > > > > familiar with) generally have the ID field as a configuration option, I could
> > > > > > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy?
> > > > > > > How would you know that I was NOT 'kivinen@iki.fi'?
> > > > > > >
> > > > > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and
> > > > > > > should be ignored and not used for anything at all.
> > > > > > >
> > > > > > > Aggressive mode is different, since I have the option of picking the shared
> > > > > > > secret based on the ID, so I can use it for policy selection (or whatever).
> > > > > > >
> > > > > > > jan
> > > > > > > --
> > > > > > > Jan Vilhuber vilhuber@cisco.com
> > > > > > > Cisco Systems, San Jose (408) 527-0847
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Jan Vilhuber vilhuber@cisco.com
> > > > > Cisco Systems, San Jose (408) 527-0847
> > > >
> > > >
> > > >
> > >
> > > --
> > > Jan Vilhuber vilhuber@cisco.com
> > > Cisco Systems, San Jose (408) 527-0847
>
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
References: