-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/15/2011 02:11 AM, Marc Petit-Huguenin wrote: > No response to this review, but I have an additional comment on this draft: > > 11. Section 3 > > "Note that these rules permit Alice to forward calls to Bob without > his permission. However, they do not permit Alice to forward Bob's > calls to her." > > One way to allow Alice to forward Bob's calls to her (or someone else) in a > secure way is to use the access control policy defined in > draft-knauf-p2psip-share. With -sip-06, only the owner of the certificate can > store a SIP-REGISTRATION, that we can represent like this: > > Resource Kind Node-ID URI signer > [email protected]>0x12345678--->sip:[email protected] [email protected] > > What Share can bring here is the possibility to have an authorized third-party > modifying the SIP registration: > > Resource Kind Node-ID URI signer > [email protected]>0x12345678--->sip:[email protected] [email protected] > > Resource Kind Index ACL signer > [email protected]>0x56780001-->[email protected] 1001 true [email protected] > [email protected]>0x56780002-->[email protected] 1001 false [email protected] > > Here Bob (the boss) delegates to Alice (his assistant[1]) the right to modify > its registration, so Alice can now change it: > > Resource Kind Node-ID URI signer > [email protected]>0x12345678--->sip:[email protected] [email protected] > > One problem is that we cannot reuse the Kind 1 (SIP), because it is already > bound to USER-NODE-MATCH, so we have to create a new kind (1001) that is bound > to USER-CHAIN-ACL. Unfortunately I do not see an easy solution to use the > original Kind (1) with USER-CHAIN-ACL. > > I would suggest to add an informative reference to draft-p2psip-knauf-share, > and
I meant "add an informative reference in draft-ietf-p2psip-sip to draft-knauf-p2psip-share". > to add a similar example in an appendix. > > > [1] For the record, the example I sent to the Share authors had Alice as the > boss, and Bob as her assistant, but I had to invert the example to match the > text in -sip. > > On 08/16/2011 08:23 AM, Marc Petit-Huguenin wrote: >> 1. Section 3: SipRegistration structure >> >> I would suggest to use "SipRegistration Resource Record" instead, to match >> the >> terminology in -concepts. >> >> Same thing for SipRegistration PDU in the same section. >> >> >> 2. Section 3: 1st paragraph >> >> s/This uses the SIP-REGISTRATION Kind-ID/This uses the SIP-REGISTRATION Kind/ >> >> >> 3. Section 3: opaque contact_prefs<0..2^16-1>; >> >> The format of the contact_prefs field is not described. Is it RFC 3840 or >> RFC >> 2533 (better in my opinion) or something else? >> >> >> 4. Section 3: Destination destination_list<0..2^16-1>; >> >> I think it would be better to have a list of destination_list instead, to be >> able to register different paths to the destination. This could be useful >> if a >> node decides to register as a client to multiple peers, using the procedure >> in >> the second bullet of section 3.2.1 of -base. >> >> >> 5. Section 3, second bullet of last list. >> >> It says that the storing peer must check that "[t]he certificate contains a >> Node-ID that is the same as the dictionary key it is being stored at.", >> which is >> not exactly true when the certificate contains multiple Node-ID. It would be >> better to say: >> >> "The Node-ID of the signer is the same as the dictionary key it is being >> stored at." >> >> >> 6. Section 4, first item in list >> >> "Check to see if the domain part of the AOR matches the domain name of an >> overlay of which he is a member." >> >> The way I understand this sentence, the "sip:[email protected]" AOR >> matches an overlay named "overlay.implementers.org". Was that the intent of >> this rule, or was the intent that the "sip:[email protected]" AOR >> only >> matches the "implementers.org" overlay? >> >> >> 7. Section 5. >> >> "If certificate-based authentication is in use, the responding peer MUST >> present >> a certificate with a Node-ID matching the terminal entry in the route list." >> >> If this sentence is about the AppAttach itself (and not about the connection >> created by the AppAttach), isn't that rule already part of -base? >> >> >> 8. Section 6. Second sentence. >> >> I do not understand what this sentence means. >> >> >> 9. Section 8.1. "In this section we discuss security issues that are likely >> to >> be relevant to any usage of RELOAD." >> >> There is no security issues discussed in section 8.1. >> >> >> 10. Section 9 >> >> Please change "TBD" by the code point that was already assigned (1, I >> think), so >> early implementations can do interoperability testing. >> >> >> Nits >> ==== >> >> - Abstract >> >> s/(RELOAD),/(RELOAD)./ >> >> - Section 2 >> >> s/consiered/considered/ >> > - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7Br/gACgkQ9RoMZyVa61fCTgCfQqApyrWerSBJV55zmG/svCRi zi0An33Zv3DsWywaChy+fWXNQz7aWi68 =L0Lf -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
