Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

[Yaron Sheffer <[e-mail]>]

Hi Raj,

No, RFC 5685 tried for generality without defining the usage scenario in 
advance, and this attempt failed. The solution cannot be used 
gateway-gateway, because it depends on the (arbitrary) 
initiator/responder distinction.

Thanks,
	Yaron

On 30.3.2010 15:43, Raj Singh wrote:
> Hi Yaron,
>
> You are saying the same things what i am saying, then i am not able to
> understand how its counter example?
> The point i want to make here,
> "We can emphasize the main use case scenario the draft, but protocol
> should have a space for generality".
> According to me RFC - 5685 is good example of the above.
>
> Best regards,
> Raj
>
>
> On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Raj,
>
>     this in fact is the perfect counter-example: RFC 5685 started out
>     with the client-gateway scenario, and when we woke up to see how it
>     can be generalized to the symmetric gateway-gateway case, it was too
>     late. Hence Sec. 10, which says that the resulting protocol is a
>     very partial solution for this case.
>
>     10.  Use of the Redirect Mechanism between IKEv2 Peers
>
>        The redirect mechanism described in this document is mainly intended
>        for use in client-gateway scenarios.  However, the mechanism can also
>        be used between any two IKEv2 peers.  But this protocol is
>        asymmetric, meaning that only the original responder can redirect the
>        original initiator to another server.
>
>     I'm not saying that we were right in ignoring this case. I'm saying
>     that you can only get the protocol that you want if you define the
>     requirements clearly up front.
>
>     Thanks,
>             Yaron
>
>
>     On 29.3.2010 16:58, Raj Singh wrote:
>
>         Hi Team,
>
>         The similar scenarios are beautifully handled by Redirect RFC-5685.
>         The Redirect RFC emphasize on client-gateway terminology, which is
>         typical use of Redirect mechanism in IKEv2 where Gateway redirects
>         client to another less loaded gateway but at the same time RFC
>         is also
>         applicable to router-router scenario when one router decides to
>         off-load
>         all existing IKEv2 sessions to another gateway when it goes down for
>         maintenance etc.
>         I totally agree with Paul.
>
>         Best regards,
>         Raj
>
>         On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman
>         <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>         wrote:
>
>         <wg-co-chair-hat on>
>
>             The disagreement between Dan and Yaron is over wording in the
>             not-at-all normative criteria draft. This draft is not
>         intended to
>             become an RFC, and is not binding on the WG. It currently is
>         being
>             edited by Yaron; soon it will be edited by both Yaron and Dan.
>
>              From the active thread the past few days, it seems that Dan
>             disagrees with Yaron's view that people thinking about the PAKE
>             primarily as a gateway-to-gateway solution. That's fine:
>         others in
>             the WG might take one view or the other. I ask that Dan and
>         Yaron
>             produce an -03 with both views in it. I note that the current WG
>             charter does not insist that the PAKE we choose be for
>             gateway-to-gateway, but that it does list "authentication
>         between
>             two servers or routers" as a motivating scenario, and does
>         not list
>             remote access as a motivating scenario for the proposed new
>         work.
>
>             As WG members consider which criteria are important to them,
>         they
>             should also consider what scenarios we want to emphasize in the
>             eventual document. I use the word "emphasize" here because
>         we cannot
>             prevent implementers and administrators from using the new
>             authentication mechanism however they want; we have plenty of
>             experience with IKE and IPsec documents saying "you should
>         use this
>             in that way" that are merrily ignored by large parts of the
>         market.
>
>             --Paul Hoffman, Director
>             --VPN Consortium
>             _______________________________________________
>             IPsec mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>
>         https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
>         _______________________________________________
>         IPsec mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/ipsec
>
>