Subject: RE: [MSEC] new MIKEY draft - Questions and Comments

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 11 Mar 2002 11:58:34 +0100

Dear MIKEY editors,

By comparing MIKEY-01 against the previous version, I'm convinced that this
new version is indeed a significant improvement.

Below I have compiled several questions and comments upon MIKEY that I came
across during my review.

I've named each question with a number, showed the reference to MIKEY-01.txt
with section number and mostly also a short quote >> ...<< from the text.

Q.1) Reference: section 1.2.

I'm still struggling hard to understand if MIKEY uses the same terminology
as SRTP; I'm not yet convinced since the definitions sound differently and
the mapping is not obvious.

I guess that MIKEY-crypto session corresponds to an SRTP session, but the
MIKEY "uni. or bi-directional" notion lets me wonder.

Here is my rough guess, how the situation might be:

MIKEY					SRTP
----------------------------------------------------------------------------
--
Crypto session				SRTP session
Multimedia crypto session (MCS)	RTP session ?
???					cryptographic context
Security Association (SA)		(MKI) ???
Data SA				???
Re-key SA				???
Pre-Master Key				master key
Traffic-encrypting key			session key/master key?
Key Encryption key			???
PMK re-keying				key derivation?
SPI					MKI
TMMH-16				TMMH version 2/2 word tag
...					...

It might be the case that some of the terms are just local within a
document, but certainly several terms affect the key management interface.

So I see need to harmonize the terminology across SRTP and MIKEY and to
ascertain that the definitions are exactly identical.

Q.2) Reference: section 3 >> The signature/MAC is then computed over the
entire message (not only the specific values that are shown in the protocol
definition).<<

I would add "MIKEY payload" in order to avoid the impression that the
signature/MAC would be computed over a surrounding SIP or SDP message.

Thus the sentence would read: " The signature/MAC is then computed over the
entire MIKEY payload message (not only the specific values that are shown in
the protocol definition)."

Q.3) Reference: sections 3.1, 3.2 and 3.3

All the key management protocols include the ID of the initiator. However,
the ISO/IEC 9798-2,3,4 key management protocols that are quite similar to
the MIKEY protocols also include the ID of the recipient in the protected
exchange. The purpose is to counter reflection attacks. This should be
considered for MIKEY too!

In any way, a formal security protocol analysis of MIKEY is required to find
out whether there are weaknesses in it and whether the protocols fulfils all
the stated (and non-stated) security goals. This is not trivial anymore,
since the protocols become more and more complex and use quite substantial
amount of protected information in the payloads.

Q.4) Reference: section 4.1.2, section 4.2.1

My understanding of function P is that the HMAC is actually an HMAC_H(args)
where the parameter H refers to the possible hash functions such as SHA1,
MD5, SHA256/384/512.

Q.5) Reference: section 4.2.1 >> 4.2.1 Hash functions"

In order to avoid confusion with the hash functions used for the payload
digest and in certificates, let me propose to title section 4.2.1 as "PRF
hash functions" and change the sentence to:

"MIKEY PRF SHALL use one of the following hash functions: SHA-1 (see [SHA1],
MD5 (see [MD5]), SHA256, SHA384, or SHA512 (see [SHA256] for the last
three). SHA-1 is default and the only mandatory to implement and support.""

Q.6) Reference: section 4.5 >> A problem that then MAY occur is to
synchronize the re-keying if an SPI is not used. <<

The general question related to MIKEY re-keying is how the new TEK is
synched-into the SRTP media stream? Some considerations should be given to
the following problems:

- What should sender and receiver do when the new TEK arrives too late?
(continue sending/ receiving, stopping/discarding, queuing).
- What should the receiver do when the sender already uses a new TEK but the
new TEK has not yet arrived at the receiver (the receiver might not even
expect a new TEK)?

The synchronization problem is also an issue for SRTP to address.

Q.7) Reference: section 5.1.1 and section A.10 >> The initiator tries to
guess the responder's capabilities in terms of security algorithms etc.<<

My understanding of the new draft is that the initiator actually is able to
indicate the used and applied security parameters as part of the conveyed
security profile payload. I would describe this method as security
parameter/profile indication rather than pure guessing.

