Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.

From: Fries Steffen <[email-masked]>
Date: Mon, 11 Apr 2005 08:55:08 +0200

Hi Elisabetta,

recently a question came up in the usage of the key management extentions
for SIP to use MIKEY:

Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains the following
statement: 

"If the key management rejects the offer and the session needs to be
aborted, the answerer SHOULD return a "488 Not Acceptable Here" message,
optionally also including one or more Warning headers (a 306 "Attribute not
understood" when one of the parameters is not supported, and a 399
"Miscellaneous warning" with arbitrary information to be presented to a
human user or logged, see Section 20.43 in [SIP]). Further details about the
cause of failure MAY be described in an included message from the key
management protocol. The session is then aborted (and it is up to local
policy or end user to decide how to continue)."

Concerning the sentence in bold (The sentence before the last sentence in
quotes), how does it do that in the following scenario?:
A UA receives an INVITE request containing an SDP offer with a MIKEY
I_MESSAGE that is for some reason unacceptable. The receiving UA will return
a 488 response, which does not contain an SDP answer. Therefore there is no
way of embedding a MIKEY R_MESSAGE to indicate the error. Is there any way
to signla the MIKEY error in this case?

Regards
	Steffen

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Fries Steffen <[email-masked]>
Date: Tue, 12 Apr 2005 12:21:04 +0200

Hi Karl,

thank you for the answer. Does it mean you should send the MIKEY container
even if you don't want to change any of the parameter?

To my other question, does the "no" mean, the receiver of the 488 has to
interpret it in some way?

Regards
	Steffen 

> -----Original Message-----
> From: Karl Norrman (KI/EAB) [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2005 11:59 AM
> To: Fries Steffen
> Cc: Elisabetta Carrara (AL/EAB); [email-masked]
> Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.
> 
> Hello!
> 
> As we understand the offer/answer model (rfc3264), you should 
> keep the parameters that you do not wish to change constant 
> in the re-INVITE. So we also assume that if you try to comply 
> to the offer/answer model, you will include the MIKEY 
> parameter, but "ignore" it at the receiver during the SDP 
> processing as it has not been changed.
> 
> Regarding your question in your previous mail, the answer is no.
> 
> Regards,
> MIKEY-people
> 
> > ---------------------------- Original Message
> > ----------------------------
> > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.
> > From:    "Fries Steffen" <[email-masked]>
> > Date:    Mon, April 11, 2005 8:55 am
> > To:      [email-masked]
> > Cc:      [email-masked]
> > --------------------------------------------------------------
> > ------------
> > 
> > Hi Elisabetta,
> > 
> > recently a question came up in the usage of the key management 
> > extentions for SIP to use MIKEY:
> > 
> > aborted, the answerer SHOULD return a "488 Not Acceptable Here" 
> > message, optionally also including one or more Warning 
> headers (a 306 
> > "Attribute not understood" when one of the parameters is not 
> > supported, and a 399 "Miscellaneous warning" with arbitrary 
> > information to be presented to a human user or logged, see Section 
> > 20.43 in [SIP]). Further details about the cause of failure MAY be 
> > described in an included message from the key management 
> protocol. The 
> > session is then aborted (and it is up to local policy or 
> end user to 
> > decide how to continue)."
> > 
> > Concerning the sentence in bold (The sentence before the 
> last sentence 
> > in quotes), how does it do that in the following scenario?:
> > I_MESSAGE that is for some reason unacceptable. The 
> receiving UA will 
> > return a 488 response, which does not contain an SDP 
> answer. Therefore 
> > there is no way of embedding a MIKEY R_MESSAGE to indicate 
> the error. 
> > Is there any way to signla the MIKEY error in this case?
> > 
> > Regards
> > 	Steffen
> > 
> >

---

From: "Karl Norrman \(KI/EAB\)" <[email-masked]>
Date: Tue, 12 Apr 2005 11:58:57 +0200

Hello!

As we understand the offer/answer model (rfc3264), you should 
keep the parameters that you do not wish to change constant in the
re-INVITE. So we also assume that if you try to comply to the 
offer/answer model, you will include the MIKEY parameter, but 
"ignore" it at the receiver during the SDP processing as it has
not been changed.

Regards,
MIKEY-people

> optionally also including one or more Warning headers (a 306 
> "Attribute
> not understood" when one of the parameters is not supported, and a 399
> human user or logged, see Section 20.43 in [SIP]). Further 
> details about
> the cause of failure MAY be described in an included message 
> from the key
> I_MESSAGE that is for some reason unacceptable. The receiving UA will
> return a 488 response, which does not contain an SDP answer. Therefore
> the error. Is
> there any way to signla the MIKEY error in this case?
> 
> Regards
> 	Steffen
> 
>

---

From: "Karl Norrman \(KI/EAB\)" <[email-masked]>
Date: Tue, 12 Apr 2005 14:13:24 +0200

Hello!

> From: Fries Steffen [mailto:[email-masked]]
> Sent: den 12 april 2005 12:21
> To: Karl Norrman (KI/EAB)

Yes.

> interpret it in some way?

That is up to the local policy.

Regards,
Karl

---

From: Fries Steffen <[email-masked]>
Date: Thu, 14 Apr 2005 08:25:53 +0200

Hi Karl,

by thinking about your anwer, there are still open questions for me. 

> processing as it has not been changed.

[stf] At the first glimpse this would mean that a sender of a MIKEY message
should store the MIKEY container in some place for later reuse, but this is
not really possible as parameter like timestamp and maybe RAND. Those may
need to change (otherwise, how could you detect replay?). From that point of
view the receiver of the MIKEY message needs to process the MIKEY container
in any case. 
Would'nt it be more efficient to not sent the MIKEY container if non of the
cryptographic context parameter has changed? This would save the processing
at sender and receiver and also bandwidth.

Regards
	Steffen

---

From: "Karl Norrman \(KI/EAB\)" <[email-masked]>
Date: Thu, 14 Apr 2005 09:02:18 +0200

Hello!

See inline...

> Sent: den 14 april 2005 08:26

If exactly the same container is sent in the response (without changing it), 
then the function processing SDP as such would not even bother to 
send the vale to the MIKEY implementation as it is one of the parameters that hasn't 
been changed and shouldn't be processed (according to the offer/answer 
model).

> at sender and receiver and also bandwidth.

Yes, it is more effective to not send the MIKEY data
in the response.  However, this *has* to be done to
comply to the offer/answer model, as we understand it.

Regards,
Karl