[Standards-JIG] [Fwd: Re: [Council] meeting agenda, 2006-04-11 - Dialback Key Generation and Validation]
weidongshao at gmail.com
Wed Apr 12 19:52:50 UTC 2006
HMAC is preferred in general. But in this case, I think direct hash is also
acceptable because the receiver needs to send an ID (which is kind of random
nonce value) from which the initiator generates the key. It is
challenge-reponse type of authentication. It is secure as long as we specify
"id" string to be long enough. Refer to HTTP digest authentication for an
example (RFC 2617) or SIP digest auth).
HMAC would be preferred if receiver wants to verifiy the message immediately
On 4/12/06, Philipp Hancke <fippo at goodadvice.pages.de> wrote:
> Matthias wrote:
> > I cannot write to the list, so I write to you: Why not using
> > HMAC-SHA256 instead of defining an own way of how to incorporate
> > a key into the hashing. HMAC-* also fixes all the problems Ian
> > mentions below.
> Yes. I already discussed that with Ian and will update the examples
> Ian suggested that for the sake of cross-product compability (e.g. a
> screening dialback proxy) the JEP should recommend a specific algorithm.
> Cross-application compability is indeed desirable, but it would probably
> require more than a 'recommendation', which may not be possible in an
> informational JEP.
> Assuming that a description of the key generation method is missing from
> rfc3920 because of IETF security requirements:
> Is is approriate to recommend HMAC-SHA256 (or -212?) in RFC 3920bis and
> describe the key generation and validation accordingly?
Information Security Consultant
Just another googler
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards