Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 14 Jan 2001 22:19:16 -0500

In message <Roam.SIMC.2.0.6.979236048.23304.pcalhoun@nasnfs>, Pat Calhoun write
s:
>Bernard,
>
>Should I assume from your e-mail that hop-by-hop is out in the base spec? I
>think discounting hop security is a mistake. Should I bring a contribution
>detailing this method?

Not at all.  In fact, the GSS-API and IPsec solutions are almost pure 
hop-by-hop.  (I say "almost" because I could probably construct an 
end-to-end Kerberos solution, if the proxies forwarded TGT requests to a 
distant Kerberos server.)

		--Steve Bellovin, http:/www.research.att.com/~smb

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 15 Jan 2001 12:34:54 +0530 (IST)

hi!

   Actually the kerberos solution provides both end-to-end and 
   and hop-by-hop. The TGT and service principal requests would be 
   sent directly from the Diameter client (NAS or first proxy) to
   the homerealm KDC. In case of TGT, Diameter client sends request 
   to local KDC which would be relayed to remote KDC. For service 
   principal ticket, Diameter client sends request 
   (KRB_TGS_REQ/KRB_TGS_REP) directly to remote realm KDC, proxies 
   don't relay tickets.
       The key negotiation (KRB_AP_REQ/KRB_AP_REP) messages carried in the 
   Diameter AVPs and would be forwared by proxies. The kerberos solution 
   can create security associations between any end-to-end diameter peers 
   or adjacent diameter peers. 

 kaushik!