[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hybrid Authentication and Remote Access
On Thu, 16 Jul 1998 20:33:32 -0700, Bryan Gleeson wrote:
>Scott et al.
>
>> I wasn't planning on commenting on this until I'd had a bit
>> more time to
>> review it, but so long as you're bringing it up, I will voice one
>> criticism of the hybrid-auth draft: ISAKMP Notify messages
>> are ONE-WAY.
>> You are using them for a 2-way exchange. This is a hack. Read
>> the other
>> drafts. Hacking your enhancements into the protocol is ridiculous and
>> unjustified, given that the working group is entering another round in
>> which such modifications may be properly implemented if appropriate.
>>
>> Aside from that criticism, I agree that there is a need for such a
>> mechanism, and that this proposal meets that need in one way,
>> and Roy's
>> isakmp-xauth proposal meets it in others. It's certainly worthy of
>> continued discussion.
>
>I agree with your comments on the encoding. ISAKMP has a rich set of
>hooks for future extensions and so they should be used rather than
>redefining or mis-using existing payloads or message exchanges.
As for the use of the notify payloads, I can't say that I disagree
with you, but see my comments in the reply to Scott G. Kelly.
>Specifically if there is a new message exchange that has an unlimited
>number of messages in it, then that is probably a good time to define
>a new exchange type, rather than defining it as a variant of main mode,
>which always has 6 messages.
The hybrid authentication mode has exactly the same purpose as the
main mode, and a very similar structure. In fact the first two
messages are identical thus providing the ability to negotiate the use
of the hybrid mode or other authentication mode, using a different
exchange number will prevent this useful property.
I don't think that the 6 messages of main mode are curved in rock and
I don't see why it should be. Also note that normally the hybrid mode
takes also exactly 6 messages.
More fundamental to IKE is the idea that the authentication mode is
negotiable.
> Also if there is a new grouping of
>attributes that are needed for challenge/response type scenarios, then
>a new payload type with an associated set of attributes is also the way
>to go, rather than using the notification payload. The "minor version"
>field of the ISAKMP header field can be bumped up as extensions like
>this are agreed and accepted. Before that the "Vendor ID" payload can
>be used to indicate that private payloads are in use.
>
>Bryan Gleeson
>Shasta Networks.
>
Moshe Litvin
Follow-Ups:
References: