Re: SACRED's vs. credentials' protection requirements [Was: RE: I-D ACTION:draft-ietf-sacred-reqs-00.txt]

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Hi John,

[snip]
> This seems reasonable in principle, but should temper later discussions
> about how any MUST-implement protection requirement should be framed for
> purposes of conformant interoperability.  Given an environment where
> credentials are themselves strongly protected, it could be a strong
> deterrent to SACRED adoption if the price of admission were deployment of
> additional infrastructure to support an additional layer of key management
> which wasn't strictly necessary from a security perspective.
[snip]

You're right that there will be cases where using whatever ends up as 
the standards track SACRED protocol will require overhead that isn't 
actually useful in the context of a particularly "strong" credential 
format. 

However, I think that in order to get an interoperable protocol that 
allows one to meet the overall charter we'll probably have to mandate 
that overhead, since we certainly will have to pick some credential 
format, and I'd be very surprised if that format is likely to be safe 
to use without the additional overhead.

Bit fuzzy I know, but I hope you get what I mean. 

> I'm OK with a list of example vulnerabilities, caveated as non-exhaustive,
> and think that this is useful and informative material to present.  Rather
> than considering them as a separate and different type of requirements,
> though, I'd suggest that their implied countermeasures be distilled into
> corresponding functional requirements within the existing protocol
> requirements sections.

I'm not sure that that'd work very easily but am certainly willing to
consider it. I guess the reason for listing vulnerabilities (and I 
agree that whatever list we end up with will be non-exhaustive) was
that I think its easier to do this way for requirements (i.e. less
danger of inadvertently including design in the requirements draft). 

Note also that the current draft doesn't say "protocols MUST prevent..."
but rather that they "SHOULD offer protection" and MUST specify how they 
do, or don't, protect against the listed vulnerabilities. There wasn't
an intent to declare a protocol as not meeting the requirements just
because there's some vulnerability listed that the protocol doesn't 
absolutely prevent (as long as that's noted in the protocol specification). 
Maybe this needs to be clearer?

> A separate point: shortly before the end of Sec. 2.1, it's stated that:
> 
>    "Solutions involving the direct transfer of credentials from one
>    device to another are potentially somewhat more complex than the
>    credential-server approach, owing to the large number of different
>    devices and formats that may have to be supported. Complexity is
>    also added due to the fact that each device may in turn have to
>    exhibit the behavior of both a client and a server."
> 
> I don't think that the presence or absence of a server influences the number
> of client device types that may exist, or the variety of credential formats
> they may use. I'm assuming the underlying premise here that the use of a
> server may simplify individual clients by making it unnecessary for them to
> provide functions to support other client types, at the cost of complexity
> present in the server to be able to interact with each of those client
> types.  If so, this might be a worthwhile clarification to include.

Good point.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com