If that is true, then it appears appropriate to refer to section A.10.

Q.8) Reference: section 5.1.2 >> The Initiator SHOULD therefore always be
prepared to receive such message back from the responder.<<
and section A.1 >> R: flag to indicate whether a response is expected or not
(this has only meaning when it is set by the Initiator).<<

From reading both parts together, a certain contradiction arises.

I guess the situation should be like this:

In case the Initiator has set the flag indicating an expected response, he
should be always be prepared to receive such message (error or V
confirmation message) back from the responder. Otherwise, when the flag was
not set, the initiator may expect a response (error message).

The other question is how long should the initiator wait for a potential
error message returned? And what should the initiator do, when the error
message arrives very late, such that the initiator started already sending
encrypted media streams (abort?)?

Q.9) Reference: section 5.2 >> Create a master payload starting...
Concatenate necessary payloads to the master payload...<<

I find the notion of master payload slightly confusing since it is not clear
if the master payload remains a master payload when adding payloads to it.
If the word "master" would be replaced by "MIKEY" the sense would be much
clearer.

Q.10) Reference: section 6.2 >> It is recommended to use the same identity
for both SIP and MIKEY.<<

Which SIP identity are you actually referring to?

Q.11) Reference: section 6.4 >> Therefore, the interface between MIKEY and
these protocols MUST provide certain functionality (however, exactly how the
interface looks like is very implementation dependent).<<

I believe that this section merely has the notion of an Application
Programming interface (API) in mind, rather than a protocol interface.

Q.12) Reference: section 7

This section currently does not describe peer-to-peer groups and the
application statement for the MIKEY key management protocols. A new section
9.3 could point out the use cases for the Diffie-Hellman protocol but also
the applicability of the other 2 protocols and the relation-ship with SIP
point-to-point sessions.

Q.13) Reference: section 8.6

It could be noted that MIKEY (and SRTP) does not provide any countermeasure
against untrusted receivers that are forwarding the decrypted media streams
to a 3rd party.

Q.14) Reference: section 12

It would be nice to separate out the references into normative ones and
informative ones as done in SRTP document.

Q.15) Reference: section A.1 >> MIKEY-1       |     0 | Mandatory, Default
(see Section 4.1.2-3.)<<

The referred section should probably be 4.2.1?

Q.16) Reference: section A.2 >> If the transport method used is the
pre-shared key method, this Key data transport payload MUST be the last
payload in the message (note that the Next payload field MUST be set to Last
payload).<<

Basically, a situation must be avoided in where a MIKEY message holds
several key management payloads one after the other. This does not make
sense at all and must be clearly deprecated and considered as an error.

More general, similar situations could arise where multiple other payloads
might occur in the message that are not defined to coexist according to this
draft.

Q.17) Reference: section A.7

The third table shows certificate types for X.509, X.509 URL, X.509 Sign and
X.509 Encr. It is not fully clear what those types actually refer to and
what the meaning is.

I could guess that the X.509 URL type would mean that the ID/Certificate
field holds an URL pointing to the X.509 certificate. If that is the
intention the question is, is this URL plain ASCII or somehow encoded (ISO
character set etc)?

Further, it is not specified in which encoding format to include the
certificate data (base64, plain octet string with ASN.1, ....)?

Thus some explanations appear necessary.

Q.18) Reference: section A.10.1 >> This policy specifies the policy for SRTP
and SRTCP. All defined transform applies to both SRTP and (if used) SRTCP.<<

It is my understanding that SRTCP authentication/integrity is always used;
thus, the sentence is a bit irritating.

Q.19) Reference: section A.10.1 >> TMMH-16       |     1 | Mandatory<<

My understanding of SRTP is that TMMH is not mandatory, it is just an
option.
For clarity, I recommend to add "2 word tag" in the comment column.

Q.20) Reference: section A.10.1 >> HMAC-SHA1     |     2 | Mandatory<<

Since this HMAC is actually a 32-bit truncated variant I would suggest
phrasing it as "HMAC-SHA1-32".

