OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication


Title: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication
My comments below in red :


From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: Fri 04/06/2004 18:30
To: 'Linn, John'; Tim Alsop; 'Paul Madsen'; 'John Kemp'
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication

> I believe the most recent version of the credentials collector document
> was that posted on 4 November of last year, available at:
> www.oasis-open.org/apps/org/workgroup/security/download.php/4119/oasi
> s-sstc-v2_0-credentials_collector-use_cases-moses-02_d%85.pdf,
>  but recall that this topic area fell outside SAML 2.0's selected
> priorities in subsequent discussion.

That's true in the most general sense, but we've been doing profiles that
assume credentials collection since 1.0. The part that's out of scope, in my
mind, is the actual collector/authority interaction, which is left to
implementers to define. And since it's local to a security domain, the need
for interoperability in that is less compelling.

In this context, it's the KDC/authority relationship that's undefined.
Ideally the authority could just be a service principal in the KDC and
accept tickets, but if the pre-auth designation is important but missing
from the ticket, then it's not that simple.

Yes, this is true - it is not simple. However, we need to draw a close on this so that we can add some appropriate text to SAML 2.0 documentation. The way I see it we have 2 options :

1. Do not reference any passing of pre-auth type or ticket lifetime in SAML 2.0 specs and leave this for further review post SAML 2.0.
 
2. We make reference to this capability in the SAML 2.0 specs and say something like "A trusted method must be deployed to pass the pre-auth type and other Kerberos related context details to the authority. e.g. changes should be made to the KDC so that the KDC can supply this information when required".
 
My vote is to propose text as in item 2. Clearly we can improve on this post 2.0, but we need to make some reference rather than none.
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]