I'm going to play Devil's Advocate... to an extent I'm rehashing previous
discussions, but I think it's useful to rehearse these again on the list
in advance of next week's discussion.

>My biggest concern is that this ties KNP to RADIUS. Disadvantages
>include:
>
>1) It's difficult to use KNP for keying other AAA protocols. The details
>have become rather RADIUS specific  in Alan's proposal. While you could
>use something similar for Diameter you'd end up  redoing a lot of the
>spec and implementation work.

That's true, but perhaps there's a broader argument that introducing GSS
to the AAA protocols would be beneficial in terms of improving
crypto-agility and so forth.

(I know Alan's proposal was to frame using EAP directly, but you could
frame GSS tokens instead (which themselves could be GSS EAP tokens))

>2) It seems to more require your KNP implementation be heavily tied into
>your RADIUS implemenetation.

That doesn't seem like a bad thing; KNP is scoped only to key RADIUS after
all.

>3) You seem to have modified the RADIUS state machine somewhat and I'm
>concerned that it's going to be harder to perform security analysis of
>this than a separate protocol.

That's true. However, that analysis is a one-time cost. I claim that the
deployment cost of a system using a single transport would be less than a
system using two or more, and this is the cost that the design should
optimise for.

>4) You probably need an integrity protected channel for parts of
>KNP. EAP doesn't give you an integrity-protected channel with the right
>parties.

This is all happening over TLS, no?

>5) I don't actually see advantages to tieing this to RADIUS. We're
>talking about something that runs on relatively high-end
>servers. Supporting multiple protocols does not seem to be a problem.

See my response to (3).

>6) From an implementation standpoint, all our attribute and trust
>management logic is in our GSS implementation.

Perhaps that's an argument for framing EAP within GSS using our GSS EAP
implementation?

>7) Politically I don't think this approach can be standardized in the
>time available.  It would have to be done in RADEXT.  KNP makes a lot of
>ABFAB specific assumptions; doing it in a context general enough to work
>for RADEXT seems problematic to me.

I don't know the politics well enough to comment.

>I have significantly greater issues tieing trust router into RADIUS than
>KNP.

You're right, perhaps we do need longer than 3 hours next week :-)

Josh.



JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG