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

Re: IDi/IDr distinction



  This problem only exists because the ID payload is being overloaded
to support the "me tarzan, you jane" feature.

  It's obvious modifications to the draft are needed to support this
feature. Making distinct ID payloads for the initiator and responder
is one way to do it. There would also need to be some explanitory text
to describe how to implement this feature so that two independent
implementations can interoperate. 

  Another way would be to explain how to use the certificate request
payload to support this feature. Viz:

  - Remove the text from 3.7 that says "the only form of certificate
    request currently defined is X.509 signing certificate" and make
    the last paragraph of 3.7 be the description of how to process
    a cert request when the type is X.509 signing certificate.

  - Add the following to 3.7: "When the type is 'PGP Certificate' (2),
    'DNS Signed Key' (3), or 'Raw RSA Key' (11), the Certificate 
    Request Paylod is used to inform the peer of the key the peer
    should use when authenticating. This is useful when the peer
    supports multiple identities. When used in this manner the 
    'Certification Authority' portion of the payload contains the 
    relevant keying material depending on the 'Cert Encoding'".

  Dan.

On Sun, 30 Mar 2003 13:32:26 EST you wrote
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> The IDi and IDr payloads in the exchanges use the same payload number (5). 
> 
> The IDr may presently be appear in message 3 along with IDi. I see no
> way to distinguish them except by the ordering. Further, it is apparent
> to me that it would be beneficial if a third party (i.e. tcpdump or 
> another tool that was given access to the IKE-SA keys) could distinguish
> the payloads.
> 
> I therefore propose that the IDr be given a distinct payload number.
> 
> marajade-[ietf/id/ietf/ipsec] mcr 1051 %diff -u ikev2-05.txt ikev2-05-mcr.txt
> - --- ikev2-05.txt        Mon Feb 24 08:47:20 2003
> +++ ikev2-05-mcr.txt    Sun Mar 30 13:31:35 2003
> @@ -2660,7 +2660,10 @@
>        the Identification Type. The length of the Identification Data
>        is computed from the size in the ID payload header.
>  
> - -   The payload type for the Identification Payload is five (5).
> +   The payload type for the Identification Payload when used by the
> +   initiator is five (5).
> +   The payload type for the Identification Payload when used by the
> +   responder is 25 (25).
>  
>     The following table lists the assigned values for the Identification
>     Type field, followed by a description of the Identification Data
> 
> ]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls 
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architec
>t[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device drive
>r[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy");
> [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBPoc4OIqHRg3pndX9AQGxigP+JuXlnfuFHfvHV353ayPJ+pSjDt4MU3JE
> kZk0JshmcBwYe/Esja7BV/qcm1wdXYQQxtKF4QlTzzH8W1CpsLe3eDIjHv/AN4qd
> I2XwWKub0SOmcBkLIb5MJDIoeUHtyoWqKRwgwMlbXSnRm3F7+0BOGPIziHKm/ELx
> yaIywpNmx4M=
> =25OB
> -----END PGP SIGNATURE-----