Q.21) Reference: section A.14 >> Note that for SRTP usage, the key validity
period for a PMK should be specified with either an interval, where the
VF/VT length is equal to 6 bytes, or with an SPI (in SRTP denoted as a
Master Key Identifier, MKI).<<

I guess that it is meant to include here the concatenated values of the
sequence number and the timestamp from the RTP header (SEQN || timestamp)? A
little more explanation might be useful thus.

Q.22) Reference: section Appendix B >> These messages may be included to
authenticate the error message. However, before the other peer has been
correctly authenticated, it is not recommended that the error messages are
sent authenticated (as this would open up for DoS attacks).<<

This is true. On the other hand, if error messages are not authenticated,
then DoS attacks become a risk as well where false error messages can be
injected! This is somehow a no-win situation unfortunately and I do not know
how to get out of this without any trade-off.

I'm looking forward to your response. In any way, we could discuss these
things at length also in Minneapolis...

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Fredrik Lindholm (ERA) [mailto:[email-masked]] 
Sent:	Tuesday, March 05, 2002 8:47 AM
To:	[email-masked]
Subject:	[MSEC] new MIKEY draft

The new version of MIKEY is now available. Please take a look at it. 
Questions and comments are very welcome.

http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-01.txt

Thanks,
Fredrik

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Mon, 11 Mar 2002 16:41:00 +0100

Hi, 

thanks for the thorough review. As you can see, we cut a few 
of your comments to be able to reduce the size of this message 
(you can assume that the answer/comment would be yes/ok/correct).  

> the mapping is not obvious.

We do not use the same terminology. As MIKEY is part of the 
MSEC architecture, we have also tried to align the terminology 
to this (see e.g. GKMARCH draft).

> MIKEY					SRTP
correct

> Multimedia crypto session (MCS)	RTP session ?
No.
MCS = A set of SRTP sessions (like the multimedia sessions 
in the RTP sense)

> Security Association (SA)		(MKI) ???

The Data SA is the input to the security protocol (in this 
case SRTP). It contains a TEK and the security protocol 
parameters. SRTP will use the TEK as its Master key. The 
MKI can be used by SRTP as an SPI to index the MIKEY PMK. 

The cryptographic context is an internal state in SRTP 
to store things like the current master key, replay lists, 
algorithms etc

> Re-key SA				???
No direct relation to SRTP. See e.g. GKMARCH.

> Pre-Master Key				master key
No, the PMK is used to derive one or more TEKs (i.e. SRTP 
Master keys). One TEK = Master key

> Traffic-encrypting key			session key/master key?
TEK = Master key in SRTP.

> Key Encryption key			???
No relation to SRTP (used for the Re-key SA, see above). 

> PMK re-keying				key derivation?
No relation to SRTP. 

> SPI					MKI
No. MKI is a pointer to the TEK only. 
The support of SPIs in MIKEY is for other security 
protocols or re-key protocols.

> TMMH-16				TMMH version 2/2 word tag
yes

not sure ;-)

> ascertain that the definitions are exactly identical.

We have chosen to harmonize MIKEY with the rest of the MSEC. 
So we will not use the same terminology. However, it looks 
like it might be a good idea to put a small "terminology relation"
section in the next version of MIKEY. 
 
> amount of protected information in the payloads.

Well, it is always good (and necessary) to have security protocols 
analyzed by several people (and not only by the authors).  

> synched-into the SRTP media stream? 

See SRTP for more information. But what is recommended is that SRTP uses 
the MKI (which is a pointer to the master key) or the SRTP index itself 
for the synchronization, but refer to SRTP. 

>Some considerations 
> should be given to
This is not a key management issue. This is something for the security 
protocol to worry about. MIKEY will not know what is "too late".

