Hi Wei,
Please ignore the previous response. Section 8 of the SKIP draft should read
as follows:
This document updates the use of the USE_PPK (16435) notify
message as defined in [RFC8784] to include the localSystemID of the
Key Provider as notification data,
Will update this in the next version, replacing the PPK_IDENTITY with USE_PPK.
Regards,
Rajiv.
From: Rajiv Singh (rajisin2) <rajis...@cisco.com>
Date: Monday, 2 September 2024 at 09:59
To: Panwei (William) <william.panwei=40huawei....@dmarc.ietf.org>,
draft-cisco-s...@ietf.org <draft-cisco-s...@ietf.org>
Cc: ipsec@ietf.org <ipsec@ietf.org>
Subject: Re: I-D Action: draft-cisco-skip-00.txt
Hi Wei,
Thank you for reaching out. You are correct in noting the difference in the
usage of the PPK_IDENTITY message between our draft and RFC 8784.
Our draft proposes an extension to the specification in RFC 8784. This update
is detailed in Section 7 of our draft under IANA Considerations.
Regards,
Rajiv.
From: Panwei (William) <william.panwei=40huawei....@dmarc.ietf.org>
Date: Saturday, 31 August 2024 at 16:16
To: draft-cisco-s...@ietf.org <draft-cisco-s...@ietf.org>
Cc: ipsec@ietf.org <ipsec@ietf.org>
Subject: RE: I-D Action: draft-cisco-skip-00.txt
Hi authors,
Thank you for publishing this draft. I'm glad to see this famous SKIP protocol
has finally been unveiled! ^_^
After browsed the draft, I have a simple question about one point related RFC
8784.
In section 5 describing using SKIP with IKEv2, it says that to have the
localSystemID as notification data of the USE_PPK notification payload.
(3) As part of IKE_SA_INIT exchange, encryptors propose the use of
IKEv2 PPK extension by including USE_PPK notification payload, having
type 16435, protocol ID of 0, no Security Parameter Index (SPI), and
the localSystemID of its co-located Key Provider as notification
data.
But in RFC 8784, in the beginning part of section 3, it says that USE_PPK has
no notification data.
N(USE_PPK) is a status notification payload with the type 16435; it
has a protocol ID of 0, no Security Parameter Index (SPI), and no
notification data associated with it.
I'd like to know whether the description of using RFC 8784 in SKIP in the draft
is a mistake, or SKIP requires an extension to RFC 8784
Regards & Thanks！
Wei PAN (潘伟)
> -----Original Message-----
> From: internet-dra...@ietf.org <internet-dra...@ietf.org>
> Sent: Friday, August 30, 2024 6:23 PM
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-cisco-skip-00.txt
>
> Internet-Draft draft-cisco-skip-00.txt is now available.
>
> Title: Secure Key Integration Protocol (SKIP)
> Authors: Rajiv Singh
> Craig Hill
> Scott Kawaguchi
> Joey Lupo
> Name: draft-cisco-skip-00.txt
> Pages: 24
> Dates: 2024-08-30
>
> Abstract:
>
> This document specifies the Secure Key Integration Protocol (SKIP), a
> two-party protocol that allows a client to securely obtain a key from
> an independent Key Provider. SKIP enables network and security
> operators to provide quantum-resistant keys suitable for use with
> quantum-resistant cryptographic algorithms such as AES-256. It can
> also be used to provide an additional layer of security to an already
> quantum-resistant secure channel protocol for a defense-in-depth
> strategy, and/or enforce key management policies.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-cisco-skip/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-cisco-skip-00.html
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list -- i-d-annou...@ietf.org To unsubscribe send
> an email to i-d-announce-le...@ietf.org
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
