Fwd: Re: [security-services] FW: Comment from: Nicolas.Williams@sun.com

[prateek mishra <pmishra@principalidentity.com>]

Note: forwarded message attached.

--- Begin Message ---

• From: prateek mishra <pmishra@principalidentity.com>
• To: prateek mishra <pmishra@principalidentity.com>, Nicolas.Williams@sun.com
• Date: Thu, 13 Jan 2005 23:08:33 -0800 (PST)

Hi Nicolas,

Thanks for your note. We are starting to freeze the
specification, so I made a quick pass thru your
comments and have no doubt missed some key points.



> 
>  - Core
> 
>    - The Kerberos V name syntax is not that given
> here.  Sam Hartman 
> suggests that a reference to RFC1964 for a string
> syntax would be good.

[Prateek]

Just to make sure I understand your comment: you are
proposing to RFC1964 instead of RFC1510 as the former
provides an explicit definition of the syntax of a
(string) Kerberos Principal Name Form.

[\Prateek]

> 
>    - Keying
> 
>       - How is key material obtained for encrypting
> or
> signing SAML 
> elements?  My impression is that if one has a
> certificate suitable for 
> XMLsig then one can use send wrapped ephemeral keys
> or
> key transport or 
> agreement and then encrypt, and/or one can just sign
> with the cert.  But 
> this did not seem to be explicitly mentioned in the
> SAML2 drafts -- 
> perhaps it's just that I've not read them carefully.
> 

[Prateek]

Discussion of trust-establishment and key management
were not included within scope of SAML 2.0. While it
would be helpful to have some additional material in
this space, I don't believe there are any open issues
here.

[\Prateek]


>    - Message authentication
> 
>       - XMLenc does not really provide for message
> authentication, 
> therefore it really must be used in conjunction with
> XMLsig.  Section 6 
> should not merely say that XML signatures and
> encryption "MAY" be 
> combined.  The security considerations doc doesn't
> even mention this, or so it 
> seems given its table-of-contents.  Again, maybe
> I've
> only made 
> too-cursory a reading of these documents.
> 

[Prateek]

I believe you will find this information is the
protocol section of core, as well as the profile,
binding and conformance specifications. These
specifications describe various forms of
authentication (channel, DSIG, other) that are
mandatory in various contexts. Section 6 only provides
some general guidelines for SAML use of signing over
and above those available in XML-DSIG. 

[\Prateek]

>    - channel binding issues
> 
>       - When relying on non-SAML-based channels for
> session security 
> there may be security considerations issues relating
> to the possibility 
> that the end-points of the two channels may be
> different -- i.e., just 
> saying "use TLS" does not mean that there will not
> be
> MITMs in a SAML 
> exchange.  Similar issues have come up at the IETF
> w.r.t. SASL and TLS, 
> for example.
> 

[Prateek]

I am not sure of the specific change you are
suggesting here. Is there language regarding use of
SSL/TLS that we should change?

[\Prateek]



>  - Sec. Cons., section 5.2.1.2
> 
>    Requiring that initiators sign initial messages
> does not necessarily 
> significantly reduce the responder work load that
> malicious initiators 
> can cause since, presumably, the responder would
> have
> to validate the 
> signature.
> 

[Prateek]

Agreed, but the notion here is that malicious
initiators are forced to work harder if signatures are
required. Responders are less affected as signing is
generally considered to be more computation-intensive
than its validation. I believe this is precisely what
the text states:

"In addition to the benefits gained from client
authentication discussed in Section 5.2.1.1, requiring
a
signed request also lessens the order of the asymmetry
between the work done by requester and
responder. The additional work required of the
responder to verify the signature is a relatively
small
percentage of the total work required of the
responder, while the process of calculating the
digital
signature represents a relatively large amount of work
for the requester. Narrowing this asymmetry
decreases the risk associated with a DOS attack."
[541-545]

[\Prateek]

>  - Conformance, section 4.2
> 
>    Ciphers are listed, but cipher modes aren't, and
> no
> reference to an 
> XML encryption specification is given.  This is at
> least obnoxious, in 
> that one has to hunt down the reference to obtain
> the
> additional 
> information.  The reference to key transport
> algorithms also seems strange 
> given the lack of discussion of keying in the core
> document.  The XMLenc 
> spec has many more required algorithms, but section
> 4.2 is not clear as 
> to whether all of XMLenc's requirements are
> applicable
> to SAML2 
> conformance or not.

[Prateek]

I will add the missing reference to XML-ENC. There is
no intent here of superseding or modifying XML-ENC. 

Re-reading the text, I have to agree that it sounds
odd, I will have to review the original source from
the list archives. Maybe this should be written as a
non-normative note, more of a reminder to implementors
(Recall that XML-ENC etc.) than a mandatory ("MUST")
requirement.

[\Prateek] 

> 
>  - There really should be an IETF<->OASIS liason.
> 
>    SAML specs use RFC2119 and seem to stick to some
> IETF I-D guidelines 
> (e.g., normative/informative reference split,
> etc...);
> certainly they 
> reference many IETF RFCs.  Further, I can imagine
> that
> folks will desire 
> to transport SAML assertions in PKIX extensions,
> Kerberos V 
> authorization data / ticket extensions, Kerberos V
> AP
> exchange authorization data 
> / extensions, etc...  A liason may prove useful.
> 

[Prateek]

Agreed, without a doubt liason would be helpful,
volunteers are solicited :-)

[\Prateek]

>  - More examples would be appreciated.
> 
> 
[Prateek]

As above :-)

[\Prateek]


> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> security-services-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> security-services-help@lists.oasis-open.org
> 
> 

--- End Message ---