Re: [secdir] Secdir review of draft-mattsson-mikey-ticket-02

[John Mattsson <[e-mail]>]

Dear Tobias,

Many thanks for the review. I'll update the draft based on your comments.

Best Regards,
John


-----Original Message-----
From: Tobias Gondrom [mailto:[e-mail]] 
Sent: den 18 mars 2010 23:03
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; John Mattsson; [e-mail]
Subject: Secdir review of draft-mattsson-mikey-ticket-02


> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> 0. From the security perspective, the considerations in this document
> appear to be overall sufficient.
> 
> 1. COMMENT: Intended Status
> I am not quite sure why this draft status is planned to be informational. It
> adds new protocol specification, which by my understanding should not be done
> in an informational draft. I can see why it was not aimed for standards track
> but the intended status "experimental" would seem more appropriate to me. 

I'm no expert at statuses but having it informal is in line with some other 3GPP related RFCs like EAP-SIM and EAP-AKA.

> 2. COMMENT: 
> Spelling: 
> s/5.4.  Error Handling If an error occurs, the message SHOULD be discarded and
> the the error SHOULD be reported with an error message./ 5.4.  Error Handling
> If an error occurs, the message SHOULD be discarded and the error SHOULD be
> reported with an error message.

Yes

> 3. COMMENT: section 10: 
> s/New Ticket Types SHOULD not change/New Ticket Types SHOULD NOT change
> (for rfc2119 consistent language use)

Yes

> 4. COMMENT: section 6.7.  Cert Hash Payload (CHASH) "Hash func (8 bits):
> besides the algorithms already defined in [RFC3830], this specification
> defines that the following hash function algorithm may be used.
>  SHA-256   | TBD20 |                256"
> Why do you add SHA-256 but no other hash algorithms (i.e. SHA-512/ripemd),
> how do you intend to provide for hash agility?

This seems more like a question for MIKEY in general than for the MIKEY-TICKET draft. 

> 5. COMMENT: section 8. Pre-Encrypted Content "The default setting is that the KMS
> supplies the session keys (encoded in the ticket). This is not possible if the content
> is pre-encrypted (e.g.  Video on Demand). In such use cases, the key exchange is
> typically reversed and MAY be carried out as follows. The Initiator sends a ticket
> without encoded session keys to the Responder in a TRANSFER_INIT message. The
> Responder includes the TEKs used to protect the requested content in the TRANSFER_RESP
> message, which is sent to the Initiator."
> 
> I wonder whether the pre-step of "initiator sends a ticket without encoded session key" 
> allows a potential DoS vulnerability with request flooding, when it may trigger calculations
> at the Responder or KMS. 
> Would it be necessary to mention this risk in the Security Section 12.2. as well?

I do not see how "ticket without encoded session key" makes any difference? I feel that this is already covered in Section 12.2: "Since the Responder in general cannot verify the validity of a TRANSFER_INIT message without first contacting the KMS, Denial of Service may be launched against the Responder and/or the KMS via the Responder." 

> 6. COMMENT: section 10. Signaling Between Different KMSs paragraph 1: "signaling
> between them SHALL be integrity protected."
> I understand and fully agree that you require integrity protection, but why do
> you not need confidentiality protected, too?

Yes, it should be fully protected. I'll update the draft.

> 7. COMMENT: section 12.4.  Forking
> "To prevent all forms of eavesdropping, only the endpoint that answers should
> get access to the session keys."
> From my perspective the use of RFC2119 "SHOULD" would be more appropriate here? 

Yes I agree.

> Best regards, Tobias
> 
> Ps.: I cc'ed the WGChairs of msec to this review as MIKEY got originated there.