Hi Vijay, Regarding loop avoidance, please use RFC 2119, capitalized should's.
Regarding identity protection, I now realize I don't understand the relevant
paragraph. The text is:
Redirecting based on the unauthenticated identities might leak out
information about the user when active attacker can get information
to which gateway user was redirected to. If redirection is based on
some internal information of the user, it might leak information to
attacker about the user which might not available otherwise. To
protect against this kind of attack the redirection based on the ID
should happen only after client has also authenticated himself.
If the information leak you are worried about is simply the name/address of
the redirected-to gateway, then this is available to a passive attacker as
well, by simply observing the client's next message. Or were you thinking
specifically of an attacker sitting next to the gateway?
Also note that the last sentence contradicts our choice to allow redirects
at the first IKE_AUTH response (for EAP).
Thanks,
Yaron
> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email protected]]
> Sent: Saturday, May 16, 2009 0:31
> To: Yaron Sheffer; [email protected]
> Subject: Re: [IPsec] Redirect -09 comments
>
> Hi Yaron,
>
> On 5/13/09 10:01 PM, "Yaron Sheffer" wrote:
>
> > Hi,
> >
> > While preparing to progress the draft to AD review, I reread it once
> again.
> > Here are a few comments. Although not all are nits, none of them should
> block
> > the document now.
> >
> > Thanks,
> > Yaron
> >
> > Not-quite-nits:
> >
> > General: a long way back we discussed loop avoidance, but this never
> made its
> > way into the draft. The document implicitly allows multiple redirections
> in
> > sequence. We should specify somewhere that the client MUST have a
> threshold
> > value X (possibly 1), where it is willing to redirect at most X times in
> > sequence. This is meant to deal with faulty configuration, not with
> active
> > attacks.
>
> I added the following text to the Security Considerations section.
>
> The client could end up getting redirected multiple times in a
> sequence, either because of wrong configuration or a DoS attack. The
> client could even end up in a loop with two or more gateways
> redirecting the client to each other. This could deny service to the
> client. To prevent this, the client should be configured not to
> accept more a certain number of redirects within a short time
> period. This should be configurable on the client.
>
> Freel free to modify the text.
>
> > 9. I believe the last sentence "To protect against this kind of attack
> the
> > redirection based on the ID should happen only after client has also
> > authenticated himself." should read "after the *gateway* has also
> > authenticated itself".
>
> Hmm.. This is about revealing information about the user. So I don't see
> how
> this can be avoided if the gateway is authenticating itself.
>
> > 10. Please add at the end of the section: A specification that extends
> this
> > registry MUST also define in which notification(s) the new values are
> allowed.
> >
> > Nits:
> >
> > 1. "connect to the IP address of the VPN gateways", change "gateways" to
> > "gateway".
> >
> > 3. "In practice, this means the new gateway either", remove one
> "either".
> >
> > 6. mesage -> message
> >
> > 6. "presented by the client in the first IKE_AUTH exchange itself." -
> this
> > text is duplicated.
>
> Fixed all of the above. Thanks.
>
> Vijay
>
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
