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

[Gonzalo Camarillo <[e-mail]>]

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

Francois Audet wrote:

> 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:[e-mail]]
>  > Sent: Saturday, January 15, 2005 00:41
>  > To: Audet, Francois [SC100:9T51:EXCH]
>  > Cc: '[e-mail]'; '[e-mail]';
>  > '[e-mail]'; '[e-mail]';
>  > '[e-mail]'
>  > 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
>  > > [e-mail]
>  > > https://www1.ietf.org/mailman/listinfo/mmusic
>  >
>  > --
>  > Gonzalo Camarillo         Phone :  [phone]
>  > Oy L M Ericsson Ab        Mobile:  [phone]
>  > Telecom R&D               Fax   :  [phone]
>  > FIN-02420 Jorvas          Email :  [e-mail]
>  > Finland                   http://www.hut.fi/~gonzalo
>  >
>  >
>  >
> 

-- 
Gonzalo Camarillo         Phone :  [phone]
Oy L M Ericsson Ab        Mobile:  [phone]
Telecom R&D               Fax   :  [phone]
FIN-02420 Jorvas          Email :  [e-mail]
Finland                   http://www.hut.fi/~gonzalo


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