MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)
draft-ietf-msec-mikey-rsa-r-07

[Ballot discuss]
The 07 version has text that fixes all the points in my discuss.

------------------------------------------------------

It took me a long time to track through all this. Here is my understanding of the state of things - let me know if I have it about right.

The base MIKEY draft defines both the a mandatory to implement certificate in the MIKEY messages and an optional URI that points at the certificate method. It does not state what type of URI might be used or format of data one might fetch over the implied transports. If one device is doing RSA-R with another, there is no way to discover what the other end might support. So for all practical purposes, the URI reference to a certificate is not usable. I agree it is no less unspecified that the base MIKEY, but none the less, it does not seem like two devices will not be able to use it in an interoperable way. Now this may be completely by design choice but it leads to the second part of the problem. Assuming one of the uses of this was SIP, we would need to include the certificate in the message. For 3DES level security - I'm assuming that would give us something like 800 bytes certs in DER format and with rest of the MIKEY message, the encoding into SDP, rest of SIP message etc, I suspect that it would quickly exceed the 1300 byte limit for UDP SIP requests. The conclusion that I come to is that this could not be used with SIP over UDP.

So where to go from here:
possibility 1) part of what I am saying above is wrong, we should educate me on it and I can clear all this

possibility 2) Yep, above is about right and that is known limitations and ok. If so, lets just add an applicability statement and I will clear the discuss.

possibility 3) this was not what people hand in mind, we want to use the URI indirection technique. In this case lets add some stuff to say what is mandatory to implement so that the callee knows what they can use and depend on the the other side being able to process.

possibility 4) something else :-) I'm open to any suggestion. I think this document is a useful addition to MIKEY and I want it to move forward - I'm just trying to not have surprises on it.

I suspect that path 2 is likely what we want to do but whatever folks think.

[Ballot discuss]
It took me a long time to track through all this. Here is my understanding of the state of things - let me know if I have it about right.

The base MIKEY draft defines both the a mandatory to implement certificate in the MIKEY messages and an optional URI that points at the certificate method. It does not state what type of URI might be used or format of data one might fetch over the implied transports. If one device is doing RSA-R with another, there is no way to discover what the other end might support. So for all practical purposes, the URI reference to a certificate is not usable. I agree it is no less unspecified that the base MIKEY, but none the less, it does not seem like two devices will not be able to use it in an interoperable way. Now this may be completely by design choice but it leads to the second part of the problem. Assuming one of the uses of this was SIP, we would need to include the certificate in the message. For 3DES level security - I'm assuming that would give us something like 800 bytes certs in DER format and with rest of the MIKEY message, the encoding into SDP, rest of SIP message etc, I suspect that it would quickly exceed the 1300 byte limit for UDP SIP requests. The conclusion that I come to is that this could not be used with SIP over UDP.

So where to go from here:
possibility 1) part of what I am saying above is wrong, we should educate me on it and I can clear all this

possibility 2) Yep, above is about right and that is known limitations and ok. If so, lets just add an applicability statement and I will clear the discuss.

possibility 3) this was not what people hand in mind, we want to use the URI indirection technique. In this case lets add some stuff to say what is mandatory to implement so that the callee knows what they can use and depend on the the other side being able to process.

possibility 4) something else :-) I'm open to any suggestion. I think this document is a useful addition to MIKEY and I want it to move forward - I'm just trying to not have surprises on it.

I suspect that path 2 is likely what we want to do but whatever folks think.

[Ballot discuss]
The draft leaves a few details around the edge unspecified and I think we need to specify these to have interoperable devices. They are all fairly trivial to deal with.

What URI types MUST be implemented for fetching certs. Are there any security concerns for fetching the cert.

Does a devices have to implement both the embedded CERT and link to CERT approach.

The document needs to discuss how large these are and any issues that might lead to when used in SDP transported over UDP.

[Ballot comment]
I did not fully understand how this worked in group mode - I believe it works. It just the description could use a bit more overview that made it easier to understand.

The document would be better with an example that could be used as test vector.

[Ballot comment]
Section 1.1., paragraph 0:

>    The MIKEY protocol [RFC3830] has three different methods for key
>    transport or exchange: a pre-shared key mode (PSK), a public-key
>    (RSA) mode, and an optional Diffie-Hellman exchange (DHE) mode.  In
>    addition, there is also an optional DH-HMAC mode [I-D.ietf-msec-
>    mikey-dhhmac], bringing the total number of modes to four.  The
>    primary motivation for the MIKEY protocol design is low-latency
>    requirements of real-time communication, and thus all the exchanges
>    finish in one-half to 1 round-trip; note that this offers no room for
>    security parameter negotiation of the key management protocol itself.
>    In this document, we note that the MIKEY modes defined in RFC3830
>    [RFC3830] and [I-D.ietf-msec-mikey-dhhmac] are insufficient to
>    address some deployment scenarious and common use cases, and propose
>    a new mode called MIKEY-RSA in Reverse mode, or simply as
>    MIKEY-RSA-R.  This document updates RFC 3830 with the addition of
>    this new mode to that specification.

        NIT: s/scenarious/scenarios/


Section 3.7.3., paragraph 2:

>          Type      | Value | Comment
>          -------------------------------------------------------
>          Vendor ID |    0 | Vendor specific byte string
>          SDP IDs  |    1 | List of SDP key mgmt IDs
>                    |      |  (allocated for use in [KMASDP])
>          CSB-ID    |    3 | Responder's modified CSB-ID (group mode)

        Missing Reference: [KMASDP]

ANA Last Call Comments:

Upon approval of this document, the IANA will register the below assignments in the
appropriate registries located at the following:
http://www.iana.org/assignments/mikey-payloads

"Error Payload namespace:"
Unsupported message type ------- 13

"Common Header payload name spaces:"
RSA-R I_MSG ------------- 9
RSA-R R_MSG ------------- 10

General Extensions payload name spaces:
CSB-ID ----------------- 3

We understand the above assignments to be the only IANA Actions.