<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'>I am looking at the “Pre-shared key” specs in RFC 4279, and in particular at the privacy issues inherent with pre-shared key. According to 4279, the client sends to the server a “key identity” so the server understands which shared key to use in the exchange. The problem of course is that by doing so the client reveals its own identity in a clear text message. This is dutifully flagged in the security considerations, but no mitigation is proposed.<o:p></o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'><o:p> </o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'>I can think of two kinds of mitigations. The first one is to encrypt the key identity with a server provided key. The problem is that this is a bit circular, as the server has to identity that identity encryption key. Also, privacy is only achieved if the server key is shared with multiple clients, but then it falls into the “widely known secret” category. <o:p></o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'><o:p> </o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'>The second one is to replace the key identity by a puzzle, e.g. a nonce and the hash of the nonce and the shared key. The server tries many shared keys until one is found to match, thus identifying the client with which the key was shared. Bluetooth LE does a variation of that. The problem of course is that the server load increases linearly with the number of clients, which may be OK with small Bluetooth devices paired with a small number of peers, but not so OK for medium to large servers.<o:p></o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'><o:p> </o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'>Do you know a better way?<o:p></o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'><o:p> </o:p></span></font></p><p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt'>-- Christian Huitema<o:p></o:p></span></font></p><p class=MsoNormal><font size=3 face=Calibri><span style='font-size:12.0pt'><o:p> </o:p></span></font></p><p class=MsoNormal><b><font size=3 face=Calibri><span style='font-size:12.0pt;font-weight:bold'><o:p> </o:p></span></font></b></p></div></body></html>