> -----Original Message----- > From: Richard Barnes [mailto:[EMAIL PROTECTED] > Sent: Monday, May 19, 2008 9:04 AM > To: Eric Rescorla > Cc: Dan York; 'IETF SIP List'; 'Fries, Steffen (CT)'; Dan > Wing; 'Dean Willis' > Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05 > > With respect to the proposed text for R-CERTS, I agree with Dean that > this doesn't seem like a requirement on protocols, but on how > protocols > are operated. The set of trust anchors that peers choose is an > operating policy choice of those peers, not an issue of protocol.
It is possible to have a protocol without a trust anchor. MIKEY-PSK and ZRTP are two examples of protocols without trust anchors. -d > Perhaps you could put some operating recommendations in the > explanatory > section, but I don't think this issue belongs in the requirements for > the protocol. > > One minor technical issue with the explanatory text: Both > parties don't > need to trust the same trust anchor, but each peer has to > have a trust > anchor that can be used to validate the other. > > --RLB > > > > > Eric Rescorla wrote: > > At Tue, 13 May 2008 08:38:33 -0400, > > Dan York wrote: > >> Dan, > >> > >>> The wordsmithing task falls to me, I suppose. > >>> > >>> Here is another straw man, which I think captures your sentence > >>> above your signature and your [0] comment: > >>> > >>> R-CERTS: > >>> > >>> The media security key management protocol MUST NOT require > >>> using a trust anchor to validate credentials (e.g., a > >>> certificate) or to obtain credentials (e.g., a private key) > >>> used in the protocol. > >> Your wordsmithing is fine by me. I also liked the discussion you > >> included in section 4.9 which explains the rationale for this > >> requirement more. > >> > >> 4.9. Certificates > >> > >> The discussion in this section relates > to R-CERTS. > >> > >> On the Internet and on some private > networks, validating another > >> peer's certificate is often done > through a trust anchor -- a list of > >> Certificate Authorities that are > trusted. It can be difficult or > >> expensive for a peer to obtain these > certificates. In all cases, > >> both parties to the call would need to > trust the same trust anchor > >> (i.e., "certificate authority"). For > these reasons, it is important > >> that authentication mechanisms that > utilize trust anchors not rely > >> exclusively on such Certificate > Authority-issued certificates, but > >> to > >> also allow self-signed certificates. By > allowing the use of such > >> self-signed certificates, an > out-of-band mechanism (e.g., manual > >> configuration) can be used to trust a > peer's certificate. > > > > I was sort of OK with Dan's original text, though I > probably would have > > wordsmithed it differently, but I don't agree with this > discussion at all. > > Any certificate system can in principle be used with > self-signed certs > > by doing SSH-style fingerprint exchange. The question is > whether there > > is a practical deployment model that actually supports this. > > > > > > Consider two examples, both using TLS: > > > > - HTTPS in the majority of cases is incompatible with > manual establishment > > of peer credentials. You connect to a lot of different > Web servers and > > it's not practical to obtain their certificates out of band. > > - IMAP over TLS is compatible with manual establishment of > peer credentials > > because you connect with only one or two servers and you > already share > > a shared secret (the password) so it's at least in > principle possible > > to record their cert fingerprint. This is also why SSH works. > > > > So, this isn't fundamentally an issue of protocol encoding > (as Richard > > has observed) but rather of the context in which the > protocol is embedded. > > > > > > So, I would rewrite this section as follows: > > > > On the Internet and on some private networks, > validating another > > peer's certificate is often done through a trust > anchor -- a list > > of Certificate Authorities that are trusted. It can be > difficult > > or expensive for a peer to obtain these certificates. In all > > cases, both parties to the call would need to trust the same > > trust anchor (i.e., "certificate authority"). For > these reasons, > > it is important that the media plane key management protocol > > offer a mechanism that allows end-users who have no prior > > association to authenticate to each other without acquiring > > credentials from a third party trust point. Note that this does > > not rule out mechanisms in which servers have certificates and > > attest to the identities of end-users. > > > > And since I'm in the writing business, I would adjust > R-CERTS as follows: > > > > The media security key management protocol MUST NOT require > > that end-users obtain credentials (certificates or private > > keys) from a third-party trust anchor. > > > > -Ekr > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
