Hi Sean,
Section 5. IANA Considerations can be reworded in-line with ikev2bis.
5. IANA Considerations
IANA has already registered the type and value for AES-CTR.
Name Number Defined In
ENCR_AES_CTR 13 (RFC3686 <
Thank you, Yoav,
I will have it fixed, listen to this channel for other suggestions and have the
revised version submitted by Mar 8th.
Sean
In your mail:
>From: Yoav Nir
>Reply-To:
>To: "'Paul Hoffman'" , IPsecme WG
>Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
>
Paragraph 5 of section #2:
MUST accept any length that results in proper alignment. It should
be noticed that the ESP [RFC4303] Encrypted Payload requires
Please change "noticed" to "noted".
Other than that, the document looks good enough for implementation.
-Original Message-
Fro
This IPR disclosure is relevant to this discussion:
https://datatracker.ietf.org/ipr/63/
Thanks,
--David
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Blumenthal, Uri - 0662 -
> MITLL
> Sent: Wednesday, March 03, 2010 9:26 AM
> To: 'pgut
Hi,
I did not cc cfrg on a post I made yesterday, Yaron responded
to it and I have been asked to forward this to the cfrg list to
encourage discussion. Sorry for the confusion. (And if you see
multiple copies of this, sorry about that too, I fat-fingered the
cfrg list the last time).
Dan.
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the IP Security Maintenance and Extensions
>Working Group of the IETF.
>
> Title : Using Advanced Encryption Standard (AES) Counter Mode
> with IKEv2
> Author(s)
Hi Uri,
The exchange described in draft-harkins-ipsecme-spsk-auth does not
have the same requirements on groups as EKE. To the best of my
knowledge, it can use all of the MODP and ECP groups in the IANA
registry. So the same group that is being used to do the DH exchange
in IKE(v2) could be u
Hi,
I did not cc cfrg on a post I made yesterday, Yaron responded
to it and I have been asked to forward this to encourage discussion.
Sorry for the confusion.
Dan.
Original Message
Subject: Re: [IPsec] Beginning discussion on secu
Yes I mean other protocols potentially covered by EKE patent.
Regards,
Uri
- Original Message -
From: Steven M. Bellovin
To: Blumenthal, Uri - 0662 - MITLL
Cc: 'dhark...@lounge.org' ; 'ipsec@ietf.org'
; 'c...@irtf.org' ; 'black_da...@emc.com'
; 'paul.hoff...@vpnc.org'
Sent: Wed Mar 03
On Wed, 3 Mar 2010 09:30:53 -0500
"Blumenthal, Uri - 0662 - MITLL" wrote:
> A reasonable question is - do all the proposed "EKE variations" have
> the same requirement (and the same weakness)? Or only the original
> EKE does?
>
I'm not sure what you mean by "EKE variants" -- all of the variants
On 3/3/10 6:25 AM, "Blumenthal, Uri - 0662 - MITLL" wrote:
> You're good! :-)
>
> On the vendor side - perhaps EKE patent concern was the cause (you
> implement/sell free SRP and get slapped with EKE licensing)? And the users
> found alternative solutions in the meanwhile?
No, I can say that t
A reasonable question is - do all the proposed "EKE variations" have the same
requirement (and the same weakness)? Or only the original EKE does?
Regards,
Uri
- Original Message -
From: cfrg-boun...@irtf.org
To: Dan Harkins
Cc: ipsec@ietf.org ; c...@irtf.org ;
black_da...@emc.com ; pa
You're good! :-)
On the vendor side - perhaps EKE patent concern was the cause (you
implement/sell free SRP and get slapped with EKE licensing)? And the users
found alternative solutions in the meanwhile?
Do you think weak passwords are too dangerous overall (many other ways of
attacking them
I see value in adding a simpler-than-EAP method, and support this effort. But
overall it's an extremely difficult task because of IPR.
I personally would hate to see a patent-encumbered solution - and that would
disqualify EKE and PAK outright (both held by Alcatel-Lucent, AFAIK). SRP would
be
Yoav Nir writes:
> Yes, you can sort-of negotiate DH groups, but you don't have the
> "New Group Mode" that we had in section 5.6 or RFC 2409.
Yes, that was left out but as it was seen that nobody will accept new
group proposed from unknown party without checking it first, and
checking that the m
Yes, you can sort-of negotiate DH groups, but you don't have the "New Group
Mode" that we had in section 5.6 or RFC 2409.
So with RFC 4306, you're stuck with only those groups that appear in the IANA
registry, rather than your own pet DH groups.
On Mar 2, 2010, at 10:49 PM, Yaron Sheffer wrote:
16 matches
Mail list logo
