Re: Gen-ART LC review of draft-ietf-siprec-protocol-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Charles,
	Thanks for making the changes I suggested.  I’ve got one follow-up
on the authentication item (see below).

		Kind regards,
		-Peter

>-----Original Message-----
>From: Charles Eckel (eckelcu) [mailto:eckelcu@xxxxxxxxx]
>Sent: Monday, June 01, 2015 12:39 PM
>To: Hutton, Andrew; Jari Arkko; Peter Yee
>Cc: draft-ietf-siprec-protocol.all@xxxxxxxxxxxxxx; gen-art@xxxxxxxx; IETF
>Discussion Mailing List
>Subject: Re: Gen-ART LC review of draft-ietf-siprec-protocol-16
>
>Great comments. Please see comments inline.
>
>
>>>> Page 38, section 12.1, 1st paragraph, 2nd to last sentence: just
>>>because
>>>> an SRS is compromised does not mean that it cannot be authenticated.
>>>It
>>>> may very well be operating "correctly" and be able to authenticate,
>>>yet
>>>> the compromise allows the attacker to obtain the (decrypted) RS.
>>>> Authentication does not imply that the SRS you are talking to is not
>>>> compromised.  It only indicates the SRS possesses some form of
>>>credential
>>>> that appears to identify it correctly.
>>
>>Cannot argue with that and probably we should remove the sentence
>>starting "The risk of not authenticating the SRS...".
>
>The two sentences expanding on the impact of the SRC and SRS not
>performing mutual authentication are as follows:
>
>"The risk of not authenticating the SRS is that the recording may be sent
>to a
>   compromised SRS and that a sensitive call recording will be obtained
>   by an attacker.  On the other hand, the risk of not authenticating
>   the SRC is that an SRS will accept calls from an unknown SRC and
>   allow potential forgery of call recordings."
>
>
>Rather than removing, what if I change to the following:
>
>"The risk of not authenticating the SRS is that the recording may
>be sent to an entity other than the intended SRS, allowing a sensitive
>call recording to be received by an attacker.  On the other hand,
>the risk of not authenticating the SRC is that an SRS will accept calls
>from an unknown SRC and allow potential forgery of call recordings.
>
>Cheers,
>Charles

That does improve the text.  Authentication helps to narrow the chance
that recordings are sent to the wrong SRS or received from an unknown
SRC, to the extent that the cryptographic keying materials that are used
in the authentication process are properly protected.  I think the revised
text gives enough guidance without getting too deeply into the details of
how assurance of the security services is maintained, which is a problem
for all security protocols.






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]