Subject: RE: [Simple] MSRP comments - security

From: [email-masked]
Date: Tue, 21 Oct 2003 18:37:39 +0300

> > Secondly, the digest mechanism has extensibility for other digest 
 > > algorithms, yet the SChal "algorithm" parameter is single 
 > valued. This 
 > > is a problem, since the client has no way to indicate the server 
 > > challenge contained an algorithm it does not support. 
 > Hence there needs 
 > > to be a way to negotiate the used algorithm, e.g., by the server 
 > > challenging with a list, and the client then picking one 
 > from that list.
 > > 
 > 
 > We made an explicit decision in Ottowa not to allow digest 
 > extensibility.

Well, that's not what the draft currently has. You need to then remove the "algorithm" directive, and all text talking about adding new algorithms - *if* you think SHA1 will never need to be replaced with anything else, that is.

Regards,
Aki 

 > 
 > > Furthermore, if negotiation of the used algorithm isn't 
 > secure, there is 
 > > a possibility for a bidding down attack.
 > > 
 > > So, my proposal is to modify the SChal so that the 
 > algorithm field is 
 > > multi-valued, and this field is also included in the 
 > request-digest. The 
 > > algorithm field in the CAuth then again needs to be 
 > single-valued, to 
 > > indicate which algorithm was chosen by the client.
 > > 
 > > Regards,
 > > Aki
 > > 
 > > [1] http://eprint.iacr.org/2002/163/
 > > 
 > > 
 > > 
 > > 
 > > 
 > > 
 > > _______________________________________________
 > > Simple mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/simple
 > 
 > 
 > 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Oct 2003 15:42:41 -0500

> Well, that's not what the draft currently has. You need to then remove the "algorithm" directive, and all text talking about adding new algorithms - *if* you think SHA1 will never need to be replac…

Sorry, my brain was asleppt when I wrote that. We explicitly decided not 
all mechanism extensibility where you could create mechanisms other than 
digest. I don't think we decided to forever limit digest to SHA1.

(The minutes from Ottawa are not clear on this--does anyone remember 
differently?)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Oct 2003 15:42:41 -0500

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Oct 2003 17:01:45 -0500

(replying to self)

Actually, the I think the syntax allows for more than one algorithm in 
the challenge. Aki is correct that we have no mechanism for the client 
to say that it does not support an algorithm.

Is it sufficient to say that all devices MUST support SHA1, and that if 
any algorithms are specified at all in the challenge, then SHA1 MUSt be 
included?

Ben Campbell wrote:

>>  > > algorithms, yet the SChal "algorithm" parameter is single  > 
>> valued. This  > > is a problem, since the client has no way to 
>> indicate the server  > > challenge contained an algorithm it does not 
>> support.  > Hence there needs  > > to be a way to negotiate the used 
>> algorithm, e.g., by the server  > > challenging with a list, and the 
>> client then picking one  > from that list.
>> Well, that's not what the draft currently has. You need to then remove 
>> the "algorithm" directive, and all text talking about adding new 
>> algorithms - *if* you think SHA1 will never need to be replaced with 
>> anything else, that is.
> 
> 
>>  >  > > Furthermore, if negotiation of the used algorithm isn't  > 
>> secure, there is  > > a possibility for a bidding down attack.
>>  > >  > > So, my proposal is to modify the SChal so that the  > 
>> algorithm field is  > > multi-valued, and this field is also included 
>> in the  > request-digest. The  > > algorithm field in the CAuth then 
>> again needs to be  > single-valued, to  > > indicate which algorithm 
>> was chosen by the client.
>>  > >  > > Regards,
>>  > > Aki

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Oct 2003 17:01:45 -0500

(replying to self)