Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[david.black]

> I think "IETF Review" would be good compromise for this as it would
> make it easier than "Standard Track RFC", but would satisfy those who
> do not want to have it as lower as "Specification Required" is...

Summarizing my views:
- "Specification Required" is an unacceptably low bar for this sort of
security protocol due to the possibility of security flaws.
- I prefer "IETF Review" to "Expert Review" for this sort of security
protocol as "IETF Review" should yield higher-quality results.

Thanks,
--David

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Tero Kivinen
> Sent: Wednesday, March 28, 2012 9:04 AM
> To: Dan Harkins
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods 
> (Value 3) registration
> policy
> 
> Dan Harkins writes:
> >   We can't always get what we want and we should be reasonable in
> > understanding that. If we could wave a magic wand and grant your wish
> > that would be good; we can't. And given the limits to our power we
> > have to accept that what will happen is people will continue to use
> > IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too
> > much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK
> > though, so it is likely that by adding SPSK to IKEv1 we could get people
> > off of XAUTH and that too would be a good thing.
> >
> >   So if we weigh the improbable stretch goal of forcing people to stop
> > using IKEv1 with the probable, more easily attainable, goal of getting
> > people to stop using XAUTH by giving them an alternative that can pretty
> > easily be implemented, I still come down on settling for an achievable
> > goal of goodness and not making that be a victim for an unachievable goal
> > of betterness.
> 
> The reason they cannot move to use IKEv1 + SPSK any faster than they
> can move to use IKEv2 + SPSK is same. Both of them do require new
> version of both client and server. The client customers always tell
> that the reason they cannot use IKEv2 as the SGW's they use do not
> support IKEv2 (or it is not turned on by default). The SGW customers
> say that the reason they cannot use IKEv2 as they clients do not
> support it (or it is not turned on by default)...
> 
> > > Regardless whether it is Specification Required or not, I am still
> > > objecting if someone tries to add new features to IKEv1. Of course my
> > > objecting might not have any effect, but I still think it is BAD idea.
> >
> >   OK, so we're in agreement: "Specification Required."
> 
> I originally suggested "Specification Required", so yes we are in
> agreement in that, but we are not only people in the WG, and there has
> been people saying otherwise. If we do not reach some kind of
> concensus, then the default action will most likely be "do nothing",
> which will mean the registry stays what it is now, and I do not want
> that.
> 
> I think "IETF Review" would be good compromise for this as it would
> make it easier than "Standard Track RFC", but would satisfy those who
> do not want to have it as lower as "Specification Required" is...
> --
> kivi...@iki.fi
> ___
> 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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Tero Kivinen]

Dan Harkins writes:
>   That's a really good point. Had it been "Specification Required" all
> along XAUTH might've gotten an official code point. And who knows maybe
> one of the j-random proposals might be just that. But IKEv1 really is
> pretty done. At this point I'm pretty sure that j would be zero.

Most likely not, as all IPsec work had to be stopped so we could ship
the IPsec out... IPSRA was supposed to do things like XAUTH and
Configuration mode etc, but it failed...
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Tero Kivinen]

Dan Harkins writes:
>   We can't always get what we want and we should be reasonable in
> understanding that. If we could wave a magic wand and grant your wish
> that would be good; we can't. And given the limits to our power we
> have to accept that what will happen is people will continue to use
> IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too
> much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK
> though, so it is likely that by adding SPSK to IKEv1 we could get people
> off of XAUTH and that too would be a good thing.
> 
>   So if we weigh the improbable stretch goal of forcing people to stop
> using IKEv1 with the probable, more easily attainable, goal of getting
> people to stop using XAUTH by giving them an alternative that can pretty
> easily be implemented, I still come down on settling for an achievable
> goal of goodness and not making that be a victim for an unachievable goal
> of betterness.

The reason they cannot move to use IKEv1 + SPSK any faster than they
can move to use IKEv2 + SPSK is same. Both of them do require new
version of both client and server. The client customers always tell
that the reason they cannot use IKEv2 as the SGW's they use do not
support IKEv2 (or it is not turned on by default). The SGW customers
say that the reason they cannot use IKEv2 as they clients do not
support it (or it is not turned on by default)...

> > Regardless whether it is Specification Required or not, I am still
> > objecting if someone tries to add new features to IKEv1. Of course my
> > objecting might not have any effect, but I still think it is BAD idea.
> 
>   OK, so we're in agreement: "Specification Required."

I originally suggested "Specification Required", so yes we are in
agreement in that, but we are not only people in the WG, and there has
been people saying otherwise. If we do not reach some kind of
concensus, then the default action will most likely be "do nothing",
which will mean the registry stays what it is now, and I do not want
that.

I think "IETF Review" would be good compromise for this as it would
make it easier than "Standard Track RFC", but would satisfy those who
do not want to have it as lower as "Specification Required" is... 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Yoav Nir]

On Mar 28, 2012, at 2:12 PM, Michael Richardson wrote:

> 
>> "Yoav" == Yoav Nir  writes:
>Yoav> If I had to guess the reasons for the slow adoption of IKEv2,
>Yoav> I would guess that it's because IKEv1 (with XAuth/hybrid,
>Yoav> Config, odd-numbered messages, and poor PSK support for mobile
>Yoav> peers) just works. The big vendors have at least server-side
>Yoav> support, and Microsoft has a client in Win7. I think EAP is a
>Yoav> hindrance, because XAuth works better with older backend
>Yoav> servers.
> 
> Let me suggest that enhancements to IKEv1 are point releases, for which
> you get with your maintenance.
> But, IKEv2 is a major release, for which the customer pays again.

I don't know about other vendors, but for us IKEv2 was introduced in a version 
called R71. Customers eventually do upgrade, whether it's to get IKEv2 or get 
one of the other features. Similarly in Windows, customers buy Windows 7 for 
the 64-bit support, or the aero interface, or for IPv6 support, and they also 
get the IKEv2. 

I don't think anyone is going to add new enhancements to old releases now, 
unless those "enhancements" begin with the words "prevent an attack where…"
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Michael Richardson]

> "Yoav" == Yoav Nir  writes:
Yoav> If I had to guess the reasons for the slow adoption of IKEv2,
Yoav> I would guess that it's because IKEv1 (with XAuth/hybrid,
Yoav> Config, odd-numbered messages, and poor PSK support for mobile
Yoav> peers) just works. The big vendors have at least server-side
Yoav> support, and Microsoft has a client in Win7. I think EAP is a
Yoav> hindrance, because XAuth works better with older backend
Yoav> servers.

Let me suggest that enhancements to IKEv1 are point releases, for which
you get with your maintenance.
But, IKEv2 is a major release, for which the customer pays again.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



pgpkqNgeB9Jzz.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Yoav Nir]

Hi Dan

I have no opinion about the level of review needed for changes to IKEv1, and I 
share your unhappiness with the way PAKE turned out. 

If I had to guess the reasons for the slow adoption of IKEv2, I would guess 
that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages, and 
poor PSK support for mobile peers) just works. The big vendors have at least 
server-side support, and Microsoft has a client in Win7. I think EAP is a 
hindrance, because XAuth works better with older backend servers.

Your proposal will be more secure than XAuth and require less round trips, but 
won't integrate with AAA servers.  I think anyone who is going to go to the 
effort of implementing this (replace or update all IKEv1 endpoints) might as 
well move them to IKEv2. The big hurdle to implementing what you suggest for 
remote access is that XAuth works. 

What doesn't work is a gateway with a dynamic external IP address that doesn't 
have a certificate. But I don't see how upgrading the gateways to support your 
extension is easier than upgrading them to support IKEv2. 

Yoav

On Mar 28, 2012, at 9:49 AM, Dan Harkins wrote:

> 
>  Hi,
> 
>  Let me answer David here in a response to Yaron
> 
>  To be equally blunt, it is because this PAKE work became extremely
> political and I was, and still am, very unhappy with the way it turned
> out. Repeating it, this time with an obsoleted protocol, would cause
> (more) people to question my sanity-- i.e. doing the same thing and
> expecting a different result.
> 
>  I'd like to just get a stable reference for this minor change that
> has the potential to do good. I don't want to fight over it anymore.
> 
>  regards,
> 
>  Dan.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

  Hi,

  Let me answer David here in a response to Yaron

  To be equally blunt, it is because this PAKE work became extremely
political and I was, and still am, very unhappy with the way it turned
out. Repeating it, this time with an obsoleted protocol, would cause
(more) people to question my sanity-- i.e. doing the same thing and
expecting a different result.

  I'd like to just get a stable reference for this minor change that
has the potential to do good. I don't want to fight over it anymore.

  regards,

  Dan.

On Tue, March 27, 2012 2:13 pm, Yaron Sheffer wrote:
> Hi Dan,
>
> I haven't made up my mind yet whether I support the addition of SPSK to
> IKEv1 or not, because both you and Tero have made some good points.
>
> But this very discussion is a strong proof to me that we need to have
> IETF Review (in the RFC 5226 sense) for this kind of major change to
> IKEv1. Because this is exactly the community that needs to discuss new
> authentication methods, and to weigh their security and other properties
> against the disadvantages of adding yet more stuff to IKEv1. This needs
> to be an open discussion, and I am sure the ADs will use our input when
> they decide whether to sponsor any such proposal.
>
> Thanks,
>   Yaron
>
> On 03/27/2012 06:41 PM, david.bl...@emc.com wrote:
>>>I think we can make things better with a simple addition and I just
>>> want to be able to do that.
>>
>> To ask bluntly - what is the problem with soliciting AD sponsorship for
>> the simple addition?
>>
>> IMHO, "Specification Required" by itself is entirely too weak for
>> security protocols.
>>
>> Thanks,
>> --David
>>
>>> -Original Message-
>>> From: Dan Harkins [mailto:dhark...@lounge.org]
>>> Sent: Tuesday, March 27, 2012 12:23 PM
>>> To: Black, David
>>> Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org
>>> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication
>>> Methods (Value 3) registration
>>> policy
>>>
>>>
>>>Hi David,
>>>
>>> On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:
>>>> Hi Dan,
>>>>
>>>> One process note:
>>>>
>>>>>It appears that all the PAKE drafts got one "yes" from the
>>>>> sponsoring
>>>>> AD and the remaining votes were "no objection" so it doesn't seem
>>>>> like
>>>>> the IESG is really interested in this topic and, frankly, I think the
>>>>> majority think "that stuff is out of my field of expertise". So my
>>>>> only
>>>>> option is to cajole an AD into sponsoring my draft and hoping that no
>>>>> one
>>>>> else on the IESG objects by saying, "didn't we just do this?"
>>>>
>>>> Speaking from long experience as a chair of many WGs, that sort of
>>>> IESG
>>>> vote tally is typical, even for WG docs (although usually both of the
>>>> responsible Area ADs vote yes, as they're both "sponsoring").  IMHO,
>>>> you're being overly pessimistic.
>>>>
>>>>>So let me turn it around, what's wrong with "Specification
>>>>> Required"?
>>>>
>>>> While I know that you're competent to design a solid  protocol, who
>>>> does
>>>> the security review of the next 5 j-random authentication mechanisms
>>>> to
>>>> make sure that they don't have security flaws?  I'd prefer something
>>>> like
>>>> IESG approval that puts the Security Area in the loop to the notion of
>>>> deferring to some form of Expert Review (this is not a slam against
>>>> Tero
>>>> as the expert - wider review usually produces better results).
>>>
>>>That's a really good point. Had it been "Specification Required" all
>>> along XAUTH might've gotten an official code point. And who knows maybe
>>> one of the j-random proposals might be just that. But IKEv1 really is
>>> pretty done. At this point I'm pretty sure that j would be zero.
>>>
>>>I know IKE's being used wrong and I know the people who are using it
>>> wrong don't want to go to IKEv2. They understand what they're doing is
>>> broken (a shared PSK for everyone followed by PAP in XAUTH) but they
>>> don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
>>> like going to IKEv2 with SPSK is much more attractive.
>>>
>>>I think we can make things better with a simple addition and I just
>>> want to be able to do that.
>>>
>>>regards,
>>>
>>>Dan.
>>>
>>>
>>
>> ___
>> 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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Yaron Sheffer]

Hi Dan,

I haven't made up my mind yet whether I support the addition of SPSK to 
IKEv1 or not, because both you and Tero have made some good points.


But this very discussion is a strong proof to me that we need to have 
IETF Review (in the RFC 5226 sense) for this kind of major change to 
IKEv1. Because this is exactly the community that needs to discuss new 
authentication methods, and to weigh their security and other properties 
against the disadvantages of adding yet more stuff to IKEv1. This needs 
to be an open discussion, and I am sure the ADs will use our input when 
they decide whether to sponsor any such proposal.


