Hi Dan,
Again, the criteria document is just following the charter in mentioning
this constraint.
The protocol we end up with might have all sorts of nice-to-have
features and behaviors. But for the criteria, we have to focus on what's
important. Use cases that were excluded in the charter (and for good
reason, because we have a perfectly good solution for them today) do not
fall into this category.
Thanks,
Yaron
On 27.3.2010 22:15, Dan Harkins wrote:
Hi Yaron,
You say below, "If a protocol can be specified for the general use case,
that's very well. But there will be protocols that are only applicable
to some specific use cases, and that's fine, too." But then the criteria
document says, "This document is limited to the use of password-based
authentication to achieve trust between gateways."
So basically the criteria document is specifying it for a particular
use only when there is no protocol issue that would prevent it from being
used in the general case. It should be "very well" if it worked "for the
general use case" but the criteria draft is preventing it from doing so.
In RFC 2409 it was not possible to do the "remote access" thing with a
PSK because protocol limitations forced the PSK to be bound to one IP
address. That's an example of a protocol limiting usage. But I don't see
that now. What could possibly limit what we're talking about _right now_
to some narrow uses? Maybe when we get around to designing the protocol
we'll run into something, and as you say "that's fine". But now, there is
nothing to limit us and no reason to, a priori, say something is for
"gateways" only.
Of course, I could be wrong. So maybe you could explain why there is
some protocol issue that prevents using password-based authentication in
the general case.
Dan.
On Sat, March 27, 2010 7:31 am, Yaron Sheffer wrote:
Hi Dan,
I'm afraid I disagree with you on several counts. See below.
Thanks,
Yaron
On 26.3.2010 20:11, Dan Harkins wrote:
Telling administrators what they can and cannot do is really not
the function of our standards body. If someone wants to use a
"long secret" or a password to authenticate gateways, hosts, clients,
peers, or implementations (or whatever you want to call the box) it's
none of our business. We shouldn't say, "nope, sorry you can't do that,
this is a client and you should use a stand-alone AAA server because of
the obvious benefits that have eluded you."
We cannot tell administrators anything for the simple reason that
they're not looking to us for guidance. However we do have some
influence over vendors, and we should tell vendors what we think makes
sense, i.e. what is the architecturally correct way to use the protocol.
More importantly, we should optimize the protocol (only) for the cases
that we think are reasonable. So we should care very much about usage
scenarios. As a concrete example, password management arguably matters
much more to remote access than to gateway-to-gateway scenarios. Should
we support it? Depends on the scenario(s) we want to work on.
We have RFCs on "host requirements" and "router requirements". There
isn't an RFC on "peer requirements" or "client requirements". Those are
terms that started in marketecture powerpoint slides and should not be
used to constrain or neuter our protocols.
No. For years we've had specific IPsec work items on remote access, it's
nothing new. If a protocol can be specified for the general use case,
that's very well. But there will be protocols that are only applicable
to some specific use cases, and that's fine, too.
Dan.
On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote:
Hi Yaron
Thank you for your clarification.
"between gateways" as opposed to
"between clients and gateways". So your assertion is correct.
(Between gateways, administrators can set long secrets, so the
necessity
of
PAKE seems smaller than between clients and gateways where passwords
are
recorded in the gateways and users have to type the passwords.)
Anyway, if the scope is limited only on "between gateways" but not
"between
clients and gateways," the title
"Password-Based Authentication in IKEv2: Selection Criteria and
Comparison"
seems misleading (since this itself misinforms that this criteria may
be
applied to IKEv2 in any cases), and the above should be clearly
mentioned
in
the document.
Kaz
-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
Sent: Friday, March 26, 2010 2:14 PM
To: Kaz Kobara
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)
Hi Kaz,
I *thought* my intention was clear: "between gateways" as opposed to
"between clients and gateways". So your assertion is correct.
Thanks,
Yaron
On 26.3.2010 1:40, Kaz Kobara wrote:
Hi Yaron
draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4
"This document is limited to the use of password-based
authentication
to
achieve trust between gateways"
I would like to make sure that
"gateway" in this document does not encompass VPN clients and hosts,
right?
Kaz
-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On
Behalf
Of
Yaron Sheffer
Sent: Friday, March 26, 2010 3:31 AM
To: SeongHan Shin
Cc: IPsecme WG; Kazukuni Kobara
Subject: Re: [IPsec] New PAKE Criteria draft posted
Hi Shin,
Yes. For the typical remote access VPN, EAP is typically more
useful.
Note that there is still need for strong password-based mutual
authentication EAP methods - but their home is the EMU working
group.
In addition, the IPsecME has another charter item designed to fit
such
EAP methods (such as the future EAP-AugPAKE :-) into IKEv2.
Please see again the group's charter,
http://tools.ietf.org/wg/ipsecme/charters.
Thanks,
Yaron
On 25.3.2010 20:07, SeongHan Shin wrote:
Dear Yaron Sheffer,
I have one question about the draft.
draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4
"This document is limited to the use of password-based
authentication
to
achieve trust between gateways"
Is this a consensus of this WG?
Best regards,
Shin
On Thu, Mar 25, 2010 at 3:46 PM, Yaron
Sheffer<yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>> wrote:
Hi,
after the good discussion in Anaheim, and with the help of
comments
received on and off the list, I have updated the PAKE
Criteria
draft
and posted it as
http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt.
I have added a number of criteria, clarified others, and
added
numbering (SEC1-SEC6, IPR1-IPR3 etc.).
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
--
------------------------------------------------------------------
SeongHan Shin
Research Center for Information Security (RCIS),
National Institute of Advanced Industrial Science and Technology
(AIST),
Room no. 1003, Akihabara Daibiru 10F,
1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan
Tel : +81-3-5298-2722
Fax : +81-3-5298-4522
E-mail : seonghan.s...@aist.go.jp<mailto:seonghan.s...@aist.go.jp>
------------------------------------------------------------------
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
