Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

From: "Cedric Aoun"<[email-masked]>
Date: Thu, 9 May 2002 10:10:53 +0100

why do we need the download of the shared secret to happen within the STUN
protocol?
The main thing is to have the shared secret but not how we get it (TLS, from
a manual, human interaction, secured personalized content web pages ....).
Cedric
-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: 09 May 2002 00:33
To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore; [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

I believe that using a pre-existing shared secret in STUN is very unsafe. We
must have a procedure within STUN to download a secret. Without a safe way
to download the secret, then I would rather stick with the current text,
i.e. CMS.
 
-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]] 
Sent: Wednesday, May 08, 2002 2:35 PM
To: 'Melinda Shore'; [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN
 
I just meant "shared secret". Whether it is statically provisioned or
dynamically generated/downloaded is, IMO, outside the scope of STUN. I would
prefer not to use STUN to download a shared secret. 
What I meant was if we agree on the shared secret part and on a
challenge/response mechanism to do authentication, then the relevant
attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. This
work can be progressed independent of the shared secret provisioning
mechanism. 
Thanks, 
Sanjoy 
 
> -----Original Message----- 
> From: Melinda Shore [mailto:[email-masked]] 
> Sent: Wednesday, May 08, 2002 3:51 PM 
> To: Sen, Sanjoy [NGC:B692:EXCH]; [email-masked] 
> Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN 
> 
> 
> At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote: 
> >Do we've a rough consensus on moving forward with the shared 
> security approach for STUN? 
> 
> No (if what you mean by "shared security" is pre-provisioned symmetric 
> keys). 
> 
> Melinda 
> 
>

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 10 May 2002 10:04:22 +0100

RE: [midcom] WGLC - Alternatives for 'securing' STUNTo ease implementation, would it be possible to wrap the server's public key in an HTTP wrapper.  That way the server's side of the operation could be done by deploying Apache or IIS listening on the STUN port.  The URL could simply be /.  This should be easy for most ISPs to deploy.

On the client side, worst case the user can manually enter the STUN URL (https://stun-servers.com:3478) into a standard web browser, read the base64 encoded key that comes back (probably as text/plain?) and type it into their client.  Some standalone phones have HTTP configuration.  This would allow a copy and paste operation to be used.  Best case would of course be for the actual client to do the HTTP request.

Such a strategy would seem to be easy to deploy, and shouldn't be too difficult for the user to do.  It also doesn't hinder slicker implementations.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

  ----- Original Message ----- 
  From: Cedric Aoun 
  To: 'Christian Huitema' ; Sanjoy Sen ; Melinda Shore ; [email-masked] 
  Sent: 09 May 2002 10:10
  Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

  why do we need the download of the shared secret to happen within the STUN protocol? 
  The main thing is to have the shared secret but not how we get it (TLS, from a manual, human interaction, secured personalized content web pages ....).

  Cedric 
  -----Original Message----- 
  From: Christian Huitema [mailto:[email-masked]] 
  Sent: 09 May 2002 00:33 
  To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore; [email-masked] 
  Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN 

  I believe that using a pre-existing shared secret in STUN is very unsafe. We must have a procedure within STUN to download a secret. Without a safe way to download the secret, then I would rather stick with the current text, i.e. CMS.

  -----Original Message----- 
  From: Sanjoy Sen [mailto:[email-masked]] 
  Sent: Wednesday, May 08, 2002 2:35 PM 
  To: 'Melinda Shore'; [email-masked] 
  Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN 
    
  I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I would prefer not to use STUN to download a shared secret. 

  What I meant was if we agree on the shared secret part and on a challenge/response mechanism to do authentication, then the relevant attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. This work can be progressed independent of the shared secret provisioning mechanism. 

  Thanks, 
  Sanjoy