> new TEK has not yet arrived at the receiver (the receiver 
see above.

> The synchronization problem is also an issue for SRTP to address.
Indeed.

> (this has only meaning when it is set by the Initiator).<<

Response = Verification message 

> encrypted media streams (abort?)?

In the case of SIP, the error/response message (if any) must be sent 
back in the SIP response (it is not like the responder can wait with 
parsing of the message etc. and send back the result when he feels like it). 
If MIKEY is not used with SIP or RTSP then the reliability etc. should 
be handled according to Section 5.5. 

> Which SIP identity are you actually referring to?

The one used in the To/From field.

> thus, the sentence is a bit irritating.

Please read the disclaimer in MIKEY:
  "NOTE: SRTP was not finalized by the date for this draft's submission.
   Therefore, these parameters might be an issue for update!"

As the issue of whether SRTCP integrity protection should be mandatory 
or not was not set by the date of the MIKEY submission, this is one 
of the few inconsistencies that exist. 

> little more explanation might be useful thus.

No, the 6 bytes (48 bits) denotes the SRTP Index (i.e. ROC and seq nr). 

Many of your concerns were in relation to SRTP. As you know, SRTP is 
still a draft, which also have been changed. Therefore, some updating 
and fixing in MIKEY will be needed. However, SRTP is now in Last Call. 
After the LC we could probably expect SRTP be stable enough so that 
we can update the MIKEY draft.

Thanks, 

Fredrik & Elisabetta

---

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 11 Mar 2002 17:54:14 +0100

Fredrik and Elisabetta,

thanks a lot for your fast response. For all the cut issues may I safely
assume that you consider them as editorial and address them in a new draft
as appropriate?

I have two remarks as shown below.

With kind regards

Martin Euchner.

 -----Original Message-----
From: 	Fredrik Lindholm (ERA) [mailto:[email-masked]] 
Sent:	Monday, March 11, 2002 4:41 PM
To:	Euchner Martin  ICN M SR 3; [email-masked]
Cc:	[email-masked]'; Elisabetta Carrara (ERA); Karl Norrman
(ERA); Fredrik Lindholm (ERA)
Subject:	RE: [MSEC] new MIKEY draft - Questions and Comments

> the mapping is not obvious.

[...]

Meu:> I consider such explanation very helpful indeed, especially for those
readers who are not that familiar with MSEC group terminology but try to
understand the relationship how MIKEY terms maps to SRTP terms. I would
pretty much like to see that section to address the SRTP relationship of
terms addressed. I'm open as to whether that would appear in the MIKEY or in
the SRTP document finally.

> considered for MIKEY too!
MEU:> I consider this issue really serious. My stomach tells me that there
is an issue quite likely, but I would like to see this confirmed or
disproved however.

Thanks, 

Fredrik & Elisabetta

---

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Tue, 12 Mar 2002 16:16:48 +0100

Hi Martin,
 
yes

> is an issue quite likely, but I would like to see this confirmed or

Reflection attacks are typically used at challenge-response 
authentication protocols. Even *if* it would be possible to 
fool the initiator about the identity of the responder (which 
we don't think is possible, see below), the "bad guy" would 
still not end up with any secret information that could be 
used in any way that we see.

Let's assume a reflection attack on the pre-shared key method. 
What will happen?

Alice sends a new MIKEY message, M, to Bob. Carol intercepts 
the message M and initiates a new connection towards Alice. 
In a normal reflection attack, Carol tries to use the message 
in a way so that Alice will wrongly authenticate Carol as Bob. 
Note that the message M is integrity protected (where Alice 
and Bob uniquely define the key used for the MAC). The message 
will also contain the MCS ID and the timestamp. 

Alice will not accept the message M from Carol because:
  * if Alice own ID is in M, the authentication of the message 
    will fail as Alice probably don't share a secret with her 
    self (and even if she did, it should be different from the 
    secret shared with Bob).
  * even if Alice thinks the message is from Bob, extracting the 
    MCS ID, will make Alice to expect a verification or error 
    message from Bob (due to the internal state). Therefore, 
    Alice will not accept the message M. 

Let's get even more extreme. Assume that the implementation has 
a flaw, so Alice accepts the message M and creates a verification 
message V=MAC(auth_key,IDb||IDa||T). Alice sends V to Carol. 
However, Carol has no use of it. If Carol tries to send this back 
as a response to the message sent by Alice to Bob. Alice will not 
accept this as she expects MAC(auth_key,IDa||IDb||T) from Bob. 

Similar arguments apply to the PK and DH case.

Fredrik