[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding revised identities to IKEv2


{I'm sorry to take so long to reply to this thread. I have read the entire
thread, which has been on my todo for a long time}

I would like to amend the 5.5 section as follows. The goal here is to make
sure that the initiator can indicate to the responder which identity the
initiator thinks it is connecting to. This does not have a lot of relevance
to a typical VPN usage, but becomes critical when the responder is a multiuser
system, or a multi-identiy system. Any system that practices key rollover
where a new key may get published in advance of retiring the old key may
experience the problems of multi-identity.

I will preface this with two comments:
     a) it might be that is makes sense to have two FullID-type payloads,
	with differing type codes, but otherwise identical structure.
	One for "Me", the other for "You"

     b) we have explicitely included the public key used for signing
	in the payload, in addition to either a certificate, or reference
	to something that would authenticate the public key. This is so
	that IKEv2 processing can continue *in parallel* with key

This is the "Me-Tarzan/You-Jane" (vs "Me-Tarzan/You-Sybil") proposal several
of us have been talking about.

Finally, if the key is not verified, but just accepted (according to some
policy that would permit this in certain situations), one has a form of
anonymous encryption that is possible. This may in fact be useful for use
by legacy authentication systems - in this context one would use the legacy
auth to authenticate the public keys rather than the DH exponents. This may
be easier to do - certainly, it is easier to *CACHE*, and therefore may make
rekeying of SAs that were established using a legacy auth more clear.


5.5 FullID Payload

   The FullID Payload, denoted FullID in this memo, allows peers to
   identify themselves, and to indicate to whom they believe they are
   speaking. The FullID Payload appears in messages 3 and 4, and names the
   identity associated with the AUTH payload.

   The FullID Payload consists of the IKE generic header followed by
   identification fields as follows:

                           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
      ! Next Payload  !C!  RESERVED   !         Payload Length        !
      ! me-ID Type    ! You-ID Type   !     me-public key length      |
      !      me-ID length             !  you-public key length        |
      ! algorithm     !                                               !
      +-+-+-+-+-+-+-+-+                                               +
      ~             Me-public key (RFC 3110/2536 format)              ~
      !                                                               !
      !                                                               !
      ~                Me-Identification Data                         ~
      !                                                               !
      ! algorithm     !                                               !
      +-+-+-+-+-+-+-+-+                                               +
      !                                                               !
      ~            You-public key (RFC 3110/2536 format)              ~
      !                                                               !
      !                                                               !
      ~               You-Identification Data                         ~
      !                                                               !

               Figure 8:  FullID Payload Format

   o  Me/You ID Type (1 octet) - Specifies the type of Identification being

   o  RESERVED - MUST be sent as zero; MUST be ignored.

   o  Me-public key length - the length in bytes of my public key section,
      including the algorithm byte.

   o  Me-ID length - the length of the Me-Identification section.

   o  You-public key length - the length in bytes of the public key I expect
      you to use, zero, if the initiator doesn't not know. The length
      includes the algorithm byte. 

   o  algorithm - as per section 3.2 of RFC2525 (or its successor)

   o  Me/You-public key. An RSA or DSA key, in RFC3110 or RFC2536 format.
      (i.e. 1 byte for exponent size, that many bytes of exponent, and the
      rest is modulus).

   o  Me/You-Identification Data (variable length) - Value, as indicated by
      the Identification Type. The length of the You-Identification Data
      is computed from the size in the ID payload header, subtracting the
      other three field sizes.

   The payload type for the Identification Payload is XXXX.  ****This
   should not be 5; that is, we should not re-use the payload number
   from IKEv1's Identity payload.*****

   The following table lists the assigned values for the FullID
   Type field, followed by a description of the Identification Data
   which follows:

   The payload's format is an ID type followed by the content. The ID types are:

     ID Type                           Value
      -------                           -----
      RESERVED                            0

      PKIX certificate                    1

         A standalone PKIX certificate.

      Certificate bundle                  2

         A simple ASN.1 sequence of PKIX certificates. A bundle can have
         end-entity certificates and/or certificates from a chain to a
         root. The first certificate in the bundle is the sender's
         preferred identity certificate, but beyond that there is no
         meaning to the ordering.

      Hash-and-URL of PKIX certificate    3

         The first 20 octets are the SHA-1 hash of a certificate; the
         rest is a URL that resolves to the certificate. This is
         described in more detail below.

      URL to a PKIX certificate bundle    4

         This is described in more detail below.

      PKIX keyIdentifier                  5

         Identifies a self-signed certificate that the receiver has
         already pre-loaded. Note that this is only useful when using
         self-signed certificates.

      IDForSharedSecret                   6

         This is only for use with shared secrets. It is an ASCII
         string (all octets are 31 < x < 127) of any length.

      DNS name                            7
         A fully qualified DNS name at which an IPSECKEY record will be
	 found. DNSSEC will authenticate the data. If the length of this
	 field is zero, then the value found in the Identity payload is used
	 if appropriate. (i.e. it must be ID_FQDN, ID_RFC822_ADDR,
	 ID_IPV4_ADDR, or ID_IPV6_ADDR. ID_RFC822_ADDR is converted to a
	 domain by converting the @ to a period)
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys