Re: [wss] Groups - wss-kerberos-interop.doc uploaded

["Ramana Turlapati" <ramana.rao.turlapati@oracle.com>]

Martin,

I am still not sure why the second interop case is required. I am thinking
that the interop focus is on how to transport keberos AP_REQ within the
security header ans sign some elements using shared session key. Both these
scenarios, when you look at on the wire packets do exactly the same thing.
Isn't getting a AP_REQ from Responder's KDC as opposed to Requestor's KDC
out side the scope of the interop?

/t$r
(Ramana Turlapati)

----- Original Message ----- 
From: "Martin Gudgin" <mgudgin@microsoft.com>
To: "Rich Salz" <rsalz@datapower.com>
Cc: <wss@lists.oasis-open.org>; "Ken Ballou" <krb@datapower.com>
Sent: Monday, November 22, 2004 2:43 AM
Subject: RE: [wss] Groups - wss-kerberos-interop.doc uploaded




> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com]
> Sent: 18 November 2004 02:28
> To: ageller@microsoft.com
> Cc: wss@lists.oasis-open.org; Ken Ballou
> Subject: Re: [wss] Groups - wss-kerberos-interop.doc uploaded
>
> > Detailed Kerberos interop scenarios
>
> Some folks here took a look at this.

Thanks for the feedback.

>
> We understand that only using a single realm makes things
> simpler; it may
> in fact reflect the most common use pattern.  Unless the interop is
> on-site, however, this is going to cause issues as few firewalls will
> allow UDP traffic.

I think we were planning to put up a server outside our firewall for
this interop event.

>
> The primary difference between the two scenarios is who
> "owns" the KDC;
> this makes sense.  Unfortunately, the phrase used is
> "manufactured" which
> doesn't make sense, as it would seem to prevent a broad class of
> vendors, as well as those running the MIT reference
> implementation, from
> participating.  Perhaps "run by" is a better word?

I'll amend the doc.

Thanks again,

Gudge


>
> /r$
>
> -- 
> Rich Salz                  Chief Security Architect
> DataPower Technology       http://www.datapower.com
> XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
> XML Security Overview
> http://www.datapower.com/xmldev/xmlsecurity.html
>
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wss/members/leave
_workgroup.php.
>
>

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.