[IPsec] Fwd: New Version Notification for draft-reddy-ipsecme-ikev2-pqc-auth-00.txt
Hi all, The new draft, https://www.ietf.org/archive/id/draft-reddy-ipsecme-ikev2-pqc-auth-00.html outlines how post-quantum digital signatures, specifically ML-DSA and SLH-DSA, can be employed as authentication methods within the IKEv2 protocol. Comments and suggestions are welcome. Cheers, -Tiru -- Forwarded message - From: Date: Thu, 16 May 2024 at 11:22 Subject: New Version Notification for draft-reddy-ipsecme-ikev2-pqc-auth-00.txt To: Tirumaleswar Reddy.K , Scott Fluhrer < sfluh...@cisco.com>, Valery Smyslov A new version of Internet-Draft draft-reddy-ipsecme-ikev2-pqc-auth-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-ipsecme-ikev2-pqc-auth Revision: 00 Title:Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC Date: 2024-05-16 Group:Individual Submission Pages:9 URL: https://www.ietf.org/archive/id/draft-reddy-ipsecme-ikev2-pqc-auth-00.txt Status: https://datatracker.ietf.org/doc/draft-reddy-ipsecme-ikev2-pqc-auth/ HTML: https://www.ietf.org/archive/id/draft-reddy-ipsecme-ikev2-pqc-auth-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-reddy-ipsecme-ikev2-pqc-auth Abstract: Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document outlines how post-quantum digital signatures, specifically Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-DSA), can be employed as authentication methods within the IKEv2 protocol. It introduces ML- DSA and SLH-DSA capability to IKEv2 without necessitating any alterations to existing IKE operations. The IETF Secretariat ___ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
On Tue, 31 Jan 2023 at 13:49, Valery Smyslov wrote: > Hi Tero, > > thank you for the review. Please see inline. > > > Here are some my review comments while reading > > draft-ietf-ipsecme-add-ike: > > > > -- > > The text in section 3.1 should say that if length is 0, then no > > Service Priority, Num Addresses etc fields are present. > > > > I.e., add text in first bullet under Length saying that if length is > > zero, then later fields are not present. > > Makes sense. > > > -- > > > > Also the text in Num Addresses indicate that it would be valid to send > > CFG_REQUEST with proposed Service Priority, but having Num Addresses > > set to zero? > > > > Is this intended? I.e., is the client allowed to request data, but not > > propose IP address? If so, perhaps add sentence to Num Addresses > > explaining that it can be 0 for CFG_REQUEST when no specific address > > is request, but other parameters are requested. > > Hm... I think my co-authors can comment on this. > > > -- > > > > In IP Address(es) explictly mention that it is field contain 4 octet > > IPv4 addresses, or 16 octet IPv6 address without any delimeters etc. > > This can be derived from the calculation of the length field, but I > > think it should be mentioned here, even when it is obvious. > > OK. > > > -- > > > > In section 3.2 it is not clear what the length of the Hash Algorithm > > Identifiers fields is. It contains list of hash algorithms or one hash > > algorithm if this is response, but it is not clear what is response. > > What was meant is that a list of hashes is sent by a client (in > CFG_REQUEST) and > a single hash is sent by a server (in CFG_REPLY). > > > We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely > > CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other > > hand CFG_SET is usually used to set the parameters, thus the > > Certificate Digest would be required there. > > True, but IKEv2 doesn't currently use CFG_SET/CFG_ACK and > it explicitly allows implementations to ignore them. > > > I would assume that there is only one Hash Algorithm Identifier for > > CFG_REPLY and CFG_SET, and then the Certificate Digest field is > > present. For CFG_REQUEST the Hash Algorithm Identifier is a list of > > two octet hash algorithm identifiers and the Certificate field is > > omitted. For the CFG_ACK only first 4 octets are included and Length > > is set to zero. > > > > I think it would be better to split the Figure 2 to three different > > figures: > > > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+---+ > >|R| Attribute Type |Length | > >+-+-+---+---+ > >|RESERVED | ADN Length | > >+---+---+ > >~ Authentication Domain Name ~ > >+---+ > >~ Hash Algorithm Identifier (2 octets) ~ > >+---+ > >~ Certificate Digest~ > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2: ENCDNS_DIGEST_INFO Attribute Format for CFG_REPLY and CFG_SET > > > > > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+---+ > >|R| Attribute Type |Length | > >+-+-+---+---+ > >|RESERVED | ADN Length | > >+---+---+ > >~ Authentication Domain Name ~ > >+---+ > >~ List of Hash Algorithm Identifiers ~ > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+---+ > >|R| Attribute Type |Length | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK. > > > > and then explain the Hash Algorithm Identifier and List of Hash >
Re: [IPsec] IPR Poll RE: Shepherd write-up information for draft-ietf-ipsecme-add-ike
I am not aware of any IPR that applies to this draft. Cheers, -Tiru On Mon, 30 Jan 2023 at 12:00, wrote: > Hi all, > > As a input to the writeup, we are replying to the IPR poll on-list. > > I don't have any IPR nor I'm aware of any related to this draft. > > My co-authors replies will follow soon. > > Cheers, > Med > > > -Message d'origine- > > De : Tero Kivinen > > Envoyé : dimanche 29 janvier 2023 18:01 > > À : draft-ietf-ipsecme-add-...@ietf.org > > Objet : Shepherd write-up information > > > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-add-ike
Thanks Tommy for the detailed review. Proposed changes look good to me. Cheers, -Tiru On Wed, 10 Aug 2022 at 22:03, Tommy Pauly wrote: > I’ve done a review pass of this document. In general, I think it is > technically good. > > I did find several places where I think additional clarity or editorial > improvements could be made. To address these, I’ve proposed the following > pull request: > https://github.com/boucadair/draft-ietf-ipsecme-add-ike/pull/5 > > Some of the revenant items I am trying to address are: > - Make it more clear early on that the attributes are generically > communicating encrypted DNS resolvers, and don’t define specific details > for DoH/DoT/DoQ (that comes from the SVCB-DNS draft) > - Be more explicit about how ENCDNS_IP* are two specific types, ENCDNS_IP4 > and ENCDNS_IP6 > - Introduce and explain ENCDNS_DIGEST_INFO earlier on. Currently, it is > defined with no explanation until a later section. > - Clarify the behavior of the initiator for including ENCDNS_IP* > attributes. Specifically, I believe this is intended to be: either include > exactly one empty ENCDNS_IP* attribute of a given type to request “any” > encrypted DNS resolver on that address family; OR, include one or more of > that type with hints about the addresses and APNs being requested. This was > implied by the text previously, but not clear. > > If these items are addressed, I’m happy to see this progress. > > Thanks, > Tommy > > On Aug 9, 2022, at 1:47 PM, Tero Kivinen wrote: > > This is the start of 2 week WGLC on the document, ending 2022-08-17. > Please submit your comments to the list, also send a note if you have > reviewed the document, so we can see how many people are interested in > getting this out. > -- > 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 mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
I support adoption of the draft. -Tiru On Mon, 8 Nov 2021 at 19:58, wrote: > Hi Tero, all, > > I support adoption. > > FWIW, I'm not aware of any IPR related to this I-D. > > Cheers, > Med > > > -Message d'origine- > > De : IPsec De la part de Tero Kivinen > > Envoyé : lundi 8 novembre 2021 15:17 > > À : ipsec@ietf.org > > Objet : [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > > > This is the start of 2 week WG adoption call for this document, ending > > 2021-11-22. Please send your reply about whether you support adopting > this > > document as WG document or not. > > -- > > kivi...@iki.fi > > > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