Thanks,
Yaron

On 03/27/2012 06:41 PM, david.bl...@emc.com wrote:

   I think we can make things better with a simple addition and I just
want to be able to do that.


To ask bluntly - what is the problem with soliciting AD sponsorship for the 
simple addition?

IMHO, "Specification Required" by itself is entirely too weak for security 
protocols.

Thanks,
--David


-Original Message-
From: Dan Harkins [mailto:dhark...@lounge.org]
Sent: Tuesday, March 27, 2012 12:23 PM
To: Black, David
Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org
Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods 
(Value 3) registration
policy


   Hi David,

On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:

Hi Dan,

One process note:


   It appears that all the PAKE drafts got one "yes" from the sponsoring
AD and the remaining votes were "no objection" so it doesn't seem like
the IESG is really interested in this topic and, frankly, I think the
majority think "that stuff is out of my field of expertise". So my only
option is to cajole an AD into sponsoring my draft and hoping that no
one
else on the IESG objects by saying, "didn't we just do this?"


Speaking from long experience as a chair of many WGs, that sort of IESG
vote tally is typical, even for WG docs (although usually both of the
responsible Area ADs vote yes, as they're both "sponsoring").  IMHO,
you're being overly pessimistic.


   So let me turn it around, what's wrong with "Specification Required"?


While I know that you're competent to design a solid  protocol, who does
the security review of the next 5 j-random authentication mechanisms to
make sure that they don't have security flaws?  I'd prefer something like
IESG approval that puts the Security Area in the loop to the notion of
deferring to some form of Expert Review (this is not a slam against Tero
as the expert - wider review usually produces better results).


   That's a really good point. Had it been "Specification Required" all
along XAUTH might've gotten an official code point. And who knows maybe
one of the j-random proposals might be just that. But IKEv1 really is
pretty done. At this point I'm pretty sure that j would be zero.

   I know IKE's being used wrong and I know the people who are using it
wrong don't want to go to IKEv2. They understand what they're doing is
broken (a shared PSK for everyone followed by PAP in XAUTH) but they
don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
like going to IKEv2 with SPSK is much more attractive.

   I think we can make things better with a simple addition and I just
want to be able to do that.

   regards,

   Dan.




___
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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[david.black]

>   I think we can make things better with a simple addition and I just
> want to be able to do that.

To ask bluntly - what is the problem with soliciting AD sponsorship for the 
simple addition?

IMHO, "Specification Required" by itself is entirely too weak for security 
protocols.

Thanks,
--David

> -Original Message-
> From: Dan Harkins [mailto:dhark...@lounge.org]
> Sent: Tuesday, March 27, 2012 12:23 PM
> To: Black, David
> Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods 
> (Value 3) registration
> policy
> 
> 
>   Hi David,
> 
> On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:
> > Hi Dan,
> >
> > One process note:
> >
> >>   It appears that all the PAKE drafts got one "yes" from the sponsoring
> >> AD and the remaining votes were "no objection" so it doesn't seem like
> >> the IESG is really interested in this topic and, frankly, I think the
> >> majority think "that stuff is out of my field of expertise". So my only
> >> option is to cajole an AD into sponsoring my draft and hoping that no
> >> one
> >> else on the IESG objects by saying, "didn't we just do this?"
> >
> > Speaking from long experience as a chair of many WGs, that sort of IESG
> > vote tally is typical, even for WG docs (although usually both of the
> > responsible Area ADs vote yes, as they're both "sponsoring").  IMHO,
> > you're being overly pessimistic.
> >
> >>   So let me turn it around, what's wrong with "Specification Required"?
> >
> > While I know that you're competent to design a solid  protocol, who does
> > the security review of the next 5 j-random authentication mechanisms to
> > make sure that they don't have security flaws?  I'd prefer something like
> > IESG approval that puts the Security Area in the loop to the notion of
> > deferring to some form of Expert Review (this is not a slam against Tero
> > as the expert - wider review usually produces better results).
> 
>   That's a really good point. Had it been "Specification Required" all
> along XAUTH might've gotten an official code point. And who knows maybe
> one of the j-random proposals might be just that. But IKEv1 really is
> pretty done. At this point I'm pretty sure that j would be zero.
> 
>   I know IKE's being used wrong and I know the people who are using it
> wrong don't want to go to IKEv2. They understand what they're doing is
> broken (a shared PSK for everyone followed by PAP in XAUTH) but they
> don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
> like going to IKEv2 with SPSK is much more attractive.
> 
>   I think we can make things better with a simple addition and I just
> want to be able to do that.
> 
>   regards,
> 
>   Dan.
> 
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

  Hi David,

On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:
> Hi Dan,
>
> One process note:
>
>>   It appears that all the PAKE drafts got one "yes" from the sponsoring
>> AD and the remaining votes were "no objection" so it doesn't seem like
>> the IESG is really interested in this topic and, frankly, I think the
>> majority think "that stuff is out of my field of expertise". So my only
>> option is to cajole an AD into sponsoring my draft and hoping that no
>> one
>> else on the IESG objects by saying, "didn't we just do this?"
>
> Speaking from long experience as a chair of many WGs, that sort of IESG
> vote tally is typical, even for WG docs (although usually both of the
> responsible Area ADs vote yes, as they're both "sponsoring").  IMHO,
> you're being overly pessimistic.
>
>>   So let me turn it around, what's wrong with "Specification Required"?
>
> While I know that you're competent to design a solid  protocol, who does
> the security review of the next 5 j-random authentication mechanisms to
> make sure that they don't have security flaws?  I'd prefer something like
> IESG approval that puts the Security Area in the loop to the notion of
> deferring to some form of Expert Review (this is not a slam against Tero
> as the expert - wider review usually produces better results).

  That's a really good point. Had it been "Specification Required" all
along XAUTH might've gotten an official code point. And who knows maybe
one of the j-random proposals might be just that. But IKEv1 really is
pretty done. At this point I'm pretty sure that j would be zero.

  I know IKE's being used wrong and I know the people who are using it
wrong don't want to go to IKEv2. They understand what they're doing is
broken (a shared PSK for everyone followed by PAP in XAUTH) but they
don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
like going to IKEv2 with SPSK is much more attractive.

  I think we can make things better with a simple addition and I just
want to be able to do that.

  regards,

  Dan.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

On Tue, March 27, 2012 7:39 am, Tero Kivinen wrote:
> Dan Harkins writes:
>>   That said, the problem I want to fix-- IKEv1's susceptibility to
>> dictionary attack, it's binding of a PSK to an IP address, and the
>> prevalence of XAUTH because there's no other option-- should be fixed.
>
> All others than the dictionary attack IS ALREADY FIXED. The fixes are
> in the IKEv2. Also the dictionary attack problem will be fixed by your
> IKEv2 SPSK draft.

  Yet there is still this massive deployment of XAUTH + IKEv1.

>> We can say, "stop using IKEv1" but giving someone the option of
>> implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
>> just continuing on with a broken XAUTH deployment, we all know what
>> they'll do and it's not doing PAKE + IKEv2.
>
> Yes, we can and should say "Stop using IKEv1".

  Yes we should. But we should not suffer any delusions that we can
force anyone to do anything.

> That is the part I agree with you. I do not want to add any new
> features to IKEv1, as that just makes people to continue use it, and
> not to update to the IKEv2. If PAKE is the stick that causes people to
> move from IKEv1 to IKEv2, that is very good.

  We can't always get what we want and we should be reasonable in
understanding that. If we could wave a magic wand and grant your wish
that would be good; we can't. And given the limits to our power we
have to accept that what will happen is people will continue to use
IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too
much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK
though, so it is likely that by adding SPSK to IKEv1 we could get people
off of XAUTH and that too would be a good thing.

  So if we weigh the improbable stretch goal of forcing people to stop
using IKEv1 with the probable, more easily attainable, goal of getting
people to stop using XAUTH by giving them an alternative that can pretty
easily be implemented, I still come down on settling for an achievable
goal of goodness and not making that be a victim for an unachievable goal
of betterness.

>> It would be a service to the Internet to provide a fix for this. The
>> IETF has not been successful in forcing people to do things against
>> their will (viz, the history of IPv6) and if we tried here we'd
>> likely fail again.
>>
>>   So let me turn it around, what's wrong with "Specification Required"?
>
> Read the whole original thread and find out there. I do not really
> have any objections for Specification Required, that was what I
> originally proposed. The original thread (I just gave the link to
> first email in the full thread) has emails which explains why people
> felt it was not enough.
>
> Regardless whether it is Specification Required or not, I am still
> objecting if someone tries to add new features to IKEv1. Of course my
> objecting might not have any effect, but I still think it is BAD idea.

  OK, so we're in agreement: "Specification Required."

  Dan.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Tero Kivinen]

david.bl...@emc.com writes:
> While I know that you're competent to design a solid  protocol, who
> does the security review of the next 5 j-random authentication
> mechanisms to make sure that they don't have security flaws?  I'd
> prefer something like IESG approval that puts the Security Area in
> the loop to the notion of deferring to some form of Expert Review
> (this is not a slam against Tero as the expert - wider review
> usually produces better results). 

None of the IKEv1 iana registries are expert review, so I do not have
anything to do with them, except as I am expert for the IKEv2
registries, IANA seems to assume I can help them to solve old issues
in the IKEv1 registries too, but I am doing that just as an individual
helping them...
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[david.black]

Hi Dan,

One process note:

>   It appears that all the PAKE drafts got one "yes" from the sponsoring
> AD and the remaining votes were "no objection" so it doesn't seem like
> the IESG is really interested in this topic and, frankly, I think the
> majority think "that stuff is out of my field of expertise". So my only
> option is to cajole an AD into sponsoring my draft and hoping that no one
> else on the IESG objects by saying, "didn't we just do this?"

Speaking from long experience as a chair of many WGs, that sort of IESG vote 
tally is typical, even for WG docs (although usually both of the responsible 
Area ADs vote yes, as they're both "sponsoring").  IMHO, you're being overly 
pessimistic.

>   So let me turn it around, what's wrong with "Specification Required"?

While I know that you're competent to design a solid  protocol, who does the 
security review of the next 5 j-random authentication mechanisms to make sure 
that they don't have security flaws?  I'd prefer something like IESG approval 
that puts the Security Area in the loop to the notion of deferring to some form 
of Expert Review (this is not a slam against Tero as the expert - wider review 
usually produces better results).

Thanks,
--David


> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan 
> Harkins
> Sent: Tuesday, March 27, 2012 10:14 AM
> To: Tero Kivinen
> Cc: ipsec@ietf.org; Dan Harkins
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods 
> (Value 3) registration
> policy
> 
> 
> On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote:
> > Dan Harkins writes:
> >>   I guess I'd like to register an objection. I wrote a draft a few
> >> months
> >> ago to address this:
> >>
> >>  http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
> >>
> >> That suggested making it "Specification Required". You mentioned that
> >> someone was opposed to it being "Specification Required" but didn't say
> >> who or what the rationale was behind that opposition.
> >>
> >>   So I'd like to discuss this a bit. I prefer "Specification Required"
> >> and would like to know what the problem someone has with it is.
> >
> > See the orignal thread in the ipsec-list:
> >
> > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html
> 
>   OK, but that says "'Specification Required' or 'IETF Review'", it's
> not opposition to "Specification Required".
> 
> > What is your objection to the IETF Review?
> 
>   Well, I feel it is setting the bar too high for what I want to do.
> I had to remove a chunk of text from my PAKE draft fixed a significant,
> know, serious, and continuing problem with IKEv1. I was told that
> I should write another I-D that includes that text and try to see
> what happens. The issue is that requiring IESG review and AD sponsorship
> will likely result in me not getting over that bar and getting a code
> point assigned.
> 
>   It appears that all the PAKE drafts got one "yes" from the sponsoring
> AD and the remaining votes were "no objection" so it doesn't seem like
> the IESG is really interested in this topic and, frankly, I think the
> majority think "that stuff is out of my field of expertise". So my only
> option is to cajole an AD into sponsoring my draft and hoping that no one
> else on the IESG objects by saying, "didn't we just do this?"
> 
>   I don't want to burn up what remaining goodwill I might have with
> our ADs by continuing to push this topic.
> 
>   That said, the problem I want to fix-- IKEv1's susceptibility to
> dictionary attack, it's binding of a PSK to an IP address, and the
> prevalence of XAUTH because there's no other option-- should be fixed.
> We can say, "stop using IKEv1" but giving someone the option of
> implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
> just continuing on with a broken XAUTH deployment, we all know what
> they'll do and it's not doing PAKE + IKEv2. It would be a service to
> the Internet to provide a fix for this. The IETF has not been successful
> in forcing people to do things against their will (viz, the history of
> IPv6) and if we tried here we'd likely fail again.
> 
>   So let me turn it around, what's wrong with "Specification Required"?
> 
>   thanks,
> 
>   Dan.
> 
> >> >   IETF Review - (Formerly called &quo

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Tero Kivinen]

Dan Harkins writes:
>   That said, the problem I want to fix-- IKEv1's susceptibility to
> dictionary attack, it's binding of a PSK to an IP address, and the
> prevalence of XAUTH because there's no other option-- should be fixed.

All others than the dictionary attack IS ALREADY FIXED. The fixes are
in the IKEv2. Also the dictionary attack problem will be fixed by your
IKEv2 SPSK draft. 

> We can say, "stop using IKEv1" but giving someone the option of
> implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
> just continuing on with a broken XAUTH deployment, we all know what
> they'll do and it's not doing PAKE + IKEv2.

Yes, we can and should say "Stop using IKEv1".

That is the part I agree with you. I do not want to add any new
features to IKEv1, as that just makes people to continue use it, and
not to update to the IKEv2. If PAKE is the stick that causes people to
move from IKEv1 to IKEv2, that is very good.

> It would be a service to the Internet to provide a fix for this. The
> IETF has not been successful in forcing people to do things against
> their will (viz, the history of IPv6) and if we tried here we'd
> likely fail again.
> 
>   So let me turn it around, what's wrong with "Specification Required"?

Read the whole original thread and find out there. I do not really
have any objections for Specification Required, that was what I
originally proposed. The original thread (I just gave the link to
first email in the full thread) has emails which explains why people
felt it was not enough.

Regardless whether it is Specification Required or not, I am still
objecting if someone tries to add new features to IKEv1. Of course my
objecting might not have any effect, but I still think it is BAD idea.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote:
> Dan Harkins writes:
>>   I guess I'd like to register an objection. I wrote a draft a few
>> months
>> ago to address this:
>>
>>  http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
>>
>> That suggested making it "Specification Required". You mentioned that
>> someone was opposed to it being "Specification Required" but didn't say
>> who or what the rationale was behind that opposition.
>>
>>   So I'd like to discuss this a bit. I prefer "Specification Required"
>> and would like to know what the problem someone has with it is.
>
> See the orignal thread in the ipsec-list:
>
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html

  OK, but that says "'Specification Required' or 'IETF Review'", it's
not opposition to "Specification Required".

> What is your objection to the IETF Review?

  Well, I feel it is setting the bar too high for what I want to do.
I had to remove a chunk of text from my PAKE draft fixed a significant,
know, serious, and continuing problem with IKEv1. I was told that
I should write another I-D that includes that text and try to see
what happens. The issue is that requiring IESG review and AD sponsorship
will likely result in me not getting over that bar and getting a code
point assigned.

  It appears that all the PAKE drafts got one "yes" from the sponsoring
AD and the remaining votes were "no objection" so it doesn't seem like
the IESG is really interested in this topic and, frankly, I think the
majority think "that stuff is out of my field of expertise". So my only
option is to cajole an AD into sponsoring my draft and hoping that no one
else on the IESG objects by saying, "didn't we just do this?"

  I don't want to burn up what remaining goodwill I might have with
our ADs by continuing to push this topic.

  That said, the problem I want to fix-- IKEv1's susceptibility to
dictionary attack, it's binding of a PSK to an IP address, and the
prevalence of XAUTH because there's no other option-- should be fixed.
We can say, "stop using IKEv1" but giving someone the option of
implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
just continuing on with a broken XAUTH deployment, we all know what
they'll do and it's not doing PAKE + IKEv2. It would be a service to
the Internet to provide a fix for this. The IETF has not been successful
in forcing people to do things against their will (viz, the history of
IPv6) and if we tried here we'd likely fail again.

  So let me turn it around, what's wrong with "Specification Required"?

  thanks,

  Dan.

>> >   IETF Review - (Formerly called "IETF Consensus" in
>> > [IANA-CONSIDERATIONS]) New values are assigned only
>> through
>> > RFCs that have been shepherded through the IESG as AD-
>> > Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
>> > intention is that the document and proposed assignment
>> will
>> > be reviewed by the IESG and appropriate IETF WGs (or
>> > experts, if suitable working groups no longer exist) to
>> > ensure that the proposed assignment will not negatively
>> > impact interoperability or otherwise extend IETF protocols
>> > in an inappropriate or damaging manner.
>> >
>> > To ensure adequate community review, such documents are
>> > shepherded through the IESG as AD-sponsored (or WG)
>> > documents with an IETF Last Call.
>> >
>> > Examples: IPSECKEY Algorithm Types [RFC4025],
>> > Accounting-Auth-Method AVP values in DIAMETER [RFC4005],
>> TLS
>> > Handshake Hello Extensions [RFC4366].
> --
> kivi...@iki.fi
> ___
> 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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Tero Kivinen]

Dan Harkins writes:
>   I guess I'd like to register an objection. I wrote a draft a few months
> ago to address this:
> 
>  http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
> 
> That suggested making it "Specification Required". You mentioned that
> someone was opposed to it being "Specification Required" but didn't say
> who or what the rationale was behind that opposition.
> 
>   So I'd like to discuss this a bit. I prefer "Specification Required"
> and would like to know what the problem someone has with it is.

See the orignal thread in the ipsec-list:

http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html

What is your objection to the IETF Review?

> >   IETF Review - (Formerly called "IETF Consensus" in
> > [IANA-CONSIDERATIONS]) New values are assigned only through
> > RFCs that have been shepherded through the IESG as AD-
> > Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
> > intention is that the document and proposed assignment will
> > be reviewed by the IESG and appropriate IETF WGs (or
> > experts, if suitable working groups no longer exist) to
> > ensure that the proposed assignment will not negatively
> > impact interoperability or otherwise extend IETF protocols
> > in an inappropriate or damaging manner.
> >
> > To ensure adequate community review, such documents are
> > shepherded through the IESG as AD-sponsored (or WG)
> > documents with an IETF Last Call.
> >
> > Examples: IPSECKEY Algorithm Types [RFC4025],
> > Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
> > Handshake Hello Extensions [RFC4366].
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

  Hi Tero,

  I guess I'd like to register an objection. I wrote a draft a few months
ago to address this:

 http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt

That suggested making it "Specification Required". You mentioned that
someone was opposed to it being "Specification Required" but didn't say
who or what the rationale was behind that opposition.

  So I'd like to discuss this a bit. I prefer "Specification Required"
and would like to know what the problem someone has with it is.

  thanks,

  Dan.

On Mon, March 26, 2012 9:49 am, Tero Kivinen wrote:
> As described in the IPsecME WG meeting I propose that we change the
> registration policy for the IPSEC Authentication Methods (Value 3) of
> ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From
> RFC5226):
>
> --
>   IETF Review - (Formerly called "IETF Consensus" in
> [IANA-CONSIDERATIONS]) New values are assigned only through
> RFCs that have been shepherded through the IESG as AD-
> Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
> intention is that the document and proposed assignment will
> be reviewed by the IESG and appropriate IETF WGs (or
> experts, if suitable working groups no longer exist) to
> ensure that the proposed assignment will not negatively
> impact interoperability or otherwise extend IETF protocols
> in an inappropriate or damaging manner.
>
> To ensure adequate community review, such documents are
> shepherded through the IESG as AD-sponsored (or WG)
> documents with an IETF Last Call.
>
> Examples: IPSECKEY Algorithm Types [RFC4025],
> Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
> Handshake Hello Extensions [RFC4366].
> --
>
> I will ask IANA to make the change at the 2012-04-15, unless I get
> some objections here in the list.
> --
> kivi...@iki.fi
> ___
> 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] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Tero Kivinen]

As described in the IPsecME WG meeting I propose that we change the
registration policy for the IPSEC Authentication Methods (Value 3) of
ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From
RFC5226):

--
  IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.

To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.

Examples: IPSECKEY Algorithm Types [RFC4025],
Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
Handshake Hello Extensions [RFC4366].
--

I will ask IANA to make the change at the 2012-04-15, unless I get
some objections here in the list. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec