Re: [secdir] secdir review of draft-ietf-tsvwg-admitted-realtime-dscp-05

Hi Fred,

Fred Baker wrote:

> On Nov 21, 2008, at 11:44 PM, Alexey Melnikov wrote:
>
>> I found the Security Consideration section to be insufficiently  
>> detailed
>> about threats. While the list of threats seems to be adequate,
>> it would be useful to have some pointers to documents describing  
>> possible
>> remedies (for example how to achieve adequately strong proof of  
>> identity),
>> or a clear statement that the protocol doesn't provide such facility.
>
> Would a reference to 4542 be sufficient?

It looks like a reference to section 2.4 of RFC 4542 would be helpful.

> My sense is that the threat model on a AAA service is likely to be  
> documented in something related to AAA services, and frankly you are  
> more likely to have a pointer to the document than I. Similarly, the  
> threat model regarding people getting capacity allocated to them that  
> shouldn't have been seems implicit in RFC 1633, the documentation of  
> RSVP, and the documentation of NSIS - protocols designed explicitly 
> to  prevent that from happening. There is of course a threat model 
> for  implementing such a protocol as well, which is mentioned in RFC 
> 4230.

I think a reference to RFC 4230 would be helpful as well.

> if I'm missing something and you want more, some idea of what kind of  
> threat model you are looking for would be helpful.

I was reading your Security Considerations:

   A major requirement of this service is effective use of a signaling
   protocol such as RSVP, with the capabilities to identify its user
   either as an individual or as a member of some corporate entity, and
   assert a policy such as "routine" or "priority".

   This capability, one has to believe, will be abused by script kiddies
   and others if the proof of identity is not adequately strong

My question after reading this part was "how one can make make proof of identity sufficiently strong?".
So some pointers helping a reader to find this information would be useful here.

   or if
   policies are written or implemented improperly by the carriers.  This
   goes without saying, but this section is here for it to be said...

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir