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

Reply via email to