[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Hybrid Authentication and Remote Access
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.
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. 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.
Follow-Ups: