Date: Sat, 25 Jan 2014 07:18:03 -0800 (PST)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "Alan Johnston" <alan.b.johnston@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <CAKhHsXFm1tRCPw2OUmP_QkBsu9ia1fhRrY1o_c9q8fjT8u10EQ@mail.gmail.com>
References: <1369961279.70598635@apps.rackspace.com>
 <CAKhHsXFm1tRCPw2OUmP_QkBsu9ia1fhRrY1o_c9q8fjT8u10EQ@mail.gmail.com>
Message-ID: <1390663083.06483927@apps.rackspace.com>
Cc: draft-ietf-cuss-sip-uui.all@tools.ietf.org,
 "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-cuss-sip-uui-10
Precedence: list

Hi Alan,=0A=0AIt appears that the modifications answer the questions I rais=
ed, but I again want to emphasize my lack of experience with SIP. One nit w=
ith the second paragraph of the security considerations section - it says =
=0A=0A   One model treats the SIP layer as untrusted and requires end-to-en=
d=0A   integrity protection and/or encryption.  This model can be achieved=
=0A   by providing these security services at a layer above SIP.  In this=
=0A   case, applications are encouraged to use their own integrity=0A   mec=
hanisms such as encrypting the UUI data before passing it to the=0A   SIP l=
ayer.=0A=0AEncryption is not an integrity mechanism. One way to fix this wo=
uld be to change that last sentence to something like =0A=0A   In this case=
, applications are encouraged to use their own integrity=0A   and/or encryp=
tion mechanisms.=0A=0AThanks,=0A=0AScott=0A=0AOn Thursday, January 23, 2014=
 11:44am, "Alan Johnston" <alan.b.johnston@gmail.com> said:=0A=0A> Scott,=
=0A> =0A> Thanks for your review of the draft.  We made some edits based on=
 your=0A> comments a while back, so I'm pinging you to make sure they addre=
ss your=0A> concerns.=0A> =0A>      http://tools.ietf.org/html/draft-ietf-c=
uss-sip-uui=0A> =0A> Thanks!=0A> - Alan -=0A> =0A> =0A> On Thu, May 30, 201=
3 at 7:47 PM, Scott G. Kelly <scott@hyperthought.com>wrote:=0A> =0A>> I hav=
e reviewed this document as part of the security directorate's=0A>> ongoing=
 effort to review all IETF documents being processed by the IESG.=0A>>  The=
se comments were written primarily for the benefit of the security area=0A>=
> directors.  Document editors and WG chairs should treat these comments ju=
st=0A>> like any other last call comments.=0A>>=0A>> I have no expertise in=
 SIP, and am providing this review as a first-level=0A>> filter for our ove=
r-worked security ADs. So, please take my comments=0A>> accordingly. Also, =
this review is a day late -- I hope it is still useful.=0A>>=0A>> This docu=
ment defines a method for exchanging a blob of information=0A>> between use=
r agents during SIP session establishment (User to User=0A>> Information, o=
r UUI data) by adding a new SIP header. The data is intended=0A>> to be opa=
que to SIP.=0A>>=0A>> There is a related problem statement RFC (6567) that =
briefly describes 3=0A>> different approaches to security, but neither docu=
ment describes likely=0A>> threats. They are implicit in the 3 models descr=
ibed in 6567 (e.g. treat=0A>> the sip layer as "untrusted", treat the sip l=
ayer as "trusted", treat the=0A>> transport domain as "trusted"), but I fou=
nd myself wishing I had more info=0A>> about real-world threats and counter=
measures.=0A>>=0A>> Given that I am not a SIP expert (and don't have time t=
o become one as=0A>> part of this review), I don't know if this is an issue=
 or not, but this is=0A>> an impression I think worth mentioning.=0A>>=0A>>=
 A second question relates to the binding of the UUI to its originator. The=
=0A>> security considerations section suggests that the UUI might carry sen=
sitive=0A>> info requiring privacy or integrity protection, but does not me=
ntion origin=0A>> authentication. There is a hint in the next paragraph (it=
 says=0A>> "History-Info can be used to determine the identity of the inser=
ter"), but=0A>> the relative security of this mechanism is not clear to me.=
 Could an=0A>> attacker forge History-Info? I don't know. What are the cons=
equences of=0A>> such behavior? I don't know. Seems like a well-written sec=
urity=0A>> considerations section would lay these questions to rest.=0A>>=
=0A>> Again, I have almost zero knowledge of SIP, so maybe answers are obvi=
ous=0A>> to someone steeped in SIP lore, and I apologize if this is the cas=
e. But,=0A>> these are my impressions.=0A>>=0A>> --Scott=0A>>=0A>>=0A>>=0A>=
 =0A