 |
 |
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