Re: [Sip] draft-ietf-sip-media-security-requirements-05

["Elwell, John" <john.elwell at siemens.com>]

Ekr,

Yes, I too was getting a little bit uncomfortable with saying you don't
need a trust anchor, because without some trust anchor (at least for the
server) authentication isn't achievable. So I like your proposed words.

John

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of Eric Rescorla
> Sent: 13 May 2008 18:15
> To: Dan York
> Cc: 'IETF SIP List'; Fries, Steffen (CT); Dan Wing; 'Dean Willis'
> Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05
> 
> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip