Tom Sanders wrote:
Manav,
We dont need to use a new auth type value for each new authentication
scheme > that comes up in the future.
One can define a new generic auth type 3, which would carry the
authentication > algorithm details in addition to the Key ID, auth
data length and the crypto
sequence number. The authentication data for type auth type 3 would
be the
same as type 2, except that the reserved bytes would get replaced
with the
authentication algorithm ID.
Excellent, this is much better than our initial guess.
Actually one octet is enough for carrying the Algo ID. You are still
left with one reserved octet. Go Play!
However, i dont think this is required.
Well, thats something that the WG, and not you and me, have to decide! :)
Hi Tom,
I'd also vote against this since the standardized definition of
cryptographic
authentication (AuType = 2) was designed to accommodate different hash
algorithms. Based on the discussion heretofore, it seems that its definition
satisfies this requirement. Additionally, I don't see any compatibility
problems
with implementations unequivocally map AuType 2 to MD5 authentication.
As one would expect, authentication will fail (at least with a very high
probability :^) if there is a mismatch between configured hash algorithms.
Thanks,
Acee
Cheers,
Manav
>> On 20/08/06, Phil Cowburn <[EMAIL PROTECTED]> wrote:
>>
>> I strongly agree with Manav here and an implementation must be
able to
>> demultiplex using the Key ID in the incoming packet. It is afterall
>> for this very reason that we put the Key ID in the packet.
>>
>> Erblichs point, as i read it is, that most implementations (if not
>> all) currently take type 2 to mean MD5. This may break once this
draft
>> becomes a standard, which it would, in some time.
>>
>> My take on this is that even if the WG agrees to Erblichs solution
and
>> introduces a new type, say 3 for HMAC-SHA-1 authentication, then
>> somebody else could repeat the same argument and clamour for a new
>> type when we're introducing newer authentication algorithms in the
>> future.
>>
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
