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:]
Sent: Fri 04/06/2004 18:30
To: 
'Linn, John'; Tim Alsop; 'Paul Madsen'; 'John Kemp'
Cc: 

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.