Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt

From: "Francois Audet" <[email-masked]>
Date: Tue, 18 Jan 2005 20:17:08 -0500

Thank you Gonzalo!

I agree with what you are saying as a way around the HERPF problem for
keymgmt. This is what I had in mind.

As Gonzalo describes, we need to accept the offer (even if we are
rejecting the keymgmt) instead of sending the 488.

The answerer would send a provisional response (e.g., 183) with the 
SDP-Answer. In the SDP-Answer, the a=key-mgmt:mikey attribute is included, 
but instead of the keying material, I would assume it would have the 
rejection. For example, I would assume that a proper value in the MIKEY
error 
payload (ERR) for that purpose already exists.

After that, the keying information can be renegotiated using additionnal
offer/answer cycles (I think UPDATE/re-INVITE would be appropriate).

In other words, 488 is rejecting the session completely. But to reject
just the keymgmt (and keep the session) you would reject explicitly 
the keymgmt using the native keymgmt procedures (e.g., MIKEY).

This would be a small change to kmgmt section 3.1.2. 

I don't think there are any other alternatives. Waiting for a general 
solution to the HERPF problem does not seem acceptable to me, because
it won't be backward compatible and because it may take a very long
time. Also, to me it seems logical that we accept the Offer, but reject the 
key. It really should be the same dialog, but with additional MIKEY
interactions.
It really emphases the strenght of MIKEY as a key management protocol. 

Let me know if you think this is a good idea. I can certainly help with the
wording.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Saturday, January 15, 2005 00:41
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]'; [email-masked]'; 
> [email-masked]'
> Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt
> 
> 
> Hi,
> 
> Francois is right in pointing out that there is a known 
> problem with SIP 
> forking referred to as HERFP (Heterogeneous Error Response Forking 
> Problem). RFC 3326 refers to it in its abstract.
> 
> We never got around to resolving this issue. However, as Francois 
> suggests, there could be ways around it. If both UAs support 
> 100rel the 
> offer can be accepted in a provisional (e.g., 183) response. Further 
> negotiations could be carried out using PRACKs, and when the key 
> management procedure completed, the UAS could finally accept 
> the session 
> with a 200 OK response for the INVITE.
> 
> UAs that do not suppor 100rel would need to use a 200 OK or live with 
> the HERFP, as Francois pointed out.
> 
> Regards,
> 
> Gonzalo
> 
> 
> 
> Francois Audet wrote:
> 
> > Hi,
> > 
> > I have a 2 comments on 
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-12.txt
> > .
> > 
> > 
> > This first comment is for a clarification:
> > 
> > - Section 3.1.2 explains that SIP 488 is used for rejecting a key
> > management offer.
> >   488 allows for the inclusion of an SDP indicating the 
> capabilities of the
> >   answerer (the same way an SDP in a 200 OK sent in an 
> OPTIONS request 
> > indicates
> >   capabilities). It would be desireable to explain how this 
> works with
> >   kmgmt. I assume that this is what is meant by wording 
> saying "Further 
> > details
> >   about the cause of failure MAY be described in an 
> included message 
> > from the key
> >   management protocol." Perhaps a wording like the 
> following would help:
> > 
> >         Further details about the media capabilities of the offerer 
> > MAY
> > be in
> >         included in 488 according to normal RFC 3261 rules. Further 
> > details about
> >         the cause of the rejection of the key message itself MAY be 
> > described in
> >       the key message in the SDP in the 488, according to the rules
> >         of the key management protocol. The session is then ...
> > 
> >  ...or something along those lines.
> > 
> >  It would also be worthwile to describe how this relates to 
> MIKEY in  
> > particular (i.e, that the MIKEY message itself in the key-mgmt may 
> > have  the key management rejection reason). It would also 
> be helpful 
> > to have  an Example of a failure case for SIP 488/MIKEY.
> >  
> > -----------------------
> > 
> > This next comment is concerning a potential issue with SIP forking. 
> > I'm not sure we can fix it in MMUSIC, but I'll state it anyways.
> > 
> > - There is a somewhat unpleasant side-effect of using a SIP failure
> > response
> >   for rejecting a key management message.
> > 
> > - Suppose that there is a SIP forking proxy forking the 
> offer (in the
> > INVITE).
> >   Let's say the call is forked to A and B. A is a device 
> for which no
> >   user is present at the time (say, an office phone). 
> Suppose A rejects the
> >   call with 401 Unauthorized because it needs 
> authorization. Suppose the 
> > user
> >   is at home (B), but rejects the offer with 488 (because 
> it's using the 
> > key
> >   management protocol used for the corporation which is 
> different than 
> > the one
> >   used at home). The forking proxy will see both the 401 an 
> the 488, but 
> > can only
> >   forward one to the offerer. There is nothing saying which 
> one should 
> > be forwarded
> >   beyong the error response that indicates that there could be 
> > retransmission (which
> >   applies to both codes in this case). Worst, in this particular 
> > example, if the proxy
> >   follows the rule section 6/RFC 3261, chances are it will 
> pick 401. 
> > This means
> >   that you won't be able to call home because you'll never 
> receive a 488.
> > 
> > - This is a weakness of the forking procedures in SIP, and 
> perhaps it
> > should be
> >   addresses in the SIP working group.
> > 
> > - The other alternative would be to not consider the 
> rejection of the
> > key as a
> >   rejection of the offer. Instead of sending a 488, you 
> would accept the
> >   offer with an answer, and the key rejection would be 
> included in the 
> > key message
> >   itself (which could then trigger another offer/answer). In other 
> > words, the
> >   offer/answer is sucessful, but the key exchanged is not. 
> This would 
> > have the obvious
> >   advantage of the previous scenario working properly. 
> However, if there 
> > is no
> >   suitable key management protocol, we could run into the reverse 
> > problem (when the
> >   user is at work (A) instead of (B). In this case, the proxy would 
> > forward the
> >   200 with the answer with the key message, and drop the 401. There 
> > would be another
> >   offer/answer round which would then fail. The caller in this case 
> > would never get
> >   the 401.
> > 
> > I'm not sure how to deal with this forking issue.
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
> 
> 
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Jan 2005 09:01:06 +0200

Hi,

additionally, the authors of this draft may want to have a look at the 
security preconditions draft:
http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-securityprecondition-02.txt

This type of precondition keeps the callee from being alerted until the 
crypto stuff is ready.

Regards,

Gonzalo