Re: [martini] review of draft-ietf-martini-reqs-07.txt

[Gonzalo Camarillo <[e-mail]>]

Hi,

thanks for addressing the IETF LC comments with the new revision of the
draft. I have put it on the agenda of the IESG telechat on July 15th.

Authors, please be responsive when you start receiving comments from the
ADs reviewing the document.

Cheers,

Gonzalo

On 27/06/2010 9:45 PM, Bernard Aboba wrote:
> I have opened Ticket #46 for this.  So far, I believe this is the only
> IETF last call comment.
> 
>> Date: Sat, 26 Jun 2010 19:25:45 +0300
>> From: [e-mail]
>> To: [e-mail]
>> CC: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: review of draft-ietf-martini-reqs-07.txt
>>
>> Hi John,
>>
>> please, agree with Hilarie on how to address these comments and submit a
>> new revision of the draft. Please, also include any other IETF LC
>> comments you have received.
>>
>> I have updated the draft's state in the tracker to Revised ID Needed.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> On 22/06/2010 9:43 AM, Elwell, John wrote:
>> > Hilarie,
>> >
>> > Thanks for your review. See responses below:
>> >
>> >> -----Original Message-----
>> >> From: [e-mail]
>> >> [mailto:[e-mail]] On Behalf Of Hilarie Orman
>> >> Sent: 22 June 2010 02:49
>> >> To: [e-mail]
>> >> Cc: [e-mail]; [e-mail];
>> >> [e-mail]; [e-mail]; Elwell,
>> >> John; [e-mail]
>> >> Subject: review of draft-ietf-martini-reqs-07.txt
>> >>
>> >> Security review of draft-ietf-martini-reqs-07.txt,
>> >> Multiple AOR reachability in SIP
>> >>
>> >> Do not be alarmed. 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.
>> >>
>> >> The abstract:
>> >> This document states requirements for a standardized SIP registration
>> >> mechanism for multiple addresses of record, the mechanism being
>> >> suitable for deployment by SIP service providers on a large scale in
>> >> support of small to medium sized Private Branch Exchanges (PBXs).
>> >> The requirements are for a solution that can, as a minimum, support
>> >> AORs based on E.164 numbers.
>> >>
>> >> There are 21 requirements, and two of them address security.
>> >>
>> >> I think requirement 14 leaves out a couple of things:
>> >> REQ14 - The mechanism MUST be able to operate over a transport that
>> >> provides integrity protection and confidentiality.
>> >> It should probably require "end-to-end" integrity protection and
>> >> confidentiality between the two entities (SIP-PBX and the SSP).
>> > [JRE] In the next version I will change it to:
>> > "The mechanism MUST be able to operate over a transport that
> provides end-to-end integrity protection and confidentiality between the
> SIP-PBX and the SSP."
>> >
>> >>
>> >> And I think requirement 15 should say something about how the two
>> >> entites are expected to agree on an authentication method, and that
>> >> the authentication should apply to every registration message
>> >> exchanged by the entities. That is, once they have authenticated,
>> >> then that information should be tied to requirement 14 and ensure that
>> >> the integrity and/or confidentiality is defined between the two
>> >> entities (by use of, for example, an authenticated key exchange
>> >> protocol) on all subsequent messages between the two.
>> > [JRE] I am reluctant to make any changes here. We don't anticipate
> any new security mechanism, and indeed the solution that is moving
> forward in the WG allows use of TLS, which is already allowed for in
> SIP. For authentication it allows both TLS mutual authentication or SIP
> digest authentication + TLS server authentication, again, in line with
> what is already allowed in SIP. SIP has a wealth of material in this
> area, including aspects of RFC 3263 and RFC 3329. I don't think it
> worthwhile adding a bunch of requirements that in the end will not lead
> to any new mechanisms or influence use of existing mechanisms. REQ14 and
> REQ15 I think are sufficient pointers to needs in this area.
>> >
>> >> REQ15 - The mechanism MUST support authentication of the SIP-PBX by
>> >> the SSP and vice versa.
>> >> I'd also add that it MUST support termination of authenticaton and
>> >> re-authentication.
>> > [JRE] I am not sure exactly what you are looking for here. Is this
> referring to what happens when a certificate expires, say? Again, I
> would doubt we really need to add anything here, since we don't
> anticipate new security mechanisms.
>> >
>> >>
>> >> Minor non-security things:
>> >>
>> >> Requirement 4 has a triple negative ("not" "prevent" "without"), and
>> >> I'm not sure what the heck it means.
>> > [JRE] Yes, in the next version I will change it to:
>> > "The mechanism MUST allow UAs attached to a SIP-PBX to register with
> the SIP-PBX for AORs based on assigned telephone numbers, in order to
> receive requests targeted at those telephone numbers, without needing to
> involve the SSP in the registration process."
>> >
>> >>
>> >> Requirement 5 has a typo, probably "internally" for "internal".
>> > [JRE] It intentionally says "internally" at present - an adverb
> modifying the verb "handle". I am not sure how to reword it to prevent
> misinterpretation.
>> >
>> > John
>> >
>> >
>> >>
>> >> Hilarie
>>